Understanding Kubernetes API Resources: Group and Version

Kubernetes, an open-source container orchestration platform, is renowned for its ability to manage and deploy containerized applications at scale. One of the key components that enable this functionality is the Kubernetes API (Application Programming Interface). In the Kubernetes API, resources are organized based on their group and version, providing a structured and scalable way to interact with the platform. In this blog, we will focus on the Group and Version aspects of API resources.

We will cover:

• The Basics of Kubernetes API Resources
• Group
• Version
• Why Core and Named Groups?
• Named Groups in Detail
• Core Group Essentials
• How to Specify Group and Version
• Some useful kubectl commands

The Basics of Kubernetes API Resources

In Kubernetes, everything is an API resource. Pods, Deployments, Services, and ConfigMaps – each of these entities is represented as an API resource. When you interact with the Kubernetes API, you are essentially interacting with these resources. The structure of a Kubernetes API resource is defined by its Group, Version, and Kind.

Group

The concept of a “Group” in Kubernetes API resources allows for logical categorization and organization of related resources. Resources within the same group often share common functionalities or characteristics. For example, core resources like Pods and Services belong to the “core” group, while resources related to networking, such as Ingress, are in the “networking.k8s.io” group.

By grouping resources, Kubernetes provides a modular and extensible framework. This allows for the introduction of custom resources that can be logically grouped based on their purpose or domain, making it easier to manage and extend the platform.

Version

The “Version” of an API resource defines the schema and structure of that resource. As Kubernetes evolves, new features and improvements are introduced, often requiring updates to the API schema. By versioning resources, Kubernetes ensures backward compatibility and a smooth transition for users and operators.

When interacting with the Kubernetes API, specifying the resource’s version becomes crucial. For example, the Deployment resource in the “apps” group might have different features or fields in version “v1” compared to version “v1beta1”. Understanding the version of the resource you are working with ensures that you leverage the latest capabilities and adhere to best practices.

Why Core and Named Groups?

Kubernetes adopts a strategic approach by dividing its API into core and named groups. The core group, also known as the legacy group, encompasses essential resources integral to Kubernetes’ operation, such as Pods, Nodes, Namespaces, and Services. Conversely, named groups provide an organized structure to introduce custom resources and controllers, catering to specific areas like networking or storage.

Named Groups in Detail

Named groups offer a thematic organization of resources, allowing for a more structured and extendable Kubernetes experience. These groups cover various themes such as apps, extensions, networking, storage, authentication, authorization certificates, and more. As Kubernetes evolves, newer features are integrated into these named groups, making them crucial for developers seeking to customize and enhance specific functionalities.

The named group API endpoint is located at /apis/$GROUP_NAME/$VERSION, where $GROUP_NAME represents the custom resource name, and $VERSION is the API version.

Examples of Named Groups and Resources:

• apps: Deployments, ReplicaSets, StatefulSets, DaemonSets, DeploymentsRollback.
• extensions: Ingresses, NetworkPolicies, and PodSecurityPolicies.
• batch: CronJobs and Jobs.
• storage.k8s.io: StorageClasses and VolumeAttachments.
• policy: PodDisruptionBudgets.

Learn more about Kubernetes Architecture & Components

Core Group Essentials

The core group serves as the foundation of Kubernetes, encompassing critical functionalities like namespaces, Pods, replication controllers, events, endpoints, nodes, bindings, persistent volumes, persistent volume claims, configmaps, secrets, and services.

The core group’s API endpoint is located at /api/v1, and the apiVersion field in the manifest file specifies it as apiVersion: v1.

How to Specify Group and Version

When interacting with the Kubernetes API, you often encounter resource identifiers in the form of “group/version”. For example, the Pod resource in the “core” group and “v1” version is represented as “core/v1/pods”. This syntax helps Kubernetes determine which API to route the request to and ensures that the correct version of the resource is used.

apiVersion: core/v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: nginx-container
      image: nginx

In the above YAML example, “apiVersion” specifies the group (“core”) and version (“v1”) of the Pod resource.

Learn more about K8s Pods

Some useful kubectl commands

$ kubectl api-resources: This command displayes the supported API resources on the server.

$ kubectl api-versions: This command displayes the supported API versions on the server, in the form of “group/version.”

Conclusion

Understanding the Group and Version of Kubernetes API resources is fundamental for effective interaction with the platform. It allows developers, operators, and administrators to work with a diverse set of resources in a structured and modular manner. As Kubernetes continues to evolve, being aware of the group and version of resources becomes crucial for staying up-to-date with the latest features and best practices.

Related/References

• Visit our YouTube channel “K21Academy”
• Certified Kubernetes Administrator (CKA) Certification Exam
• (CKA) Certification: Step By Step Activity Guides/Hands-On Lab Exercise & Learning Path
• Certified Kubernetes Application Developer (CKAD) Certification Exam
• (CKAD) Certification: Step By Step Activity Guides/Hands-On Lab Exercise & Learning Path
• Create AKS Cluster: A Complete Step-by-Step Guide
• Container (Docker) vs Virtual Machines (VM): What Is The Difference?
• How To Setup A Three Node Kubernetes Cluster For CKA: Step By Step

Join FREE Masterclass

Discover the Power of Kubernetes, Docker & DevOps – Join Our Free Masterclass. Unlock the secrets of Kubernetes, Docker, and DevOps in our exclusive, no-cost masterclass. Take the first step towards building highly sought-after skills and securing lucrative job opportunities. Click on the below image to Register Our FREE Masterclass Now!