Custom Resource Definitions (CRDs) and Operators in Kubernetes

Kubernetes provides a rich set of built-in resources (Pods, Deployments, Services, etc.), but sometimes organizations need to extend Kubernetes with custom APIs. Custom Resource Definitions (CRDs) allow you to define new resource types, while Operators automate the management of those resources. Together, they enable Kubernetes to manage complex applications as first-class citizens.

Custom Resource Definitions (CRDs)

A CRD lets you create your own resource types in Kubernetes. Once defined, you can interact with them using kubectl just like native resources.

Key Features

  • Extensibility: Add new resource types beyond built-in Kubernetes objects.
  • Declarative Management: Define desired state for custom applications.
  • Integration: CRDs integrate seamlessly with Kubernetes API.

YAML Example: CRD

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: databases.mycompany.com
spec:
  group: mycompany.com
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              engine:
                type: string
              version:
                type: string
  scope: Namespaced
  names:
    plural: databases
    singular: database
    kind: Database
    shortNames:
    - db

Explanation: This CRD defines a new resource type Database with fields for engine and version.

Operators

An Operator is a Kubernetes controller that uses CRDs to manage complex applications. Operators encode operational knowledge (installation, upgrades, backups) into Kubernetes-native automation.

Key Features

  • Automation: Automates lifecycle tasks like scaling, upgrades, and failover.
  • Domain Knowledge: Encapsulates expertise about managing specific applications.
  • Declarative Control: Users declare desired state; Operators reconcile actual state.

YAML Example: Custom Resource Managed by Operator

apiVersion: mycompany.com/v1
kind: Database
metadata:
  name: my-db
spec:
  engine: postgres
  version: "14"

Explanation: This custom resource defines a PostgreSQL database. The Operator ensures the database is deployed, configured, and maintained.

Flowchart: CRDs and Operators Workflow


   Define CRD ---> Kubernetes API recognizes new resource
          |
          v
   Create Custom Resource ---> Operator watches resource
          |
          v
   Operator reconciles state ---> Application deployed/managed
  

Real-Time Example

In a SaaS platform:

  • CRD: Defines a Database resource for PostgreSQL instances.
  • Operator: Automates provisioning, backups, and upgrades of databases.
  • Outcome: Developers declare database requirements, while Operators handle operational complexity.

Common Mistakes

  • Creating CRDs without Operators, leaving manual management tasks.
  • Not versioning CRDs, causing compatibility issues.
  • Overcomplicating Operators with too much logic, making them hard to maintain.
  • Ignoring RBAC, leading to insecure custom resources.

Interview Notes

Q1: What is the difference between CRDs and Operators?

Answer: CRDs define new resource types, while Operators automate their lifecycle management.

Q2: Why are Operators important?

Answer: Operators encode operational expertise, automating complex tasks like upgrades, scaling, and failover.

Q3: How do CRDs integrate with Kubernetes?

Answer: CRDs extend the Kubernetes API, allowing custom resources to be managed with kubectl and controllers.

Q4: Example Interview Task

# Apply CRD
kubectl apply -f database-crd.yaml

# Create custom resource
kubectl apply -f my-db.yaml

Explanation: This sequence defines a new CRD and creates a custom resource managed by an Operator.

Advanced Notes

  • Operator SDK: Framework for building Operators in Go, Helm, or Ansible.
  • Versioning: CRDs should support multiple versions for backward compatibility.
  • GitOps Integration: Manage CRDs and Operators declaratively via GitOps tools like Argo CD.
  • Best Practices: Keep Operators lightweight, secure CRDs with RBAC, and monitor Operator logs.

Summary

CRDs and Operators extend Kubernetes beyond its built-in resources, enabling management of complex applications as native objects. CRDs define new resource types, while Operators automate their lifecycle. Together, they provide powerful abstractions for declarative, automated, and secure application management. Mastering CRDs and Operators is essential for advanced Kubernetes deployments and a frequent topic in interviews.