I'm doing some analysis on the swagger file that is supposed to generate the official Kubernetes Python client, and I put in a check just to see if the version named in a path ever differs from the version named in a parameter or return object, and it happens all over the place! Sometimes a v1 path has a param or return naming v1beta1 objects, and sometimes a beta path names v1 objects as params or returns. Just a couple of examples:
/api/v1/namespaces/{namespace}/pods/{name}/eviction, post, body, path_ver=v1, param_ver=v1beta1
/apis/batch/v1beta1/, get, 200 code, path_ver=v1beta1, response_ver=v1Is there some justification for this? In the eviction example above, there is no equivalent Eviction object in the v1 definition; shouldn't there be? This means that no single version is consistent and contained in and of itself. And in fact, in the case of the v1beta1 eviction object, it includes a reference to a v1 object, DeleteOptions. How can this be right? Is there an explanation that anyone can point me to?
The reason behind this is the promotion of v1beta1 resources to the v1 API group, as happened with Ingress.
There's an internal mechanism that provides the conversion between resource versions when getting resources, as happening between extensions/v1 and networking.k8s.io/v1beta1.
$ kubectl get ingresses.v1beta1.extensions
NAME CLASS HOSTS ADDRESS PORTS AGE
minimal-ingress <none> * 80 5s
$ kubectl get ingresses.v1.networking.k8s.io
NAME CLASS HOSTS ADDRESS PORTS AGE
minimal-ingress <none> * 80 27s
More details on the conversion is available here.