Pod Annotations Examples

Here are a few examples demonstrating how to set up Bacula annotations within Kubernetes Pods.

When dealing with Kubernetes deployments, the annotations must be placed in the Pod template’s specification, or .template.spec field:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
    tier: mysql
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
      annotations:
        bacula/backup.mode: standard
        bacula/backup.volumes: mysql-pv-claim
    spec:
      containers:
        - image: mysql:5.6
          name: mysql
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: changeme
          ports:
            - containerPort: 3306
              name: mysql
          volumeMounts:
            - name: mysql-persistent-storage
              mountPath: /var/lib/mysql
      volumes:
        - name: mysql-persistent-storage
          persistentVolumeClaim:
            claimName: mysql-pv-claim

In the example below you will use a simple Linux command sync to synchronize cached writes to persistent storage before volume cloning.

apiVersion: v1
kind: Pod
metadata:
   name: app1
   namespace: default
   annotations:
   bacula/backup.mode: clone
   bacula/run.before.job.container.command: "*/sync -f /data1; sync -f /data2"
   bacula/run.before.job.failjobonerror: "no"
   bacula/backup.volumes: "pvc1,pvc2"
spec:
   containers:
   - image: ubuntu:latest
     name: test-container
     volumeMounts:
       - name: pvc1
         mountPath: /data1
       - name: pvc2
         mountPath: /data2
   volumes:
     - name: pvc1
       persistentVolumeClaim:
         claimName: pvc1
     - name: pvc2
       persistentVolumeClaim:
         claimName: pvc2

In the example below you will use PostgreSQL’s database data files quiesce feature to perform consistent backup with volume cloning.

Note

The final PostgreSQL backup solution requires more configuration and preparation which was skipped in this example to make it clearer.

The initial directive (run.before.job.container.command) halts any updates to the database files, while the subsequent instruction (run.after.snapshot.container.command) restores normal database functionality once the PVC volume cloning process is completed.

apiVersion: v1
kind: Pod
metadata:
  name: postgresql13
  namespace: default
  annotations:
    bacula/backup.mode: standard
    bacula/run.before.job.container.command: "*//bin/startpgsqlbackup.sh"
    bacula/run.after.snapshot.container.command: "*//bin/stoppgsqlbackup.sh"
    bacula/run.after.snapshot.failjobonerror: "yes"
    bacula/backup.volumes: "pgsql"
spec:
   containers:
   - image: postgresql:13
     name: postgresql-server
     volumeMounts:
       - name: pgsql
         mountPath: /var/lib/pgsql
     volumes:
       - name: pgsql
         persistentVolumeClaim:
           claimName: pgsql-volume

All PVCs defined with this storage class will perform backups using snapshots as per this storage definition.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-hostpath-sc
provisioner: hostpath.csi.k8s.io
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: plugintest-persistent-volume-claim-csi
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-hostpath-sc