We develop a Kubernetes Operator which manages Custom Resources and performs certain tasks in the cluster based on the spec. So resources manifests start like this:

apiVersion: foo.example.com/v1alpha1
kind: someKindOfResource
...

Now we want to introduce some breaking changes in the operator and also in the schema of the CustomResourceDefinition. Therefore we define the a new CRD Version v1beta1. Instead of setting up a automated conversion strategy, we think of the following manual procedure:

• Update the CRD (include both versions v1alpha1 and v1beta1)
• Update the Operator, it shall only support the new schema v1beta1. Custom Resources with version v1alpha1 shall be ignored in the reconciliation loop and only an operator log would indicate the error, like: ..Version not supported anymore, please update to new schema.
• A cluster admin can now manually apply the required changes to the CustomResources spec and change its version to v1beta1. Then the operator can manage the Custom Resource again.

The CRD Version Topic is described here kubernetes.io

If the conversion involves schema changes and requires custom logic, a conversion webhook should be used. If there are no schema changes, the default None conversion strategy may be used and only the apiVersion field will be modified when serving different versions.

In fact, we don’t want to have a automated conversion strategy at all. But the default conversion strategy does already change apiVersion to v1beta1 which leads to errors on the operator cannot handle the spec which is still based to the v1alpha1.

Question:
Is there an option to turn off the CRD automatic conversion strategy, so that the apiVersion in the CustomResource version remains unchanged?

Also ideas for other approaches are welcome. Thanks!