move to apiextensions.k8s.io/v1 and admissionregistration.k8s.io/v1

[joel-bluedata]

We need to start using apiextensions.k8s.io/v1 instead of apiextensions.k8s.io/v1beta1, because v1beta1 will be gone in K8s 1.22.

Need to figure out what the upgrade implications are for existing CRDs.

[joel-bluedata]

I don't think there are upgrade implications. We'd have to raise our K8s version support floor to 1.16 though.

[joel-bluedata]

Either that, or we could get fancier with our make-deploy and detect supported APIs, using the beta or final CRD API version accordingly.

[joel-bluedata]

Similar issue for admissionregistration.k8s.io/v1beta1 objects like MutatingWebhookConfiguration. Not sure when v1 was introduced there, but it's certainly in 1.16 so that would still work as a support floor. That will require (minor) code changes. Fortunately that won't require an upgrade of our operator SDK version since we already use the 1.16 API. We do want to upgrade our operator SDK dependency but it's nice not to have this minor change depend on that.

[joel-bluedata]

Working on this at https://github.com/joel-bluedata/kubedirector/tree/apiver

[joel-bluedata]

One thing I'm pondering is whether to set x-kubernetes-preserve-unknown-fields in the CRD schemas, to preserve the old behavior where unknown fields are not dropped from incoming CRs. In v1 by default they are dropped and not stored in etcd (and in fact can't even get past kubectl input validation unless you use --validate=false).

There a good reasons to prevent/drop unknown fields, e.g. the discussion in https://kubernetes.io/blog/2019/06/20/crd-structural-schema/ so I probably will leave the new v1 default behavior in place.