Velero

Installiert Velero im Cluster.

Sollte restic prune mit einem signal: killed beendet werden, muss block.config.resource.limits.memory und block.config.nodeagent.resource.limits.memory erhöht werden.

upgradecrds – kubectl-Image

Der Velero upgradecrds-Job nutzt ein kubectl-Container-Image für CRD-Upgrades. Das Chart leitet den Image-Tag standardmäßig von der Kubernetes-Cluster-Version ab.

Problem: Seit dem Bitnami-Brownout 2025/2026 (Migration von docker.io/bitnami zu docker.io/bitnamilegacy, keine neuen Tags) existiert für neuere K8s-Versionen (z.B. 1.34) oft kein passendes Image. Der Job fällt mit ImagePullBackOff aus.

Lösung: Default-Repository ist registry.k8s.io/kubectl (kein Bitnami-Tag mehr). Ein Tag ist optional; ohne Tag nutzt das Chart den Cluster-kompatiblen kubectl. Überschreiben:

config:
  upgradecrds:
    kubectl:
      repository: registry.k8s.io/kubectl
      # tag: "v1.33.4"  # optional

Node taints / Data-Mover-Pods

Der Node-Agent-DaemonSet toleriert im Default alle NoSchedule/NoExecute-Taints (operator: Exists).

Velero 1.18.x kopiert auf Data-Mover- und PVB-Exposer-Pods nur Tolerations mit diesen Keys:

CriticalAddonsOnly
kubernetes.azure.com/scalesetpriority

Ohne expliziten Key CriticalAddonsOnly auf dem DaemonSet schlagen Exposer-Pods auf Control-Plane-Nodes fehl (Predicate TaintToleration failed). Das Backup bleibt dann InProgress, bis fs_backup_timeout / item_operation_timeout.

Custom-Taints (mssql, mongodb, …) stehen in den Defaults für den DaemonSet und für spätere Velero-Versionen (inherit-all, PR #9575). In 1.18.x werden sie nicht auf Data-Mover-Pods kopiert. Weitere Keys im Workspace setzen — die Liste ersetzt den Default:

config:
  nodeagent:
    tolerations:
      - key: CriticalAddonsOnly
        operator: Exists
        effect: NoExecute
      - key: mssql
        operator: Equal
        value: "true"
        effect: NoExecute
      - operator: Exists
        effect: NoExecute
      - operator: Exists
        effect: NoSchedule

Changelog

Siehe CHANGELOG.poly

actions

install

Mit config.nodeagent.password wird das Passwort zum verschlüsseln der Backups definiert.

Der Wert config.scheduled_backups.ttl gibt an, wie lange ein Backup aufbewahrt werden soll bis es gelöscht wird. Wird kein Wert angegeben, ist der Default 30 Tage (720 Stunden)

Der Wert config.scheduled_backups.schedule gibt an, wann ein zeitplangesteuertes Backup ausgeführt werden soll. Mit folgender Seite kann man einen Zeitplan erstellen/prüfen crontab.guru

Beispielkonfiguration mit minio als s3 und Backup angegebener Namespaces

Sichert alle Kubernetes Objekte und Volumes welche nich in exclude_namespaces angegeben wurden.

blocks:
  - name: velero
    from: cargo.ayedo.cloud/ayedo/k8s/velero
    kubeconfig:
      from: k8s
    config:
      namespace: velero
      nodeagent:
        password: "randomPasswordHere"
      s3:
        username: "yourS3Username-Key"
        password: "yourS3Password-Token"
      backup_location:
        name: "displayNameInK8s"
        bucket: "bucketname"
        region: "minio"
        force_path_style: true
        url: "https://s3.example.com"
        # Wird ggf. benötigt, wenn die Backups mit "The provided 'x-amz-content-sha256' header does not match what was computed." fehlschlagen
        disablechecksum: true
      scheduled_backups:
        disabled: false
        weekly_disabled: false
        namespaces: [] # leer = alle Namespaces (nicht include_namespaces)
        excluded_namespaces:
          - default
          - gitlab-runner
          - ingress
          - kube-node-lease
          - kube-public
          - kube-system
          - kubernetes-event-exporter
          - polycrate
          - velero
          # - victoria-metrics-stack
          # - victoria-logs
        # ttl: "72h0m0s" default
        schedule: "0 */12 * * *"
        parallel_files_upload: 10
        item_operation_timeout: "12h"
        # weekly_schedule: "0 2 * * 0" # default
        # weekly_ttl: "672h" default
        include_crds: true
      snapshotLocation: {}

Beispielkonfiguration mit minio als s3 und Backup über label_selector

Sichert alle Kubernetes Objekte und Volumes die ein label velero haben.

blocks:
  - name: velero
    from: cargo.ayedo.cloud/ayedo/k8s/velero
    kubeconfig:
      from: k8s
    config:
      namespace: velero
      nodeagent:
        password: "randomPasswordHere"
      s3:
        username: "yourS3Username-Key"
        password: "yourS3Password-Token"
      backup_location:
        name: "displayNameInK8s"
        bucket: "bucketname"
        region: "minio"
        force_path_style: true
        url: "https://s3.example.com"
      scheduled_backups:
        disabled: false
        weekly_disabled: false
        label_selector:
          enabled: true
          match_labels:
            backup: velero
        # ttl: "72h0m0s" default
        schedule: "0 */12 * * *"
        # parallel_files_upload: 5 # default
        item_operation_timeout: "12h"
        # weekly_schedule: "0 2 * * 0" # default
        # weekly_ttl: "672h" default
        include_crds: true
      snapshotLocation: {}

uninstall

Deinstalliert Velero vom Cluster.

Backups werden nicht gelöscht. Alte Backups werden nicht mehr aufgeräumt.

Wird Velero mit identischen Daten neu installiert, werden die vorhandenen Backups nach einiger Zeit im Cluster wieder angezeigt.

polycrate run velero uninstall