The Kubernetes API group and version returned for a resource from the Kubernetes API (using for example the
kubectl CLI) may show as different to the original group and version defined in the resource specification via the
apiVersion. For example, when creating a Deployment resource in the v1 version of the apps API group, the output of
kubectl get deployment -o yaml may show the Deployment resource in the v1beta1 version of the extensions API group, per the below:
Original Deployment YAML:
apiVersion: apps/v1 kind: Deployment [...]
kubectl get deployment -o yaml for this Deployment resource post-creation:
apiVersion: extensions/v1beta1 kind: Deployment [...]
This article explains the cause of this behaviour and how to ensure resources are returned by the API under a specific API group and version.
A Kubernetes resource type, such as Deployment, can exist within multiple API groups. Where this is the case, and no API group and version is specified in the command,
kubectl will use the first group listed in the discovery docs published by the Kubernetes API server that you are querying. In the instance of the above example, the Deployment resource exists under boths the
extensions/v1beta1 API groups, but for backwards compatability the API server lists this first under the
To ensure that the resource retrieved is in a particular API group, you should fully qualify the resource type in the
kubectl command, i.e. to query Deployment resources in the apps API group run
kubectl get deployments.apps -o yaml. Additionally you can provide an explicit version of the API group, i.e. to query Deployment resources in the v1 version of the apps API group run
kubectl get deployments.v1.apps -o yaml.
You can find a good discussion on this behaviour in the Kubernetes GitHub Issue #58131.
The Kubernetes developer documentation on API resource versioning can be found here.