Vultr DocsLatest Docs

Kubernetes: Groups, Versions, and Resources

ResourcesKubernetesAPI
Updated on October 21, 2022
Kubernetes: Groups, Versions, and Resources header image

What is the GVR in Kubernetes? It stands for Group Version Resource, which drives the Kubernetes API Server structure. This article explains the terminology for Groups, Versions, Resources (and Kinds) and how they fit into the Kubernetes API.

Kind

Kinds in Kubernetes are related to the object you are trying to interact with. For example, a pod or deployment would be your Kind. There are three categories of Kinds which are listed below.

  • Objects: These are your pods, endpoints, and deployments.
  • Lists: These would be collections of one or more Kinds. An example would be pod list or node list.
  • Special Purpose: Use these as specific actions on objects or none persistent objects. Examples would be /binding or /scale.

Group

A group is a collection of kinds. The ReplicaSets, StatefulSets, and Deployments are part of the apps group. One thing to note is that you can have Kinds living in multiple groups. The group may start as an alpha version, and as it matures, it will move into another group.

Version

Versions allow Kubernetes to release groups as tagged versions. There are different versions of Kubernetes.

  • Alpha: By default, usually disabled because we should only use them for testing. You may see these labeled as v1alpha1.
  • Beta: By default, enabled; however, there is no guarantee that any further beta or stable releases will be backward compatible. You may see these labeled as v1beta1.
  • Stable: These have reached maturity and will be around for further releases. You may see these labeled as v1.

You can have a group within any of these versions. A group usually starts in Alpha, then moves onto Beta, and eventually Stable.

Resource

The resource is an identifier that receives and returns its corresponding kind. Resources also expose CRUD actions for that Kind.

API URI

Now that you have a base understanding look at the URI for Deployment creation. The URI is as follows:

POST /apis/apps/v1/namespaces/{namespace}/deployments

The breakdown for the URI is as follows:

POST /apis/{GROUP}/{VERSION}/namespaces/{namespace}/{KIND}

If you want further actions on a resource, further endpoints are available. Here is how to get a specific deployment and its status.

GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}
GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status

There may be some resources that are cluster-wide such as nodes or namespaces. These can be grouped into a GVK (Group Version Kind) where the namespace is omitted, as opposed to the namespace being part of the resource in a GVR.

GET /api/v1/nodes

Summary

This should give you more insight into how the API Servers APIs are designed with their URI structure. Along with a new appreciation for some terms, such as kinds, groups, and resources you may see in your YAML definitions.

Some useful links are available if you want more information about this topic.