Clarify compatibility guarantees around spec.preserveUnknownFields

Author: apelisse

content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md

@@ -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`: