Database operators example in Kubernetes - Mini Project: Build & Apply

Database Operators Example with Kubernetes

📖 Scenario: You are working as a DevOps engineer managing a Kubernetes cluster. Your team wants to deploy a PostgreSQL database using a Kubernetes Operator to simplify management tasks like backups and scaling.

🎯 Goal: Learn how to deploy a PostgreSQL database using a Kubernetes Operator by creating the necessary Kubernetes manifests step-by-step.

📋 What You'll Learn

Create a namespace for the database operator

Deploy the PostgreSQL Operator in the namespace

Create a PostgreSQL cluster custom resource

Verify the PostgreSQL pods are running

💡 Why This Matters

🌍 Real World

Kubernetes Operators automate complex application management tasks like deploying and managing databases in cloud environments.

💼 Career

DevOps engineers and SREs use Operators to simplify database lifecycle management, improving reliability and reducing manual work.

1

Create a namespace for the PostgreSQL Operator

Write a YAML manifest to create a Kubernetes namespace called postgres-operator. Use the apiVersion v1 and kind Namespace.

Kubernetes

# Write the YAML manifest to create the namespace
# Your code here

Hint

Namespaces isolate resources in Kubernetes. Use apiVersion: v1 and kind: Namespace with metadata name.

2

Deploy the PostgreSQL Operator in the namespace

Write a YAML manifest to deploy the PostgreSQL Operator as a Deployment named postgres-operator in the postgres-operator namespace. Use apps/v1 for apiVersion and specify 1 replica. Use the container image postgres-operator:latest.

Kubernetes

apiVersion: v1
kind: Namespace
metadata:
  name: postgres-operator

# Write the Deployment manifest for postgres-operator
# Your code here

Hint

Deployments manage pods. Use apps/v1 apiVersion, set replicas to 1, and specify the container image.

3

Create a PostgreSQL cluster custom resource

Write a YAML manifest for a PostgreSQL cluster custom resource named example-cluster in the postgres-operator namespace. Use apiVersion: postgres-operator.crunchydata.com/v1beta1 and kind: PostgresCluster. Set instances replicas to 1 and image to postgres:14.

Kubernetes

apiVersion: v1
kind: Namespace
metadata:
  name: postgres-operator
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-operator
  namespace: postgres-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres-operator
  template:
    metadata:
      labels:
        app: postgres-operator
    spec:
      containers:
      - name: postgres-operator
        image: postgres-operator:latest

# Write the PostgresCluster custom resource manifest
# Your code here

Hint

Custom resources define the database cluster. Use the correct apiVersion and kind, set replicas and image as specified.

4

Verify the PostgreSQL pods are running

Run the command kubectl get pods -n postgres-operator to list pods in the postgres-operator namespace. Confirm that the pod for example-cluster is in the Running state.

Kubernetes

apiVersion: v1
kind: Namespace
metadata:
  name: postgres-operator
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-operator
  namespace: postgres-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres-operator
  template:
    metadata:
      labels:
        app: postgres-operator
    spec:
      containers:
      - name: postgres-operator
        image: postgres-operator:latest
---
apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: example-cluster
  namespace: postgres-operator
spec:
  instances:
  - replicas: 1
  image:
    name: postgres:14

# Run the command below to check pods
# Your code here

Hint

Use kubectl get pods -n postgres-operator to see pods and their status.

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