Mastering Kubernetes CRDs and Operators: From Basics to Advanced Design

1. What is a CRD

When built‑in Kubernetes resources are insufficient, developers create Custom Resources (CR). A CustomResourceDefinition (CRD) acts as a schema that tells the API server how to recognize these resources, using an OpenAPI v3 schema similar to a strongly‑typed declaration.

<code>apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: lights.light.sreworks.io
spec:
  group: light.sreworks.io
  names:
    kind: Light
    plural: lights
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          description: ...
          type: object
          properties:
            spec:
              type: object
              properties:
                company:
                  type: string
                ...</code>

With CRDs you can add resources that sit alongside native ones, such as jobs, routes, or accounts, and let an Operator make them effective.

2. What is an Operator

An Operator encodes human operational knowledge into software, managing the full lifecycle of a Kubernetes application (deploy, upgrade, scale, delete, etc.). It is essentially a controller that watches custom resources and reconciles their desired state.

WHAT IS AN OPERATOR AFTER ALL? An Operator represents human operational knowledge in software, to reliably manage an application. They are methods of packaging, deploying, and managing a Kubernetes application.

Operators often work with a CRD; each custom resource is backed by one or more controllers that act like operators, reacting to changes and performing actions such as turning a light on/off based on a YAML spec.

<code>apiVersion: v1
kind: Light
metadata:
  name: bedroom
spec:
  power: on
  brightness: 70
  colorTemperature: 5000k</code>

The controller abstracts the retry logic, so users only set the desired final state (e.g., power=on) and the Operator ensures it is achieved, similar to how a Pod controller keeps a pod running.

3. Implementing a Kubernetes Operator

Operators can be built with frameworks like KubeBuilder or Operator‑SDK, which handle the boilerplate of watching CRs, queuing events, and reconciling state. They complement Helm or Kustomize, which still handle templating and packaging.

4. A Generic Big‑Data Operator

Complex distributed workloads share common patterns; a generic big‑data Operator abstracts these into a YAML‑driven control loop (perception → decision → execution). It introduces a VirtualResource concept, inspired by React’s VirtualDOM, allowing SQL‑like queries over resources.

The controller description can be expressed without Go code, for example:

<code>default:
  def: crd.yaml
  deploy:
    - cmd: helm
      chart: vvp/vvp
      values: vvp/values.yaml
  maintain:
    - watch:
        category: ResourceDidChange
        kind: Service
        apiVersion: v1
      action:
        - cmd: kube-patch
          file: ingressUpdate.yaml</code>

5. Summary

CRD + Operator is the most flexible way to extend Kubernetes when Helm or Kustomize are insufficient, but it adds complexity and is best used together with those tools. Operators are suited for migrating non‑cloud‑native applications to Kubernetes, while native cloud‑native workloads increasingly rely on built‑in controllers.