What is a Kubernetes Operator?
Learn what a Kubernetes Operator is, how CRDs and controllers reconcile state, and how it automates expert operational tasks.
Expected Interview Answer
A Kubernetes Operator is a software extension that packages human operational knowledge about running a specific application into code, using a Custom Resource Definition plus a custom controller that continuously reconciles the cluster's actual state toward a declared desired state.
Operators build on the same controller pattern Kubernetes itself uses for built-in objects like Deployments: a control loop watches a custom resource (for example a "PostgresCluster" object), compares its spec against the real world, and takes action — creating Pods, adjusting replicas, taking backups, or performing a failover — until actual state matches desired state, then repeats indefinitely. What distinguishes an Operator from a generic controller is that it encodes domain-specific operational expertise that would otherwise live in a human runbook: how to safely upgrade this specific database's version, how to elect a new primary during a failure, how to resize storage without downtime. Operators are typically built with frameworks like the Operator SDK or Kubebuilder, which scaffold the CRD, controller, and reconciliation loop boilerplate. The result is that operationally complex, stateful software can be managed declaratively — a user edits the custom resource's YAML and the Operator handles the multi-step imperative work safely and automatically.
- Encodes expert operational runbooks as automated, repeatable code
- Enables declarative management of complex stateful applications
- Extends the Kubernetes API with domain-specific abstractions
- Reduces manual toil for tasks like failover, backup, and upgrades
AI Mentor Explanation
An Operator is like an experienced head groundsman who does not just follow a checklist once, but continuously watches pitch conditions and automatically adjusts watering, rolling, and covering decisions to keep the pitch matching the exact specification the curator wrote down. If rain threatens, the groundsman does not wait for instructions — years of expert knowledge about this specific ground are baked into their judgment, and they act immediately to bring conditions back to the target state. A generic assistant could follow a simple checklist, but the head groundsman knows the specific quirks of this exact pitch the way an Operator knows one specific application. The curator only needs to state the desired pitch condition; the groundsman's expertise handles every step to get there.
Step-by-Step Explanation
Step 1
Define the CRD
Register a Custom Resource Definition describing the domain object, e.g. a PostgresCluster with a spec for version and replicas.
Step 2
Build the controller
Write (or scaffold via Operator SDK/Kubebuilder) a control loop that watches instances of that custom resource.
Step 3
Reconcile toward desired state
On every change or periodic resync, compare actual cluster state to the resource spec and take the domain-specific actions needed.
Step 4
Encode operational expertise
Bake in safe upgrade paths, failover logic, and backup procedures so a human never needs to run those steps manually.
What Interviewer Expects
- Understanding that an Operator = CRD + a controller running the reconciliation loop
- Ability to explain what distinguishes an Operator from a generic Kubernetes controller (encoded domain expertise)
- Knowledge of common tooling: Operator SDK, Kubebuilder, Helm-based operators
- A concrete example, e.g. a database Operator handling failover or backups declaratively
Common Mistakes
- Describing an Operator as just “a Helm chart” with no reconciliation logic
- Confusing a CRD (the schema) with an Operator (the CRD plus its controller)
- Not mentioning the continuous reconcile loop, describing it as a one-time setup script instead
- Assuming every application needs an Operator rather than a simpler Deployment/StatefulSet
Best Answer (HR Friendly)
“An Operator is a way of teaching Kubernetes how to run a specific, often complicated piece of software the way an expert human would. We define a custom object describing the desired state, and the Operator continuously watches it and automatically performs the right operational steps, like backups or failovers, to keep reality matching that desired state, which saves the team from doing that work manually every time.”
Code Example
apiVersion: databases.example.com/v1
kind: PostgresCluster
metadata:
name: orders-db
namespace: payments
spec:
version: "16"
replicas: 3
storageSize: 100Gi
backupSchedule: "0 2 * * *"
status:
primary: orders-db-0
phase: HealthyFollow-up Questions
- How does an Operator differ from a plain Kubernetes controller?
- What role does a CRD play versus the controller code in an Operator?
- How would you test an Operator's reconciliation logic safely?
- When would you avoid building a custom Operator instead of using a Helm chart?
MCQ Practice
1. What two components together make up a Kubernetes Operator?
An Operator pairs a CRD (the schema for the domain object) with a controller that continuously reconciles actual state to the spec.
2. What primarily distinguishes an Operator from a generic Kubernetes controller?
What sets an Operator apart is encoding expert operational knowledge (upgrades, failover, backups) for a specific application into automated code.
3. Which toolkits are commonly used to scaffold Kubernetes Operators?
Operator SDK and Kubebuilder are the standard frameworks for scaffolding CRDs and controller boilerplate for Operators.
Flash Cards
What is a Kubernetes Operator made of? — A Custom Resource Definition plus a controller that reconciles it.
What makes an Operator different from a generic controller? — It encodes domain-specific operational expertise for one application.
Common Operator scaffolding tools? — Operator SDK and Kubebuilder.
Example Operator use case? — Automating database failover, backups, and safe version upgrades declaratively.