Change:
<!-- 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

Discussion:
<ins> apiVersion: test.com/v1 kind: Example metadata: name: test spec: test: test </ins>

<ins> apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: examples.test.com spec: group: test.com scope: Cluster versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: test: type: string names: plural: examples singular: example kind: Example </ins>

<ins> apiVersion: test.com/v1 kind: Example metadata: name: test namespace: default spec: test: test </ins>

<ins> apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: examples.test.com spec: group: test.com scope: Namespaced versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: test: type: string names: plural: examples singular: example kind: Example </ins>

Note that the delete command does NOT do resource version checks, so if someone submits an update to a resource right when you submit a delete, their update will be lost along with the <del> rest of the resource.`)) </del> <ins> rest of the resource. After a CustomResourceDefinition is deleted, invalidation of discovery cache may take up to 10 minutes. If you don't want to wait, you might want to run "kubectl api-resources" to refresh the discovery cache.`)) </ins> deleteExample = templates.Examples(i18n.T(` # Delete a pod using the type and name specified in pod.json

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

record_command run_kubectl_explain_tests fi <ins> ############################## # CRD Deletion / Re-creation # ############################## if kube::test::if_supports_resource "${namespaces}" ; then record_command run_crd_deletion_recreation_tests fi </ins> ########### # Swagger #