Velero: Update velero CRDs to v1

[skriss]

We're currently generating and installing v1beta1 CRDs for Velero, mainly for backwards compatibility. The apiextensions API group graduated to v1 as of Kubernetes 1.16, and the v1beta1 version of the group is scheduled to be dropped in an upcoming Kubernetes release.

At some point (before v1beta1 is dropped for good) we need to updated our generated CRDs to be v1. There's an existing PR (#2190) that we may want to dust off.

Additionally, it'd be nice to take advantage of some of the v1 features, like defaulting.

Tagging this for v1.5 for now -- not sure yet if it's must-do for then or not.

[skriss]

FYI per https://github.com/kubernetes/kubernetes/issues/82022#issuecomment-636872808 removal of apiextensions.k8s.io/v1beta1 has been targeted for 1.22. cc @nrb

[nrb]

Good to know!

When we move this, we'll likely end up bumping our minimum supporting k8s version to one that at least has the v1 endpoint.

[skriss]

Yep, so 1.16 by default - I think by the time 1.22 rolls around, that should be fine (and older versions of Velero will still work on older Kubernetes versions).

[jenting]

I'd like to revisit this again since at K8s 1.19+, installation CRD apiextensions.k8s.io/v1beta1 shows the deprecated warning message, use apiextensions.k8s.io/v1 instead. The apiextensions.k8s.io/v1beta1 introduced from K8s 1.16+ and apiextensions.k8s.io/v1beta1 will be dropped at 1.22.

I'd like to take the approach that let user executes --validate=false for k8s 1.16- cluster, like https://velero.io/docs/v1.5/customize-installation/#generate-yaml-only.

cc @nrb any comments or feedback?

[mapdegree]

Hi @skriss,

I would appreciate, if we could move Velero CRD to the v1 Kubernetes APIs soon. I checked that version 1.16 was available since 8 September 2019, so at least a 1.5 years has been given to the community to migrate over.

In many organisations /companies we focus a lot currently when migrating to 1.20 that we abandon as many beta Kubernetes API calls in the manifests. We got a surprise that Velero is left behind at current version.

Thanks,
Dejan

[nrb]

@mapdegree While the community may have upgraded, it is very possible enterprise users have not. As a migration tool, Velero should be useful on older versions of Kubernetes, without requiring users to use 2 different versions of Velero to do the job.

Per the Kubernetes deprecation guidelines v1beta1 will be removed in v1.22.

That said, we're looking to get this upgraded or allow dual version usage soon, so our supported window of Kubernetes versions is greater than 6 releases.