<p>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:</p>
<pre><code>/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=v1
</code></pre>
<p>Is 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?</p>

Haxsaw
<p>The reason behind this is the promotion of <code>v1beta1</code> resources to the <code>v1</code> API group, <a href="https://www.infoq.com/news/2020/09/kubernetes-ingress-ga" rel="nofollow noreferrer">as happened with Ingress</a>.</p>
<p>There's an internal mechanism that provides the conversion between resource versions when getting resources, as happening between <code>extensions/v1</code> and <code>networking.k8s.io/v1beta1</code>.</p>
<pre><code>$ kubectl get ingresses.v1beta1.extensions
NAME              CLASS    HOSTS   ADDRESS   PORTS   AGE
minimal-ingress   &lt;none&gt;   *                 80      5s

$ kubectl get ingresses.v1.networking.k8s.io
NAME              CLASS    HOSTS   ADDRESS   PORTS   AGE
minimal-ingress   &lt;none&gt;   *                 80      27s
</code></pre>
<p>More details on the conversion is available <a href="https://github.com/kubernetes/kubernetes/issues/94761#issuecomment-691982480" rel="nofollow noreferrer">here</a>.</p>
