Why does `kubectl get` show a different API group for a resource to the group originally applied in the resource specification?

Question

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
[...]

Output of 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.

Answer

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 apps/v1 and extensions/v1beta1 API groups, but for backwards compatability the API server lists this first under the extensions/v1beta1 group.

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.

Further Reading

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.