Operator pattern overview in Kubernetes - Step-by-Step Execution

Process Flow - Operator pattern overview

User defines Custom Resource (CR)

↓

Operator watches CR changes

↓

Operator reads desired state

↓

Operator compares desired vs actual state

↓

Operator takes actions to reconcile

↓

Kubernetes cluster state updated

↓

Operator continues watching for changes

The Operator pattern watches custom resources, compares desired and actual states, and acts to keep the system in the desired state.

Execution Sample

Kubernetes

apiVersion: example.com/v1
kind: MyApp
metadata:
  name: example-app
spec:
  replicas: 3

This YAML defines a custom resource 'MyApp' with 3 replicas, which the Operator will manage.

Process Table

Step	Action	Operator Reads	Comparison Result	Operator Action	Cluster State Change
1	Operator detects new CR 'example-app'	replicas=3	No actual state yet	Create 3 pods	3 pods created
2	Operator checks cluster state	replicas=3	Actual pods=3 matches desired	No action needed	State unchanged
3	User updates CR replicas to 5	replicas=5	Actual pods=3 less than desired	Create 2 more pods	5 pods running
4	Operator detects pod failure, actual pods=4	replicas=5	Actual pods=4 less than desired	Create 1 pod	5 pods running
5	User deletes CR 'example-app'	CR missing	Desired state gone	Delete all pods	Pods deleted
6	Operator sees no CR	No CR	No desired state	No action	Cluster idle

💡 Operator stops actions when no custom resource exists or desired state matches actual state.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6
Desired replicas	undefined	3	3	5	5	undefined	undefined
Actual pods	0	3	3	5	5	0	0
CR exists	false	true	true	true	true	false	false

Key Moments - 3 Insights

Why does the Operator create pods even if some pods already exist?

Because the Operator compares desired replicas with actual pods (see Step 3 and 4 in execution_table). If actual pods are fewer than desired, it creates more to match.

What happens when the custom resource is deleted?

The Operator detects no desired state (Step 5), so it deletes all related pods to clean up the cluster.

Does the Operator act if the actual state matches the desired state?

No, as shown in Step 2, when actual pods equal desired replicas, the Operator takes no action.

Visual Quiz - 3 Questions

Look at the execution table, what is the actual number of pods after Step 3?

A 5 pods

B 3 pods

C 4 pods

D 0 pods

💡 Hint

Check the 'Actual pods' column in variable_tracker after Step 3.

At which step does the Operator detect the custom resource has been deleted?

A Step 4

B Step 5

C Step 6

D Step 2

💡 Hint

Look at the 'CR exists' variable in variable_tracker and the 'Action' column in execution_table.

If the desired replicas were changed to 4 instead of 5 at Step 3, what would the Operator do?

A Delete 1 pod

B Create 2 more pods

C Create 1 more pod

D No action

💡 Hint

Compare desired vs actual pods in execution_table Step 3 and think about the difference.

Concept Snapshot

Operator pattern overview:
- User creates a Custom Resource (CR) defining desired state.
- Operator watches CR changes continuously.
- Operator compares desired state with actual cluster state.
- Operator takes actions to reconcile differences.
- When desired and actual states match, Operator waits.
- Deleting CR triggers cleanup by Operator.

Full Transcript

The Operator pattern in Kubernetes works by watching custom resources that users create to define how they want their applications to run. The Operator continuously checks the desired state from these resources and compares it with the actual state in the cluster. If there is a difference, such as fewer pods running than desired, the Operator takes action to fix it by creating or deleting pods. When the desired state matches the actual state, the Operator does nothing and waits for changes. If the user deletes the custom resource, the Operator cleans up by removing all related resources. This cycle repeats to keep the system stable and as the user wants.