Change:
set +o errexit } <ins> run_crd_deletion_recreation_tests() { set -o nounset set -o errexit create_and_use_new_namespace kube::log::status "Testing resource creation, deletion, and re-creation" output_message=$(kubectl apply -f hack/testdata/CRD/example-crd-1-cluster-scoped.yaml) kube::test::if_has_string "${output_message}" 'created' output_message=$(kubectl apply -f hack/testdata/CRD/example-crd-1-cluster-scoped-resource.yaml) kube::test::if_has_string "${output_message}" 'created' output_message=$(kubectl delete -f hack/testdata/CRD/example-crd-1-cluster-scoped.yaml) kube::test::if_has_string "${output_message}" 'deleted' # Invalidate local cache because cluster scoped CRD in cache is stale. # Invalidation of cache may take up to 10 minutes and we are manually # invalidate cache and expect that scope changed CRD should be created without problem. kubectl api-resources output_message=$(kubectl apply -f hack/testdata/CRD/example-crd-1-namespaced.yaml) kube::test::if_has_string "${output_message}" 'created' output_message=$(kubectl apply -f hack/testdata/CRD/example-crd-1-namespaced-resource.yaml) kube::test::if_has_string "${output_message}" 'created' # Cleanup kubectl delete -f hack/testdata/CRD/example-crd-1-namespaced-resource.yaml kubectl delete -f hack/testdata/CRD/example-crd-1-namespaced.yaml set +o nounset set +o errexit } </ins> run_kubectl_explain_tests() { set -o nounset set -o errexit

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --Changing the scope field of a CRD ist not possible since it's immutable. But even after deleting and re-creating the CRD with changed scope it doesn't let me create resources of the CRD's kind. Re-creating CRD with changed scope should just work. Here is a full example that in the end leads to the error when trying to create a resource after re-creating the CRD. Kubernetes version (use ): v1.21.4 Cloud provider or hardware configuration: vSphere 7.0 OS (e.g: ): Centos 7 Kernel (e.g. ): 3.10.0-1160.42.2.el7.x86_64
/sig api-machinery
/assign /triage accepted
This appears to be working as intended. The example custom resource you use: It Cluster scoped because it has no namespace. But once the CRD is namespace scoped, you should not be able to create cluster scoped custom resources of that type. If instead you add a namespace to Example, it should be created, e.g.:
if the above seems to have answered your question - please feel free to close the issue :) Thank you!
kubectl will automatically use the namespace so this is definitely not the issue here. I can reproduce this issue with my above script in a fresh (v1.22.2) cluster. You can add the namespace in the last manifest, it makes no difference. From my understanding this really seems to be a bug.
Yes, that's true. Good catch. Okay, we need to root cause this.
I tried using curl to create the custom resource directly against the API and got the same result: So the problem seems to be in the API server (not in kubectl).
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale