Extending K8S API

Enter the world of Custom Resource Definitions, or CRDs for the cool kids. Imagine being able to teach your Kubernetes new tricks without waiting for the next big release. That’s exactly what CRDs let you do!

In this blog post, we will explore how to extend the Kubernetes API with Custom Resource Definitions (CRDs).

Topics To be covered :

1. Registering a Custom API in Golang
2. Creating a Custom Resource Definition ( CRD ) to Register our Custom Resource

A Look at the General API of Kubernetes Resources

1. The Basics: API Groups and Versions

• API Groups: To make its API more extensible and modular, Kubernetes has different API groups like core, apps, batch, extensions, and more. These groups represent various functionalities and components.
• Versions: Each group can have multiple versions, typically marked as v1, v1beta1, etc. This is because the Kubernetes API evolves over time, and different versions can coexist.

2. Resources and Kinds

• Resources: These are a persistent entity in the Kubernetes system. Pods, Services, and Nodes are all examples of resources.
• Kinds: This denotes the type of the resource. When you create or read a resource, you work with its kind. For instance, the kind for a Pod is Pod, and for a Service, it’s Service.

3. Object Metadata Every Kubernetes resource comes with metadata. This section usually includes details like:

• name: Unique within a namespace, used to identify the resource.
• namespace: Helps with the resource’s scope. Some resources are cluster-scoped (like Node), while others are namespace-scoped (like Pod).
• labels and annotations: Key-value pairs that you can attach to resources for various purposes, from organizational patterns to notes.

4. Spec and Status Almost every Kubernetes resource has these two main fields:

• Spec (Specification): This is what you provide. It’s your desired state for the resource.
• Status: This is what Kubernetes provides back. It tells you the current state of the resource and how it compares to the spec.

5. API Endpoints For every resource, there are specific API endpoints. These are the URLs you’d hit if you were to interact directly with the Kubernetes API server. For instance, /api/v1/namespaces/{namespace}/pods/{pod} would be an endpoint for a specific pod.

You can check more info about: K8S API.

• GitOps.
• CoreDNS.
• AWS Consulting Services.
• DevOps Solutions Company.
•