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.

Practice

1. What is the main purpose of the Kubernetes Operator pattern?

easy

A. To replace Kubernetes core components

B. To automate application management tasks on Kubernetes

C. To manually configure pods and services

D. To monitor network traffic between nodes

Solution

1. Step 1: Understand the Operator pattern role

   The Operator pattern automates tasks like deployment, scaling, and updates for applications on Kubernetes.

2. Step 2: Compare options with the pattern's purpose

   Only To automate application management tasks on Kubernetes describes automation of app management, which matches the Operator's goal.

3. Final Answer:

   To automate application management tasks on Kubernetes -> Option B

4. Quick Check:

   Operator automates app management = A [OK]

Hint: Operators automate apps, not replace Kubernetes core [OK]

Common Mistakes:

• Thinking Operators replace Kubernetes components
• Confusing manual config with automation
• Assuming Operators handle network monitoring

2. Which Kubernetes resource is essential for an Operator to manage custom application logic?

easy

A. Pod

B. Service

C. Custom Resource Definition (CRD)

D. ConfigMap

Solution

1. Step 1: Identify resource for extending Kubernetes

   Operators use Custom Resource Definitions (CRDs) to add new resource types representing app-specific data.

2. Step 2: Match resource with Operator management

   CRDs enable Operators to watch and act on custom resources, unlike Pods, Services, or ConfigMaps.

3. Final Answer:

   Custom Resource Definition (CRD) -> Option C

4. Quick Check:

   CRD extends Kubernetes for Operators = B [OK]

Hint: CRDs define custom resources Operators manage [OK]

Common Mistakes:

• Choosing Pod or Service which are standard resources
• Confusing ConfigMap with custom resource definitions
• Not knowing CRD extends Kubernetes API

3. Given this Operator controller snippet watching a custom resource, what will happen when a new resource instance is created?

func (r *MyOperatorReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    var app MyApp
    if err := r.Get(ctx, req.NamespacedName, &app); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }
    // Logic to create or update deployment based on app spec
    return ctrl.Result{}, nil
}

medium

A. The Operator will crash due to missing deployment code

B. The Operator will delete the custom resource immediately

C. The Operator will ignore the new resource and do nothing

D. The Operator will create or update a deployment matching the custom resource spec

Solution

1. Step 1: Analyze Reconcile function behavior

   The function fetches the custom resource and applies logic to create or update a deployment accordingly.

2. Step 2: Understand Operator reaction to resource creation

   When a new resource instance is created, the Operator reconciles state by creating/updating deployments to match spec.

3. Final Answer:

   The Operator will create or update a deployment matching the custom resource spec -> Option D

4. Quick Check:

   Reconcile creates/updates deployment = A [OK]

Hint: Reconcile syncs resources to desired state [OK]

Common Mistakes:

• Thinking Operator deletes resource on creation
• Assuming Operator ignores new resources
• Believing missing code causes crash here

4. You wrote an Operator but it never reacts to changes in your custom resource. What is the most likely cause?

medium

A. The Operator's controller is not watching the Custom Resource Definition

B. The Kubernetes cluster is down

C. The custom resource YAML is invalid and rejected

D. The Operator is missing RBAC permissions for Pods

Solution

1. Step 1: Identify why Operator ignores resource changes

   If the controller does not watch the custom resource, it won't get events to trigger reconciliation.

2. Step 2: Compare other options

   Cluster down or invalid YAML would cause errors, not silent ignoring. Missing Pod RBAC affects pod actions, not event watching.

3. Final Answer:

   The Operator's controller is not watching the Custom Resource Definition -> Option A

4. Quick Check:

   Controller watch missing = no reactions = D [OK]

Hint: Ensure controller watches CRD to react to changes [OK]

Common Mistakes:

• Assuming cluster down without checking logs
• Blaming YAML without validation errors
• Confusing RBAC for Pods with watching permissions

5. You want to build an Operator that manages a database cluster with automatic backups and scaling. Which two Kubernetes concepts must you combine to implement this Operator effectively?

hard

A. Custom Resource Definitions and Controllers

B. ConfigMaps and Secrets

C. Ingress and Network Policies

D. DaemonSets and StatefulSets

Solution

1. Step 1: Identify core Operator components

   Operators use Custom Resource Definitions (CRDs) to define new resource types and Controllers to manage their lifecycle.

2. Step 2: Evaluate other Kubernetes concepts

   ConfigMaps and Secrets store config data, Ingress and Network Policies manage traffic, DaemonSets and StatefulSets manage pods but don't implement custom logic.

3. Final Answer:

   Custom Resource Definitions and Controllers -> Option A

4. Quick Check:

   CRDs + Controllers build Operators = C [OK]

Hint: Operators = CRDs + Controllers for custom logic [OK]

Common Mistakes:

• Confusing config storage with Operator logic
• Mixing networking resources with Operator pattern
• Thinking pod controllers alone build Operators