Move CRD to apiextensions.k8s.io/v1

[JohnStrunk]

Describe the feature you'd like to have.
Kube 1.16 brought apiextensions to v1, and it appears v1beta1 vill no longer be available in 1.19.
The SnapScheduler operator needs to be deployed w/ the proper version depending on the cluster version.

What is the value to the end user? (why is it a priority?)
It is desirable for users to continue to have access to SnapScheduler as Kubernetes moves to 1.19+.

How will we know we have a good solution? (acceptance criteria)
Deployment of the operator is currently supported both via Helm and OLM. This should continue to be the case.

Additional context
Currently, Helm deployment is supported back to 1.13, and OLM is back to 1.17. Ideally, we can preserve that even with this switch.

[JohnStrunk]

In both cases below, it is necessary to investigate installing updates (using v1) over top of v1beta1.

Helm

In the case of Helm, we currently deploy the CRD via its crds directory. Unfortunately, that mechanism doesn't have any pre-processing that would allow us to dynamically choose the proper apiextensions version.

Since we don't actually use the CR in the chart, it's not necessary for it to be deployed via the crds directory. Instead, it should be possible to move it into the templates directory and choose the correct version to deploy based on .Capabilities.KubeVersion.Version like we do here:

snapscheduler/helm/snapscheduler/templates/deployment.yaml

Line 58 in f230f7c

{{- if semverCompare ">=1.14" .Capabilities.KubeVersion.Version }}

OLM

I think this may come down to specifying a min kube version and stranding old clusters on old versions of the operator. This may be ok since OLM is primarily targeted at OpenShift and users would be expected to follow the upgrade cycle there.
The result would be that old clusters would stop getting operator updates (except for backported bugfix releases), but once the cluster is updated, operator updates would resume.

[JohnStrunk]

Removal of v1beta1 has been moved to kube v1.22:
kubernetes/kubernetes#82022 (comment)