Database operators example in Kubernetes - Commands & Configuration

Introduction

Managing databases in Kubernetes can be complex because databases need special care for storage and backups. Database operators help automate these tasks so your database runs smoothly without manual work.

When you want to run a PostgreSQL database inside Kubernetes with automatic backups and scaling.

When you need to manage a MySQL database that recovers automatically after failures.

When you want to deploy a MongoDB cluster with easy updates and monitoring inside Kubernetes.

When you want to avoid manual setup of persistent storage and configuration for your database.

When you want your database to be managed like any other Kubernetes resource with simple commands.

Config File - postgres-operator.yaml

postgres-operator.yaml

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: my-postgres
  namespace: default
spec:
  instances:
    - name: instance1
      replicas: 1
  backups:
    pgbackrest:
      repos:
        - name: repo1
          volume:
            volumeClaimSpec:
              accessModes:
                - ReadWriteOnce
              resources:
                requests:
                  storage: 1Gi
  storage:
    volumes:
      - name: data
        volumeClaimSpec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 1Gi

This YAML file defines a PostgreSQL cluster managed by the Crunchy Data Postgres Operator.

apiVersion and kind specify the operator resource type.

metadata names the cluster.

spec.instances defines one instance with one replica.

spec.backups configures backup storage using pgBackRest.

spec.storage sets persistent storage for the database data.

Commands

This command creates the PostgreSQL cluster resource in Kubernetes using the operator. It tells Kubernetes to start managing the database with the settings in the YAML file.

Terminal

kubectl apply -f postgres-operator.yaml

Expected Output

postgrescluster.postgres-operator.crunchydata.com/my-postgres created

This command lists the pods created by the operator for the PostgreSQL cluster to check if the database is running.

Terminal

kubectl get pods -l postgres-operator.crunchydata.com/cluster=my-postgres

Expected Output

NAME                                READY   STATUS    RESTARTS   AGE

my-postgres-instance1-0              1/1     Running   0          30s

→

-l - Filter pods by label to show only those belonging to the PostgreSQL cluster

This command shows detailed information about the PostgreSQL cluster resource, including status, events, and conditions managed by the operator.

Terminal

kubectl describe postgrescluster my-postgres

Expected Output

Name:         my-postgres

Namespace:    default

Labels:       

Annotations:  

API Version:  postgres-operator.crunchydata.com/v1beta1

Kind:         PostgresCluster

Spec:

  Instances:

    Name:      instance1

    Replicas:  1

  Storage:

    Volumes:

      Name: data

      Storage Request: 1Gi

Status:

  State: Running

Events:

  Type    Reason             Age   From                       Message

  ----    ------             ----  ----                       -------

  Normal  SuccessfulCreate   1m    postgres-operator-controller  Created pod my-postgres-instance1-0

Key Concept

If you remember nothing else from this pattern, remember: database operators automate complex database tasks inside Kubernetes so you can manage databases like regular apps.

Common Mistakes

Applying the operator resource without installing the database operator first

Kubernetes does not recognize the custom resource and returns an error because the operator controller is missing.

Install the database operator in the cluster before applying any database custom resources.

Not specifying persistent storage in the YAML file

The database pods will not have storage to save data, causing data loss on pod restarts.

Always define persistent volume claims in the storage section to keep data safe.

Summary

Create a database cluster resource YAML file for the operator to manage.

Apply the YAML file with kubectl to start the database cluster.

Check pods with kubectl get pods to verify the database is running.

Use kubectl describe on the cluster resource to see detailed status and events.

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