Database operators example in Kubernetes - Step-by-Step Execution

Process Flow - Database operators example

Create Custom Resource Definition (CRD)

↓

Deploy Database Operator

↓

Create Database Custom Resource

↓

Operator Watches CR

↓

Operator Creates/Manages DB Pods

↓

Database Ready and Running

↓

Operator Monitors and Updates DB

↓

End

This flow shows how a Kubernetes database operator manages database lifecycle by watching custom resources and controlling pods.

Execution Sample

Kubernetes

apiVersion: databases.example.com/v1
kind: PostgresCluster
metadata:
  name: my-postgres
spec:
  instances: 3

This YAML creates a custom resource for a Postgres database cluster with 3 instances, which the operator will manage.

Process Table

Step	Action	Resource State	Operator Reaction	Result
1	Apply CRD for PostgresCluster	CRD created	Operator recognizes new resource type	Ready to manage PostgresCluster resources
2	Deploy Postgres Operator	Operator pod running	Operator starts watching PostgresCluster resources	Operator active
3	Create PostgresCluster resource with 3 instances	PostgresCluster resource created	Operator detects new resource	Starts creating 3 Postgres pods
4	Operator creates Postgres pod 1	Pod 1 Pending -> Running	Operator monitors pod status	Pod 1 ready
5	Operator creates Postgres pod 2	Pod 2 Pending -> Running	Operator monitors pod status	Pod 2 ready
6	Operator creates Postgres pod 3	Pod 3 Pending -> Running	Operator monitors pod status	Pod 3 ready
7	All pods running	Cluster ready	Operator ensures cluster health	Database cluster operational
8	Update PostgresCluster spec to 4 instances	Spec updated	Operator detects change	Creates 4th pod
9	Operator creates Postgres pod 4	Pod 4 Pending -> Running	Operator monitors pod status	Pod 4 ready
10	All 4 pods running	Cluster ready	Operator maintains cluster	Database cluster scaled
11	Delete PostgresCluster resource	Resource deleted	Operator deletes all pods	Cluster removed
12	All pods terminated	No pods running	Operator stops managing cluster	Cleanup complete

💡 PostgresCluster resource deleted, operator cleans up pods and stops managing cluster

Status Tracker

Variable	Start	After Step 3	After Step 7	After Step 10	Final
PostgresCluster.spec.instances	undefined	3	3	4	undefined
Postgres Pods Running	0	0	3	4	0
Operator State	Not running	Running	Running	Running	Running but idle

Key Moments - 3 Insights

Why does the operator create pods after the PostgresCluster resource is created?

Because the operator watches for new PostgresCluster resources (see execution_table step 3) and reacts by creating pods to match the requested instances.

What happens when the number of instances in the spec changes?

The operator detects the spec update (step 8) and adjusts the number of pods accordingly by creating or deleting pods to match the new count.

How does the operator clean up resources when the PostgresCluster is deleted?

When the resource is deleted (step 11), the operator deletes all associated pods and stops managing the cluster, completing cleanup (step 12).

Visual Quiz - 3 Questions

Look at the execution table, at which step does the operator first create a Postgres pod?

A Step 3

B Step 4

C Step 2

D Step 1

💡 Hint

Check the 'Operator Reaction' and 'Result' columns around steps 3 and 4.

According to the variable tracker, how many pods are running after step 7?

A 3

B 0

C 4

D Undefined

💡 Hint

Look at the 'Postgres Pods Running' row under 'After Step 7' column.

If the PostgresCluster spec.instances was changed from 3 to 5 instead of 4, what would the operator do?

A Do nothing

B Delete pods to reduce to 3

C Create 2 more pods to reach 5

D Delete all pods

💡 Hint

Refer to the behavior in steps 8-10 where the operator adjusts pods to match spec.instances.

Concept Snapshot

Database Operator in Kubernetes:
- Deploy operator and CRD first
- Create custom resource (e.g., PostgresCluster)
- Operator watches resource and creates/manages pods
- Changes in spec trigger operator to scale pods
- Deleting resource triggers cleanup
- Operator automates DB lifecycle management

Full Transcript

This visual execution shows how a Kubernetes database operator manages a Postgres database cluster. First, the Custom Resource Definition (CRD) is created so Kubernetes knows about the new resource type. Then the operator is deployed and starts watching for PostgresCluster resources. When a PostgresCluster resource is created with a spec requesting 3 instances, the operator reacts by creating 3 Postgres pods. It monitors their status until all are running and the cluster is ready. If the spec changes to request 4 instances, the operator creates an additional pod to scale up. When the PostgresCluster resource is deleted, the operator deletes all pods and cleans up. Variables like the number of running pods and operator state change step-by-step as shown. Key moments include understanding how the operator reacts to resource creation, spec changes, and deletion. The quizzes test understanding of when pods are created, pod counts at steps, and operator scaling behavior. This example demonstrates how operators automate database lifecycle in Kubernetes.

Practice

1. What is the main purpose of a database operator in Kubernetes?

easy

A. To manually configure database settings using kubectl commands

B. To monitor network traffic between pods

C. To replace the Kubernetes API server

D. To automate database management tasks like backups and scaling

Solution

