Extending Kubernetes with Custom Resource Definitions

You will define custom API types to extend the Kubernetes schema and store domain-specific configuration data within the cluster.

In this lesson, you will learn how to expand the Kubernetes API by defining your own domain-specific resource types using Custom Resource Definitions (CRDs).

While Kubernetes comes pre-packaged with primitives like Pods, Deployments, and Services, real-world applications often require specialized configuration data that doesn't map perfectly to those standard objects. CRDs allow you to teach the Kubernetes API server about entirely new object types, letting you store and manage custom configuration data directly within the cluster state.

Defining Your Custom Schema

A CRD acts as a "blueprint" for your new object. When you submit a YAML manifest for a CRD, Kubernetes updates its API to recognize your new resource. For example, if you were building a custom platform for database management, you might want a DatabaseInstance resource.

Your CRD manifest defines the structure of this object, including its group, version, and the schema for its spec (the desired state):

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: databaseinstances.stable.example.com
spec:
  group: stable.example.com
  names:
    kind: DatabaseInstance
    plural: databaseinstances
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                engine:
                  type: string
                size:
                  type: integer

Why Use CRDs?

Once the CRD is applied, you can interact with these new objects using standard kubectl commands, such as kubectl get databaseinstances. This is incredibly powerful because it allows you to leverage existing Kubernetes tooling—like RBAC, auditing, and backup systems—to manage your custom domain data.

In a CI/CD pipeline context, CRDs serve as the "source of truth." You can package these definitions within your Helm charts, allowing you to deploy both your application services and the custom configurations they require in a single, unified release. By extending the schema, you transition from managing generic infrastructure to managing your specific business domain natively within Kubernetes.

Key Takeaway: Custom Resource Definitions allow you to extend the Kubernetes API with your own object types, enabling you to store domain-specific configurations as first-class citizens in the cluster.