Understanding Kubernetes GVR

Photo by Dakota Roos on Unsplash

What is the GVR in Kubernetes? It stands for Group Version Resource and this is what drives the Kubernetes API Server structure. We will cover exactly what the terminology means for Groups, Versions, Resources (and Kinds) and how they fit into the Kubernetes API.


Kinds in Kubernetes relate to the object you are trying to interact with. A pod or deployment would be your Kind.

There are three categories of Kinds

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


A group is simply a collection of kinds. You can have kinds such as ReplicaSets, StatefulSets, and Deployments which are all part of the apps group.

One thing to note is that you can have Kinds living in multiple groups. The group may start off as a alpha version in group and as it matures it move be moved into another group.


Versions allow Kubernetes to release groups as tagged versions. Here are the versions that Kubernetes has available.

  • Alpha : This is usually disabled by default since they should only be used for testing. You may see these labeled as v1alpha1
  • Beta : This is enabled by default. However there is no guarantee that any further beta or stable releases will be backwards 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 exist within any of these versions if not all of the. A group usually starts off in Alpha then moves onto Beta and eventually Stable.


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


Now with a base understanding if we look at the URI for Deployment creation

The uri is as follows:

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

Now the breakdown for the URI is as follows

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

If you wanted to get further actions on a resource there are further endpoints available. Here is getting a specific deployment and it’s status

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

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

GET /api/v1/nodes

To summarize

This should give you a little more insight into how the API Servers APIs are designed with their URI structure. Along with a new appreciation for what some of the terms such as kinds groups resources that you may see your yaml definitions you write for Kubernetes.

If you want some more information about this topic here are some useful links




Gopher with a keen interest in cloud native. Principal Engineer @Vultr

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

08. Using the Java Library

My second dive into TI stuff: Part 1 - HTML (First Post)

Concurrent Programming Fundamentals — Sharing Objects (Part 1)

People build products, not processes

Announcing the Official Release of Nabox Chrome Extension

How to Make your localhost Online on Ubuntu?


What makes Flutter different from other languages and frameworks?

Check If It Is a Good Array

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
David Dymko

David Dymko

Gopher with a keen interest in cloud native. Principal Engineer @Vultr

More from Medium

Learn Kubernetes: Secrets — Use of a TLS type secret

Kubernetes in production

Creating multiple deployments with different configurations using Helm

How Docker inspired other Container Orchestration tools — An Inspiring Journey of Kubernetes