1. Step 1: Understand the role of operators

   Operators automate complex tasks for applications running in Kubernetes, such as databases.

2. Step 2: Identify database operator tasks

   Database operators handle backups, scaling, and updates automatically without manual intervention.

3. Final Answer:

   To automate database management tasks like backups and scaling -> Option D

4. Quick Check:

   Database operator purpose = automate management [OK]

Hint: Operators automate tasks, not manual configs [OK]

Common Mistakes:

• Thinking operators replace Kubernetes API
• Confusing operators with manual commands
• Assuming operators monitor network traffic

2. Which YAML field is commonly used to specify the database version in a Kubernetes operator manifest?

easy

A. spec.replicas

B. spec.version

C. status.phase

D. metadata.name

Solution

1. Step 1: Review common YAML fields in operator manifests

   Database version is usually set under the spec section to define desired state.

2. Step 2: Identify the correct field for version

   The field spec.version is used to specify which database version to deploy.

3. Final Answer:

   spec.version -> Option B

4. Quick Check:

   Database version field = spec.version [OK]

Hint: Version info is under spec, not metadata or status [OK]

Common Mistakes:

• Using metadata.name for version
• Confusing status.phase with version
• Mistaking spec.replicas for version

3. Given this snippet of a PostgreSQL operator manifest:

apiVersion: postgres-operator.crunchydata.com/v1
kind: PostgresCluster
metadata:
  name: my-postgres
spec:
  instances:
    - replicas: 3
  backups:
    pgbackrest:
      repos:
        - name: repo1
          volume:
            volumeClaimSpec:
              accessModes: ["ReadWriteOnce"]
              resources:
                requests:
                  storage: 10Gi
  version: "14"

What does the replicas: 3 setting do?

medium

A. Sets the backup frequency to 3 times per day

B. Limits the database to 3 connections

C. Creates 3 PostgreSQL instances for high availability

D. Defines 3 storage volumes for backups

Solution

1. Step 1: Understand replicas in Kubernetes

   Replicas define how many copies of a pod or instance run for availability and load balancing.

2. Step 2: Apply to PostgreSQL operator

   replicas: 3 means 3 PostgreSQL instances will run, improving availability.

3. Final Answer:

   Creates 3 PostgreSQL instances for high availability -> Option C

4. Quick Check:

   replicas = number of instances [OK]

Hint: Replicas control instance count, not connections or backups [OK]

Common Mistakes:

• Confusing replicas with connection limits
• Thinking replicas set backup frequency
• Assuming replicas define storage volumes

4. You applied a YAML manifest for a MySQL operator but the pods fail to start. The manifest includes:

spec:
  replicas: 2
  version: "8.0"
  backup:
    enabled: true
    schedule: "0 2 * * *"

What is the likely error in this manifest?

medium

A. The field 'backup' should be 'backups' to match operator schema

B. The version number must be an integer, not a string

C. Replicas cannot be set to 2 for MySQL operator

D. Schedule format is invalid; cron must have 6 fields

Solution

1. Step 1: Check operator schema for backup configuration

   Most database operators expect 'backups' (plural) as the field name, not 'backup'.

2. Step 2: Validate other fields

   Version as string is valid, replicas can be 2, and cron with 5 fields is standard.

3. Final Answer:

   The field 'backup' should be 'backups' to match operator schema -> Option A

4. Quick Check:

   Field names must match operator schema exactly [OK]

Hint: Check exact field names in operator docs [OK]

Common Mistakes:

• Changing version to integer unnecessarily
• Assuming replicas must be 1
• Misunderstanding cron schedule format

5. You want to deploy a MongoDB cluster using a Kubernetes operator that supports automatic backups and scaling. Which combination of YAML fields is essential to enable these features correctly?

hard

A. spec:
replicas: 3
version: "5.0"
backups:
enabled: true
schedule: "0 1 * * *"
autoscaling:
enabled: true
minReplicas: 2
maxReplicas: 5

B. spec:
instances: 3
version: 5
backup:
schedule: daily
scaling:
enabled: yes

C. metadata:
replicas: 3
version: "5.0"
backups:
enabled: false
autoscale:
min: 2
max: 5

D. spec:
replicas: 1
version: "latest"
backup:
enabled: true
schedule: "@daily"
autoscaling:
enabled: false

Solution

1. Step 1: Identify correct field names and types for backups and scaling

   Backups require 'backups' with enabled and schedule fields; autoscaling needs enabled, minReplicas, maxReplicas.

2. Step 2: Compare options for correctness

   spec: replicas: 3 version: "5.0" backups: enabled: true schedule: "0 1 * * *" autoscaling: enabled: true minReplicas: 2 maxReplicas: 5 uses correct field names, proper YAML structure, and valid values for version and schedule.

3. Final Answer:

   spec: replicas: 3 version: "5.0" backups: enabled: true schedule: "0 1 * * *" autoscaling: enabled: true minReplicas: 2 maxReplicas: 5 -> Option A

4. Quick Check:

   Correct fields and values enable features [OK]

Hint: Use exact field names and valid cron schedules [OK]

Common Mistakes:

• Using 'backup' instead of 'backups'
• Incorrect autoscaling field names
• Setting enabled false disables features