Clarify compatibility guarantees around spec.preserveUnknownFields

pull/25597/head
Antoine Pelisse 2020-12-13 20:43:29 -08:00
parent fa83273ca5
commit a51a653764
1 changed files with 1 additions and 1 deletions

View File

@ -314,7 +314,7 @@ CustomResourceDefinitions store validated resource data in the cluster's persist
{{< note >}}
CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`.
For migrated CustomResourceDefinitions where `spec.preserveUnknownFields` is set, pruning is _not_ enabled and you can store arbitrary data. For best compatibility, you should update your custom resources to meet an OpenAPI schema, and you should set `spec.preserveUnknownFields` to true for the CustomResourceDefinition itself.
For legacy CustomResourceDefinitions created as `apiextensions.k8s.io/v1beta1` where spec.preserveUnknownFields is set to true, pruning is not enabled and you can store arbitrary data. For compatibility with `apiextensions.k8s.io/v1`, you should update your custom resources definition to (1) have a structural OpenAPI schema, and (2) you should set spec.preserveUnknownFields to false. In Kubernetes 1.22 the `apiextensions.k8s.io/v1beta1` API will be removed, and every CustomResourceDefinition must be created via `apiextensions/v1`, and this enforces both (1) and (2).
{{< /note >}}
If you save the following YAML to `my-crontab.yaml`: