Is it mandatory to upgrade CRDs deprecated apiVersions?

I have a few external CRDs with old apiVersion applied in the cluster, and operators based on those CRDs deployed.

As said in official docs about Kubernetes API and Feature Removals in 1.22.

You can use the v1 API to retrieve or update existing objects, even if they were created using an older API version. If you defined any custom resources in your cluster, those are still served after you upgrade.

Based on the quote, does it mean I could leave those apiextensions.k8s.io/v1beta1 CRDs in the cluster? Will controllers/operators continue to work normally?

Solution

The custom resources will still be served after you upgrade

Suppose we define a resource called mykind

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: mykinds.grp.example.com
spec:
  group: grp.example.com
  versions:
    - name: v1beta1
      served: true
      storage: true

Then, on any cluster where this has been applied I can always define a mykind resource:

apiVersion: grp.example.com/v1beta1
kind: Mykind
metadata:
  name: mykind-instance

And this resource will still be served normally after upgrade even if the CRD for mykind was created under v1beta1.

However, anything in the controller / operator code referencing v1beta1 CRD won't work. This could be applying the CRD itself (if your controller has permissions to do that) for example. That's something to watch out for if your operator is managed by the Operator Lifecycle Manager. But watching for changes in the CRs would be unaffected by the upgrade.

So if your controller / operator isn't watching CustomResourceDefinitions then technically you can leave these CRDs on the cluster and your operator will work as normal. But you won't be able to uninstall + reinstall should you need to.

Another thing to explore is if / how that might affect your ability to bump API versions later though.