Kubernetes Operator

A Custom Resource Definition (CRD) is a Kubernetes API extension that defines a new, custom object type (a Custom Resource) for the operator to manage. It specifies the object's schema—the structure of its spec (desired state) and status (observed state) fields. For example, a Database CRD would define fields for spec.replicas and status.readyReplicas. The CRD allows users to declare their application's configuration using kubectl and YAML files, just like native Kubernetes resources such as Pods or Deployments.

A Custom Resource (CR) is an instance of the object type defined by a Custom Resource Definition. It represents a declarative intent or a specific instance of the application the operator manages. The user creates a CR manifest (YAML) to specify the desired state. For instance, creating a postgres-cluster CR with spec.storage: 100Gi instructs the operator to provision a PostgreSQL cluster with that configuration. The operator continuously watches these objects and reconciles the actual system state to match the user's declared intent in the CR.

The Controller is the core logic of the operator, implementing a continuous reconciliation loop. This loop:

• Watches for changes to Custom Resources and related Kubernetes objects.
• Compares the observed state of the world (e.g., actual Pod status) with the desired state declared in the CR's spec.
• Takes Action to make the observed state match the desired state (e.g., creating a Deployment, updating a ConfigMap).
• Updates Status by writing the current observed conditions back to the CR's status field. This loop runs perpetually, ensuring the system self-heals from drift or failures.

The key value of an operator is the domain-specific operational knowledge encoded within its controller logic. This goes beyond simple deployment to handle complex, stateful application lifecycle tasks that are otherwise manual and error-prone. This encoded knowledge typically includes:

• Lifecycle Management: Handling version upgrades, schema migrations, and backup/restore procedures.
• Failure Recovery: Automatically replacing failed nodes, rebalancing data, and handling network partitions.
• Configuration Management: Dynamically updating configuration files and rolling out changes safely.
• Scaling Operations: Correctly scaling stateful components, which may require re-sharding or data redistribution.

Finalizers are keys on a Kubernetes object that block its deletion until specific controller logic is executed. Operators use them to implement orderly resource cleanup. When a user deletes a Custom Resource, the operator's finalizer ensures it can perform necessary pre-deletion steps (like draining connections, deleting cloud volumes, or removing external dependencies) before the object is removed from the API server. This prevents orphaned resources and data loss. The controller removes the finalizer only after cleanup is complete, allowing Kubernetes garbage collection to proceed.

The Operator pattern combines two core Kubernetes concepts: Custom Resources and Controllers.

1. Custom Resource Definition (CRD): Extends the Kubernetes API to define a new object type (e.g., PostgresCluster) that represents the desired state of the application.
2. Custom Resource (CR): An instance of the CRD (e.g., a YAML file specifying 3 replicas, version 15, 100GB storage).
3. Controller: A control loop that watches the API server for changes to CRs and other resources (Pods, Services). It compares the observed state of the cluster with the desired state specified in the CR.
4. Reconciliation Loop: The core logic where the Operator makes imperative calls to the Kubernetes API (create/delete/update Pods, Jobs, ConfigMaps, etc.) to drive the observed state toward the desired state. This loop runs continuously, ensuring the system self-heals and converges on the specified configuration.

A Custom Resource Definition (CRD) is the Kubernetes API extension mechanism that allows users to define their own resource types (Custom Resources) alongside native ones like Pods or Deployments. It specifies the schema (the spec and status fields) for the new resource.

• Purpose: Encodes domain-specific objects (e.g., PostgresCluster, TensorFlowJob) into the Kubernetes API.
• Mechanism: Once a CRD is applied, the Kubernetes API server begins serving the new RESTful endpoint for the custom resource.
• Example: A CRD for a database might define fields for spec.replicas, spec.storage.size, and status.readyReplicas.

A Controller is a control loop that watches the state of resources (both Kubernetes-native and Custom Resources) and takes action to move the current state toward the desired state declared in the resource's spec. This continuous process is called the reconciliation loop.

• Core Pattern: It follows the Observe, Diff, Act cycle.
• Operator Role: An Operator's primary component is a custom controller that understands the operational semantics of its specific application.
• Example: A database controller observes a PostgresCluster custom resource, and if spec.replicas is 3 but status.readyReplicas is 2, it will create a new Pod.

A Custom Resource is an instance of a resource type defined by a Custom Resource Definition (CRD). It is a declarative YAML or JSON object that represents the desired state of a specific application or service within the Kubernetes cluster.

• User Interface: This is what users and automation tools interact with to manage the operator's application.
• Structure: Contains a spec section (user's desired state) and a status section (operator-populated actual state).
• Example: apiVersion: postgres.example.com/v1, kind: PostgresCluster, metadata: name: my-db, spec: replicas: 3.

The Operator Pattern is a method of packaging, deploying, and managing a Kubernetes application by combining three key elements: a Custom Resource Definition to define the application's API, a Custom Controller to implement operational logic, and Custom Resources as the user interface. It codifies human operational knowledge (backups, scaling, upgrades) into software.

• Goal: To automate the entire lifecycle of complex, stateful applications.
• Evolution: Originally conceptualized by CoreOS to manage etcd, Prometheus, and other services.

A StatefulSet is a native Kubernetes workload API object used to manage stateful applications. It provides guarantees about the ordering and uniqueness of Pods. Operators frequently manage StatefulSets to deploy the underlying pods of a stateful service.

• Key Features: Stable, unique network identifiers and persistent storage per Pod ordinal. Ordered, graceful deployment and scaling.
• Operator Relationship: An Operator's controller often creates and manages one or more StatefulSets to run the core application (e.g., database nodes). The Operator handles higher-level logic (failover, configuration) that the StatefulSet alone cannot.