Wie man Backup und Wiederherstellung mit TrilioVault in DOKS durchführt

Einführung

In diesem Tutorial erfahren Sie, wie Sie TrilioVault für Kubernetes (oder TVK) in Ihrem DOKS-Cluster bereitstellen, Backups erstellen und sich von einem Backup wiederherstellen können, wenn etwas schief geht. Sie können Ihren gesamten Cluster sichern oder optional Backups auf Namespace- oder Label-Basis auswählen.

Vorteile der Verwendung von Trilio:

• Erstellen Sie vollständige (oder inkrementelle) Backups Ihres Clusters und stellen Sie sie im Falle eines Datenverlusts wieder her.
• Wechseln Sie von einem Cluster zu einem anderen.
• Helm-Release-Backups werden unterstützt.
• Führen Sie vor und nach den Sicherungs- und Wiederherstellungsvorgängen Vor- und Nachhaken aus.
• Web-Verwaltungskonsole, mit der Sie den Status Ihrer Backup-/Wiederherstellungsvorgänge im Detail überprüfen können.
• Definieren Sie Aufbewahrungsrichtlinien für Ihre Backups.
• Die Anwendungslebensdauer (das bedeutet TVK selbst) kann über einen dedizierten TrilioVault-Operator verwaltet werden.
• Velero-Integration.
• Sie können anwendungsbezogene Backups und Wiederherstellungen durchführen.

Weitere Informationen finden Sie in der offiziellen Dokumentation zu den TVK CRDs.

Inhaltsverzeichnis

• Voraussetzungen
• Schritt 1 – Installation von TrilioVault für Kubernetes
• Schritt 2 – Erstellen eines TrilioVault-Ziels zum Speichern von Backups
• Schritt 3 – Kennenlernen der TVK-Webverwaltungskonsole
• Schritt 4 – Beispiel für Backup und Wiederherstellung im Namespace
• Schritt 5 – Beispiel für Backup und Wiederherstellung des gesamten Clusters
• Schritt 6 – Geplante Backups
• Schritt 7 – Sicherungsretentionsrichtlinie
• Abschluss

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie folgendes:

1. A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
2. A Git client to clone the Starter Kit repository.
3. Helm zur Verwaltung von TrilioVault Operator-Versionen und Upgrades.
4. Doctl für die Interaktion mit der DigitalOcean-API.
5. Kubectl für die Interaktion mit Kubernetes.

Damit TrilioVault ordnungsgemäß funktioniert und Ihre PVCs sichern kann, muss DOKS so konfiguriert sein, dass es das Container Storage Interface (CSI) unterstützt. Standardmäßig wird der Treiber bereits installiert und konfiguriert mitgeliefert. Sie können dies mit dem folgenden Befehl überprüfen:

kubectl get storageclass

Die Ausgabe sollte ähnlich aussehen wie der folgende Ausschnitt. Beachten Sie, dass der Bereitsteller dobs.csi.digitalocean.com ist.

NAME                         PROVISIONER                 RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
do-block-storage (default)   dobs.csi.digitalocean.com   Delete          Immediate           true                   10d

Die Installation von TrilioVault erfordert auch die benutzerdefinierte Ressourcendefinition (CRD) volumeSnapshot für eine erfolgreiche Installation. Sie können dies mit dem folgenden Befehl überprüfen:

kubectl get crd | grep volumesnapshot

Die Ausgabe sollte ähnlich aussehen wie der folgende Ausschnitt. Wenn die CRD VolumeSnapshot nicht installiert ist, siehe Installieren von VolumeSnapshot CRDs.

volumesnapshotclasses.snapshot.storage.k8s.io         2022-02-01T06:01:14Z
volumesnapshotcontents.snapshot.storage.k8s.io        2022-02-01T06:01:14Z
volumesnapshots.snapshot.storage.k8s.io               2022-02-01T06:01:15Z

Außerdem stellen Sie sicher, dass die CRD beide API-Versionen v1beta1 und v1 unterstützt. Sie können den folgenden Befehl ausführen, um die API-Version zu überprüfen:

kubectl get crd volumesnapshots.snapshot.storage.k8s.io -o yaml

Am Ende des CRD-YAML sollte eine storedVersions-Liste stehen, die sowohl v1beta1 als auch v1 Werte enthält (falls nicht installiert, siehe Installieren von VolumeSnapshot CRDs):

...
- lastTransitionTime: "2022-01-20T07:58:06Z"
    message: approved in https://github.com/kubernetes-csi/external-snapshotter/pull/419
    reason: ApprovedAnnotation
    status: "True"
    type: KubernetesAPIApprovalPolicyConformant
  storedVersions:
  - v1beta1
  - v1

Schritt 1 – Installation von TrilioVault für Kubernetes

In diesem Schritt lernen Sie, wie Sie TrilioVault für DOKS bereitstellen und TVK-Installationen über Helm verwalten. Die Sicherungsdaten werden im DO Spaces-Bucket gespeichert, der zuvor im Abschnitt Voraussetzungen erstellt wurde.

Die TrilioVault-Anwendung kann auf verschiedene Arten installiert werden:

• Über den TrilioVault Operator. Dabei definieren Sie eine TrilioVaultManager-CRD, die dem TrilioVault-Operator mitteilt, wie die Installation, Nachkonfigurationsschritte und zukünftige Upgrades der Trilio-Anwendungskomponenten gehandhabt werden sollen.
• Über das triliovault-operator-Chart, das vollständig von Helm verwaltet wird (in diesem Tutorial behandelt).

TrilioVault mit Helm installieren

Zuerst klonen Sie das Starter Kit Git-Repository und wechseln in das Verzeichnis Ihrer lokalen Kopie:

git clone https://github.com/digitalocean/Kubernetes-Starter-Kit-Developers.git
cd Kubernetes-Starter-Kit-Developers

Anschließend fügen Sie das TrilioVault Helm-Repository hinzu und listen die verfügbaren Charts auf:

helm repo add triliovault-operator http://charts.k8strilio.net/trilio-stable/k8s-triliovault-operator
helm repo update triliovault-operator
helm search repo triliovault-operator

Die Ausgabe ähnelt dem Folgenden:

NAME                                            CHART VERSION   APP VERSION     DESCRIPTION
triliovault-operator/k8s-triliovault-operator   2.9.2           2.9.2           K8s-TrilioVault-Operator is an operator designe...

Öffnen und überprüfen Sie dann die TrilioVault Helm-Werte-Datei, die im Starterkit-Repository bereitgestellt wird, mit einem Editor Ihrer Wahl (bevorzugt mit YAML-Lint-Unterstützung).

code 05-setup-backup-restore/assets/manifests/triliovault-values-v2.9.2.yaml

Installieren Sie TrilioVault für Kubernetes schließlich mit Helm:

helm install triliovault-operator triliovault-operator/k8s-triliovault-operator \
  --namespace tvk \
  --create-namespace \
  -f 05-setup-backup-restore/assets/manifests/triliovault-values.yaml

installTVK.ComponentConfiguration.ingressController.service.type für den Servicetyp zum Zugriff auf die TVK-Benutzeroberfläche z.B. NodePort oder LoadBalancer

helm ls -n tvk

Überprüfen Sie nun Ihre TVK-Bereitstellung:

NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
triliovault-manager-tvk tvk             1               2022-06-08 08:30:08.490304959 +0000 UTC deployed        k8s-triliovault-2.9.2           2.9.2
triliovault-operator    tvk             1               2022-06-08 11:32:55.755395 +0300 EEST   deployed        k8s-triliovault-operator-2.9.2  2.9.2

Die Ausgabe sieht ähnlich wie der folgende Ausschnitt aus (die STATUS-Spalte sollte deployed anzeigen):

kubectl get deployments -n tvk

Als nächstes überprüfen Sie, ob TrilioVault läuft und einsatzbereit ist:

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
k8s-triliovault-admission-webhook               1/1     1            1           83s
k8s-triliovault-control-plane                   1/1     1            1           83s
k8s-triliovault-exporter                        1/1     1            1           83s
k8s-triliovault-ingress-nginx-controller        1/1     1            1           83s
k8s-triliovault-web                             1/1     1            1           83s
k8s-triliovault-web-backend                     1/1     1            1           83s
triliovault-operator-k8s-triliovault-operator   1/1     1            1           4m22s

Die Ausgabe sieht ähnlich wie der folgende Ausschnitt aus. Alle Bereitstellungspods müssen den Zustand Ready haben.

Wenn die Ausgabe so aussieht, haben Sie TVK erfolgreich installiert. Als nächstes erfahren Sie, wie Sie den Lizenztyp und die Gültigkeit überprüfen und wie Sie sie erneuern können.

TrilioVault-Anwendungs Lizenzierung

Beispiele für Starter-Kits basieren auf dem Lizenztyp Cluster, um ordnungsgemäß zu funktionieren.

Erstellung und Überprüfung der TVK-Anwendungslizenz

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/tvk_install_license.yaml

Führen Sie den folgenden Befehl aus, um eine neue Lizenz für Ihren Cluster zu erstellen (diese wird über den License CRD verwaltet):

kubectl apply -f <YOUR_LICENSE_FILE_NAME>.yaml -n tvk

Wenn Sie eine kostenlose Lizenz von der Trilio-Website herunterladen, wenden Sie sie mit diesem Befehl an:

kubectl get license -n tvk

Bitte führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Lizenz auf Ihrem Cluster installiert und im Aktiv-Zustand ist.

NAME             STATUS   MESSAGE                                   CURRENT NODE COUNT   GRACE PERIOD END TIME   EDITION     CAPACITY   EXPIRATION TIME        MAX NODES
test-license-1   Active   Cluster License Activated successfully.   1                                            FreeTrial   100000     2023-02-25T00:00:00Z   1

Die Ausgabe sieht ähnlich wie folgt aus. Beachten Sie den STATUS, der Aktiv sein sollte, sowie den Lizenztyp in der EDITION-Spalte und die Ablaufzeit.

kubectl describe license test-license-1 -n tvk

Die Lizenz wird über einen speziellen CRD mit dem Namen License verwaltet. Sie können ihn inspizieren, indem Sie den folgenden Befehl ausführen:

Name:         test-license-1
Namespace:    tvk
Labels:       <none>
Annotations:
              generation: 1
              triliovault.trilio.io/creator: system:serviceaccount:tvk:k8s-triliovault
              triliovault.trilio.io/instance-id: b060660d-4851-482b-8e60-4addd260e1d3
              triliovault.trilio.io/updater:
                [{"username":"system:serviceaccount:tvk:k8s-triliovault","lastUpdatedTimestamp":"2022-02-24T06:38:21.418828262Z"}]
API Version:  triliovault.trilio.io/v1
Kind:         License
Metadata:
  Creation Timestamp:  2022-02-24T06:38:21Z
...
Status:
  Condition:
    Message:           License Key changed
    Timestamp:         2022-02-24T06:38:21Z
    Message:           Cluster License Activated successfully.
    Status:            Active
    Timestamp:         2022-02-24T06:38:21Z
  Current Node Count:  1
  Max Nodes:           1
  Message:             Cluster License Activated successfully.
  Properties:
    Active:                        true
    Capacity:                      100000
    Company:                       TRILIO-KUBERNETES-LICENSE-GEN-DIGITALOCEAN-BASIC
    Creation Timestamp:            2022-02-24T00:00:00Z
    Edition:                       FreeTrial
    Expiration Timestamp:          2023-02-25T00:00:00Z
    Kube UID:                      b060660d-4851-482b-8e60-4addd260e1d3
    License ID:                    TVAULT-5a4b42c6-953c-11ec-8116-0cc47a9fd48e
    Maintenance Expiry Timestamp:  2023-02-25T00:00:00Z
    Number Of Users:               -1
    Purchase Timestamp:            2022-02-24T00:00:00Z
    Scope:                         Cluster
...

Die Ausgabe sieht ähnlich wie folgt aus. Beachten Sie die Felder Nachricht und Kapazität sowie die Edition.

Die obige Ausgabe wird Ihnen auch mitteilen, wann die Lizenz im Feld Ablaufzeitstempel abläuft, und den Geltungsbereich (Cluster in diesem Fall). Sie können sich für einen lizenztypischen Cluster oder eine lizenztypische Namespace-Option entscheiden.

Erneuerung der TVK-Anwendungslizenz

kubectl apply -f <YOUR_LICENSE_FILE_NAME>.yaml -n tvk

Um die Lizenz zu erneuern, müssen Sie eine neue von der Trilio-Website anfordern, indem Sie zur Lizenzierungsseite navigieren, um die alte zu ersetzen. Nachdem Sie das Formular ausgefüllt haben, sollten Sie das Lizenz-YAML-Manifest erhalten, das mit kubectl auf Ihren Cluster angewendet werden kann. Die folgenden Befehle gehen davon aus, dass TVK im Standard-Namespace tvk installiert ist (ersetzen Sie bitte die Platzhalter <> entsprechend, wo erforderlich):

Dann können Sie den neuen Lizenzstatus überprüfen, wie Sie bereits gelernt haben:
kubectl get license -n tvk

# Zuerst verfügbare TVK-Lizenzen aus dem Namespace `tvk` auflisten
kubectl describe license <YOUR_LICENSE_NAME_HERE> -n tvk

# Informationen über eine bestimmte Lizenz aus dem Namespace `tvk` abrufen

Im nächsten Schritt erfahren Sie, wie Sie das Speicher-Backend für TrilioVault definieren, um Backups zu speichern, das als Ziel bezeichnet wird.

Schritt 2 – Erstellen eines TrilioVault-Ziels zur Speicherung von Backups

A typical Target definition looks like:

apiVersion: triliovault.trilio.io/v1
kind: Target
metadata:
  name: trilio-s3-target
  namespace: tvk
spec:
  type: ObjectStore
  vendor: Other
  enableBrowsing: true
  objectStoreCredentials:
    bucketName: <YOUR_DO_SPACES_BUCKET_NAME_HERE>
    region: <YOUR_DO_SPACES_BUCKET_REGION_HERE>
    url: 'https://<YOUR_DO_SPACES_BUCKET_ENDPOINT_HERE>'
    credentialSecret:
      name: trilio-s3-target
      namespace: tvk
  thresholdCapacity: 10Gi

TrilioVault muss zunächst wissen, wo Ihre Backups gespeichert werden sollen. TrilioVault bezieht sich auf das Speicher-Backend, indem es den Begriff target verwendet, und es wird über eine spezielle CRD mit dem Namen Target verwaltet. Die folgenden Zieltypen werden unterstützt: S3 und NFS. Für DigitalOcean und den Zweck des Starter Kits ist es sinnvoll, auf den Speichertyp S3 zu setzen, da er kostengünstig und skalierbar ist. Um von einem verbesserten Schutzniveau zu profitieren, können Sie mehrere Zieltypen (für sowohl S3 als auch NFS) erstellen, sodass Ihre Daten an mehreren Orten sicher aufbewahrt werden und somit eine Backup-Redundanz erreicht wird.

• In dieser Konfiguration,
• spec.type: Typ des Ziels für die Backup-Speicherung (S3 ist ein Objektspeicher).
• spec.vendor: Drittanbieter-Speicheranbieter, der das Ziel hostet (für DigitalOcean Spaces müssen Sie anstelle von AWS Other verwenden).
• spec.enableBrowsing: Aktivieren des Browsens für das Ziel.
• spec.objectStoreCredentials: Definiert erforderliche Anmeldeinformationen (über credentialSecret) zum Zugriff auf den S3-Speicher sowie andere Parameter wie Bucket-Region und -Namen.

spec.thresholdCapacity: Maximale Schwellenkapazität zur Speicherung von Backup-Daten.

apiVersion: v1
kind: Secret
metadata:
  name: trilio-s3-target
  namespace: tvk
type: Opaque
stringData:
  accessKey: <YOUR_DO_SPACES_ACCESS_KEY_ID_HERE> Um auf den S3-Speicher zuzugreifen, muss jedes Ziel die Bucket-Anmeldeinformationen kennen. Es muss auch ein Kubernetes Secret erstellt werden:
  secretKey: <YOUR_DO_SPACES_SECRET_KEY_HERE>    # Wert muss base64-codiert sein

# Wert muss base64-codiert sein

Beachten Sie, dass der Name des Secrets trilio-s3-target ist und es vom Feld spec.objectStoreCredentials.credentialSecret des zuvor erklärten Target CRD referenziert wird. Das Secret kann sich im selben Namespace befinden, in dem TrilioVault installiert wurde (Standardwert ist tvk), oder in einem anderen Namespace Ihrer Wahl. Stellen Sie nur sicher, dass Sie den Namespace korrekt referenzieren. Andererseits stellen Sie bitte sicher, dass Sie den Namespace, in dem Sie TrilioVault-Secrets speichern, aus Sicherheitsgründen über RBAC schützen.

Schritte zum Erstellen eines Ziels für TrilioVault:

cd Kubernetes-Starter-Kit-Developers

Zuerst wechseln Sie in das Verzeichnis, in dem das Git-Repository des Starter Kits auf Ihrem lokalen Rechner geklont wurde:

kubectl create secret generic trilio-s3-target \
  --namespace=tvk \
  --from-literal=accessKey="<YOUR_DO_SPACES_ACCESS_KEY_HERE>" \
  --from-literal=secretKey="<YOUR_DO_SPACES_SECRET_KEY_HERE>"

Dann erstellen Sie das Kubernetes-Secret, das Ihre Ziel-S3-Bucket-Anmeldeinformationen enthält (ersetzen Sie bitte die Platzhalter <> entsprechend):

code 05-setup-backup-restore/assets/manifests/triliovault/triliovault-s3-target.yaml

–from-literal=accessKey=„<IHR_DO_SPACES_ACCESS_KEY_HIER>“ \

–from-literal=secretKey=„<IHR_DO_SPACES_SECRET_KEY_HIER>“

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/triliovault-s3-target.yaml

Dann öffnen und inspizieren Sie die Zielmanifestdatei im Starter-Kit-Repository mit einem Editor Ihrer Wahl (vorzugsweise mit YAML-Lint-Unterstützung).

Jetzt ersetzen Sie bitte die <>-Platzhalter entsprechend für Ihren DO Spaces Trilio-Bucket, wie bucketName, region, url und credentialSecret.

kubectl get target trilio-s3-target  -n tvk

Speichern Sie schließlich die Manifestdatei und erstellen Sie das Zielobjekt mit kubectl:

NAME               TYPE          THRESHOLD CAPACITY   VENDOR   STATUS      BROWSING ENABLED
trilio-s3-target   ObjectStore   10Gi                 Other    Available

Als nächstes wird TrilioVault einen Arbeitsjob namens trilio-s3-target-validator starten, der für die Validierung Ihres S3-Buckets (z. B. Verfügbarkeit, Berechtigungen usw.) verantwortlich ist. Wenn der Job erfolgreich abgeschlossen wird, wird der Bucket als gesund oder verfügbar betrachtet und die Ressource des Jobs trilio-s3-target-validator wird anschließend gelöscht. Wenn etwas schief geht, bleibt der S3-Zielvalidierungsjob aktiv, sodass Sie die Protokolle überprüfen und das mögliche Problem finden können.

Die Ausgabe sieht ähnlich aus wie folgt. Beachten Sie den Wert in der Spalte STATUS - sollte Available sein, was bedeutet, dass es sich in einem gesunden Zustand befindet.
kubectl get pods -n tvk | grep trilio-s3-target-validator

Wenn die Ausgabe so aussieht, haben Sie das S3-Zielobjekt erfolgreich konfiguriert.
Wenn das Zielobjekt jedoch nicht gesund wird, können Sie die Protokolle aus dem Pod trilio-s3-target-validator überprüfen, um das Problem zu finden:

# Zuerst müssen Sie den Zielvalidierer finden
kubectl logs pod/trilio-s3-target-validator-tio99a-6lz4q -n tvk

...
INFO:root:2021-11-24 09:06:50.595166: waiting for mount operation to complete.
INFO:root:2021-11-24 09:06:52.595772: waiting for mount operation to complete.
ERROR:root:2021-11-24 09:06:54.598541: timeout exceeded, not able to mount within time.
ERROR:root:/triliodata is not a mountpoint. We can't proceed further.
Traceback (most recent call last):
  File "/opt/tvk/datastore-attacher/mount_utility/mount_by_target_crd/mount_datastores.py", line 56, in main
    utilities.mount_datastore(metadata, datastore.get(constants.DATASTORE_TYPE), base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 377, in mount_datastore
    mount_s3_datastore(metadata_list, base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 306, in mount_s3_datastore
    wait_until_mount(base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 328, in wait_until_mount
    base_path))
Exception: /triliodata is not a mountpoint. We can't proceed further.
...

#trilio-s3-target-validator-tio99a-6lz4q 1/1 Ausführung 0 104s

# Jetzt Logs-Daten abrufen

Die Ausgabe wird diese Ausnahme sein:

Als nächstes werden Sie die TVK-Webkonsole entdecken, die eine nützliche Ergänzung ist, um Ihnen bei der einfachen Verwaltung von Backup- und Wiederherstellungsvorgängen sowie vielen anderen zu helfen.

Schritt 3 – Kennenlernen der TVK-Web-Management-Konsole

Auch wenn Sie Backup- und Wiederherstellungsvorgänge vollständig über die CLI über kubectl und CRDs verwalten können, bietet TVK eine Web-Management-Konsole, um dieselben Operationen über die GUI auszuführen. Die Management-Konsole vereinfacht gängige Aufgaben durch Point-and-Click-Operationen, bietet eine bessere Visualisierung und Inspektion von TVK-Clusterobjekten sowie die Erstellung von Notfallwiederherstellungsplänen (oder DRPs).

Die in Schritt 1 – Installieren von TrilioVault für Kubernetes behandelte Helm-basierte Installation hat bereits die erforderlichen Komponenten für die Web-Management-Konsole installiert.

kubectl get svc -n tvk

Zugriff auf die TVK-Webverwaltungskonsole erhalten

NAME                                                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
k8s-triliovault-admission-webhook                               ClusterIP   10.245.202.17    <none>        443/TCP                      13m
k8s-triliovault-ingress-nginx-controller                        NodePort    10.245.192.140   <none>        80:32448/TCP,443:32588/TCP   13m
k8s-triliovault-ingress-nginx-controller-admission              ClusterIP   10.3.20.89       <none>        443/TCP                      13m
k8s-triliovault-web                                             ClusterIP   10.245.214.13    <none>        80/TCP                       13m
k8s-triliovault-web-backend                                     ClusterIP   10.245.10.221    <none>        80/TCP                       13m
triliovault-operator-k8s-triliovault-operator-webhook-service   ClusterIP   10.245.186.59    <none>        443/TCP                      16m

Um Zugriff auf die Konsole zu erhalten und die angebotenen Funktionen zu erkunden, müssen Sie den Ingress-Controller-Dienst für TVK weiterleiten.

Zuerst müssen Sie den Dienst ingress-nginx-controller im Namespace tvk identifizieren:
installTVK:
  ingressConfig:
    host: "tvk-doks.com"

Die Ausgabe ähnelt dem Folgenden. Suchen Sie nach der Zeile k8s-triliovault-ingress-nginx-controller und beachten Sie, dass er auf Port 80 in der Spalte PORT(S) hört.

127.0.0.1 tvk-doks.com

TVK verwendet einen Nginx Ingress Controller, um den Verkehr zu den Diensten der Management-Webkonsole zu leiten. Die Routen sind hostbasiert, und der Hostname ist tvk-doks.com, wie in der Helm-Values-Datei des Starter Kits definiert:

kubectl port-forward svc/k8s-triliovault-ingress-nginx-controller 8080:80 -n tvk

# Der Hostname, der verwendet wird, um auf die Webkonsole über den TVK Ingress Nginx Controller zuzugreifen

Mit den oben genannten Informationen gehen Sie bitte weiter und bearbeiten Sie die Datei /etc/hosts und fügen Sie diesen Eintrag hinzu:
doctl k8s cluster list

Als nächstes erstellen Sie die Portweiterleitung für den TVK-Ingress-Controller-Dienst:
doctl kubernetes cluster kubeconfig show <YOUR_CLUSTER_NAME_HERE> > config_<YOUR_CLUSTER_NAME_HERE>.yaml

DOKS_CLUSTER_NAME="$(doctl k8s cluster list --no-header --format Name)"
doctl kubernetes cluster kubeconfig show $DOKS_CLUSTER_NAME > config_${DOKS_CLUSTER_NAME}.yaml

# Liste der verfügbaren Cluster

Wenn Sie nur einen Cluster haben, führen Sie den folgenden Befehl aus:

Nachdem Sie diese Schritte befolgt haben, können Sie auf die Konsole in Ihrem Webbrowser zugreifen, indem Sie zu gehen: http://tvk-doks.com:8080. Wenn Sie nach der kubeconfig-Datei gefragt werden, wählen Sie bitte diejenige aus, die Sie im letzten Befehl oben erstellt haben.

Bitte bewahren Sie die generierte kubeconfig-Datei sicher auf, da sie sensible Daten enthält.

• Erkunden der Benutzeroberfläche der TVK-Webkonsole
• Erkunden Sie jeden Abschnitt links, wie:
• Cluster-Management: Hier wird die Liste der primären und anderen Cluster angezeigt, die TVK-Instanzen haben und dem primären OVH-Cluster mithilfe der Multi-Cluster-Verwaltungsfunktion hinzugefügt wurden.
• Backup & Wiederherstellung: Dies ist das Hauptdashboard, das Ihnen einen allgemeinen Überblick über den gesamten Cluster gibt, wie entdeckte Namespaces, Anwendungen, Backup-Planliste, Ziele, Hooks, Richtlinien usw.

Überwachung: Hier gibt es zwei Optionen – TrilioVault-Überwachung und Velero-Überwachung, wenn der Benutzer Velero auf seinem OVH-Cluster konfiguriert hat.

Katastrophenwiederherstellung: Ermöglicht Ihnen das Verwalten und Durchführen von Katastrophenwiederherstellungsoperationen.

Katastrophenwiederherstellung: Ermöglicht Ihnen das Verwalten und Durchführen von Katastrophenwiederherstellungsoperationen.

Sie können auch das zuvor erstellte S3-Ziel anzeigen, indem Sie zu Backup & Wiederherstellung -> Ziele -> <Namespace> tvk aus dem Dropdown-Menü oben navigieren.

Um weiter zu gehen, können Sie das Ziel durchsuchen und die verfügbaren Backups auflisten, indem Sie auf die Schaltfläche Aktionen rechts klicken und dann die Option Browser starten aus dem Popup-Menü auswählen. Damit dies funktioniert, muss das Ziel das Flag enableBrowsing auf true gesetzt haben.

Weitere Informationen und verfügbare Funktionen finden Sie in der offiziellen Dokumentation zur TVK Web Management Console User Interface.

Anschließend erfahren Sie, wie Sie Backup- und Wiederherstellungsoperationen für spezifische Anwendungsfälle durchführen können.

Schritt 4 – Beispiel für Namensraum-Backup und -Wiederherstellung

apiVersion: triliovault.trilio.io/v1
kind: BackupPlan
metadata:
  name: ambassador-helm-release-backup-plan
  namespace: ambassador
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
  backupPlanComponents:
    helmReleases:
      - ambassador

In diesem Schritt lernen Sie, wie Sie ein einmaliges Backup für einen gesamten Namensraum (ambassador in diesem Fall) von Ihrem DOKS-Cluster erstellen und es anschließend wiederherstellen, um sicherzustellen, dass alle Ressourcen neu erstellt werden. TVK verfügt über eine Funktion, die es Ihnen ermöglicht, Backups auf einer höheren Ebene als nur Namensräume durchzuführen.

• Erstellen des Ambassador Helm Release-Backups
• Um Backups für eine einzelne Anwendung auf der Namensraumebene (oder Helm-Release) durchzuführen, ist zunächst ein BackupPlan gefolgt von einer Backup-CRD erforderlich. Ein BackupPlan ist eine Definition von ‚was‘, ‚wo‘, ‚nach‘ und ‚wie‘ des Backup-Vorgangs, führt jedoch das eigentliche Backup nicht durch. Die Backup-CRD ist für das Auslösen des tatsächlichen Backup-Vorgangs verantwortlich, wie es von der BackupPlan-Spezifikation vorgegeben wird.
• In dieser Konfiguration

A typical Backup CRD looks like below:

apiVersion: triliovault.trilio.io/v1
kind: Backup
metadata:
  name: ambassador-helm-release-full-backup
  namespace: ambassador
spec:
  type: Full
  backupPlan:
    name: ambassador-helm-release-backup-plan
    namespace: ambassador

spec.backupConfig.target.name: gibt an, welchen Zielnamen TVK zum Speichern von Backups verwenden soll.

• spec.backupConfig.target.namespace: gibt an, in welchem Namensraum das Ziel erstellt wurde.
• spec.backupComponents: Definiert eine Liste von Ressourcen, die gesichert werden sollen.

In dieser Konfiguration,

spec.type: Legt den Sicherungstyp fest.

spec.backupPlan: Legt den BackupPlan fest, den diese Sicherung verwenden soll.

cd Kubernetes-Starter-Kit-Developers

Schritte zur Initiierung des Ambassador Helm Einmal-Backups:

code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup-plan.yaml
code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup.yaml

Zuerst stellen Sie sicher, dass der Ambassador Edge Stack in Ihrem Cluster bereitgestellt ist, indem Sie den Anweisungen im Ambassador Ingress Tutorial folgen.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup-plan.yaml
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup.yaml

Dann wechseln Sie zum Verzeichnis, in das das Starter Kit Git-Repository auf Ihrem lokalen Rechner geklont wurde:

kubectl get backupplan ambassador-helm-release-backup-plan -n ambassador

Danach öffnen und inspizieren Sie die Ambassador BackupPlan und Backup Manifestdateien, die im Starter Kit Repository mit einem Editor Ihrer Wahl bereitgestellt wurden (vorzugsweise mit YAML-Lint-Unterstützung).

NAME                                  TARGET             ...   STATUS
ambassador-helm-release-backup-plan   trilio-s3-target   ...   Available

Zuletzt erstellen Sie die BackupPlan und Backup Ressourcen mit kubectl.

kubectl get backup ambassador-helm-release-full-backup -n ambassador

Jetzt inspizieren Sie den BackupPlan-Status (mit Ausrichtung auf die ambassador Helm-Veröffentlichung) mit kubectl:

NAME                                  BACKUPPLAN                            BACKUP TYPE   STATUS       ...
ambassador-helm-release-full-backup   ambassador-helm-release-backup-plan   Full          InProgress   ...

Die Ausgabe ähnelt dem Folgenden. Beachten Sie den Wert der Spalte STATUS, der auf Verfügbar gesetzt sein sollte.

Anschließend überprüfen Sie den Status des Backup-Objekts mit kubectl:
NAME                                  BACKUPPLAN                            BACKUP TYPE   STATUS      ...   PERCENTAGE
ambassador-helm-release-full-backup   ambassador-helm-release-backup-plan   Full          Available   ...   100

Die Ausgabe ähnelt dem Folgenden. Beachten Sie den Wert der Spalte STATUS, der auf InBearbeitung gesetzt sein sollte, sowie den Wert von BACKUP TYPE, der auf Vollständig gesetzt ist.

s3cmd ls s3://trilio-starter-kit --recursive

Nachdem alle Botschafter Helm Release-Komponenten erfolgreich auf das S3-Ziel hochgeladen wurden, sollten Sie diese Ergebnisse erhalten:

2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/
2021-11-25 07:04          311  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup-namespace.json.manifest.00000004
2021-11-25 07:04          302  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup.json.manifest.00000004
2021-11-25 07:04          305  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backupplan.json.manifest.00000004
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/
2021-11-25 07:04          330  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/metadata.json.manifest.00000002
...

kubectl get pods -n ambassador | grep metamover

ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx   1/1     Running   0          4m32s

kubectl logs pod/ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx -n ambassador -f

...
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding: [edge-stack]","time":"2022-06-14T06:20:56Z"}
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=RoleBinding: [edge-stack-agent-config]","time":"2022-06-14T06:20:56Z"}
...

Die Ausgabe sieht ähnlich aus wie:

Jetzt die Protokolldaten abrufen:

Die Ausgabe sieht ähnlich wie folgt aus.

helm delete ambassador -n ambassador

Zuletzt können Sie überprüfen, ob das Backup auch im Web-Portal verfügbar ist, indem Sie zu Ressourcenverwaltung -> Botschafter -> Backup-Pläne navigieren. Beachten Sie, dass es sich im Verfügbar-Zustand befindet und dass das Botschafter Helm-Release im Unteransicht Komponentendetails gesichert wurde.

kubectl get all -n ambassador

Löschen des Botschafter Helm Release und der Ressourcen

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

Nun, fahren Sie fort und simulieren Sie eine Katastrophe, indem Sie die ambassador-Helm-Freigabe absichtlich löschen:

Wenn Sie denselben Namespace wiederherstellen, stellen Sie sicher, dass die ursprünglichen Anwendungskomponenten entfernt wurden. Insbesondere der PVC der Anwendung wird gelöscht.

apiVersion: triliovault.trilio.io/v1
kind: Restore
metadata:
  name: ambassador-helm-release-restore
  namespace: ambassador
spec:
  source:
    type: Backup
    backup:
      name: ambassador-helm-release-full-backup
      namespace: ambassador
  skipIfAlreadyExists: true

Wenn Sie eine Wiederherstellung in ein anderes Cluster durchführen (Migrationsszenario), stellen Sie sicher, dass TrilioVault für Kubernetes auch im entfernten Namespace/Cluster läuft. Um in ein neues Cluster wiederherzustellen (wo das Backup-CR nicht vorhanden ist), muss source.type auf location gesetzt werden. Bitte beachten Sie den Bereich zur Definition von benutzerdefinierten Ressourcen für die Wiederherstellung, um ein Wiederherstellungsbeispiel nach Standort zu sehen.

• Wenn Sie den Namespace ambassador löschen, wird die mit dem Ambassador-Dienst verbundene Lastenausgleichsressource ebenfalls gelöscht. Wenn Sie also den Dienst ambassador wiederherstellen, wird der LB von DigitalOcean neu erstellt. Das Problem besteht darin, dass Sie eine NEUE IP-Adresse für Ihren LB erhalten, daher müssen Sie die A-Records anpassen, um den Datenverkehr in Ihre auf dem Cluster gehosteten Domains zu leiten.
• Um ein bestimmtes Backup wiederherzustellen, müssen Sie eine Restore-CRD erstellen. Eine typische Wiederherstellungs-CRD sieht wie folgt aus:
• In dieser Konfiguration,

spec.source.type: Gibt an, welcher Backup-Typ wiederhergestellt werden soll.

spec.source.backup: Enthält einen Verweis auf das Backup-Objekt, das wiederhergestellt werden soll.

code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-restore.yaml

spec.skipIfAlreadyExists: Gibt an, ob die Wiederherstellung einer Ressource übersprungen werden soll, wenn sie bereits im wiederhergestellten Namespace vorhanden ist.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-restore.yaml

Wiederherstellen ermöglicht es Ihnen, das letzte erfolgreiche Backup für eine Anwendung wiederherzustellen. Es wird verwendet, um einen einzelnen Namensraum oder Helm-Release wiederherzustellen, der durch die Backup-CRD geschützt ist. Die Backup-CRD wird durch ihren Namen `ambassador-helm-release-full-backup` identifiziert.

kubectl get restore ambassador-helm-release-restore -n ambassador

Zuerst, inspizieren Sie das Beispiel für die Restore-CRD aus dem Starter Kit Git-Repository:

NAME                              STATUS      DATA SIZE   START TIME             END TIME               PERCENTAGE COMPLETED   DURATION
ambassador-helm-release-restore   Completed   0           2021-11-25T15:06:52Z   2021-11-25T15:07:35Z   100                    43.524191306s

Dann erstellen Sie die Restore-Ressource mit `kubectl`:

Zum Schluss inspizieren Sie den Status des Restore-Objekts:

Die Ausgabe sieht ähnlich aus wie folgt. Beachten Sie die `STATUS`-Spalte, die auf `Completed` gesetzt ist, sowie die `PERCENTAGE COMPLETED` auf `100`.

kubectl get all -n ambassador

Wenn die Ausgabe so aussieht, dann ist der Wiederherstellungsprozess für das `ambassador` Helm-Release erfolgreich abgeschlossen.

NAME                                    READY   STATUS    RESTARTS   AGE
pod/ambassador-5bdc64f9f6-42wzr         1/1     Running   0          9m58s
pod/ambassador-5bdc64f9f6-nrkzd         1/1     Running   0          9m58s
pod/ambassador-agent-bcdd8ccc8-ktmcv    1/1     Running   0          9m58s
pod/ambassador-redis-64b7c668b9-69drs   1/1     Running   0          9m58s

NAME                       TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
service/ambassador         LoadBalancer   10.245.173.90    157.245.23.93   80:30304/TCP,443:30577/TCP   9m59s
service/ambassador-admin   ClusterIP      10.245.217.211   <none>          8877/TCP,8005/TCP            9m59s
service/ambassador-redis   ClusterIP      10.245.77.142    <none>          6379/TCP                     9m59s

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ambassador         2/2     2            2           9m59s
deployment.apps/ambassador-agent   1/1     1            1           9m59s
deployment.apps/ambassador-redis   1/1     1            1           9m59s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/ambassador-5bdc64f9f6         2         2         2       9m59s
replicaset.apps/ambassador-agent-bcdd8ccc8    1         1         1       9m59s
replicaset.apps/ambassador-redis-64b7c668b9   1         1         1       9m59s

Überprüfen der Anwendungsintegrität nach der Wiederherstellung

kubectl get hosts -n ambassador

Überprüfen Sie, dass alle Ressourcen im Namensraum `ambassador` vorhanden und aktiv sind:

NAME         HOSTNAME                   STATE   PHASE COMPLETED   PHASE PENDING   AGE
echo-host    echo.starter-kit.online    Ready                                     11m
quote-host   quote.starter-kit.online   Ready                                     11m

Die Ausgabe sieht ähnlich aus wie folgt:

kubectl get mappings -n ambassador

Holen Sie sich Ambassador-Hosts:

NAME                          SOURCE HOST                SOURCE PREFIX                               DEST SERVICE     STATE   REASON
ambassador-devportal                                     /documentation/                             127.0.0.1:8500
ambassador-devportal-api                                 /openapi/                                   127.0.0.1:8500
ambassador-devportal-assets                              /documentation/(assets|styles)/(.*)(.css)   127.0.0.1:8500
ambassador-devportal-demo                                /docs/                                      127.0.0.1:8500
echo-backend                  echo.starter-kit.online    /echo/                                      echo.backend
quote-backend                 quote.starter-kit.online   /quote/                                     quote.backend

Die Ausgabe sieht ähnlich aus wie folgt. `STATE` sollte `Ready` sein und die `HOSTNAME`-Spalte sollte auf den vollständig qualifizierten Hostnamen verweisen.

Holen Sie sich Ambassador-Mappings:

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

Die Ausgabe sieht ähnlich wie folgt aus. Beachten Sie den echo-backend, der dem Host echo.starter-kit.online und dem Quellpräfix /echo/ zugeordnet ist, ebenso wie quote-backend.

Jetzt müssen Sie Ihre DNS A Records aktualisieren, da die Ressource des DigitalOcean-Lastenausgleichs neu erstellt wurde und eine neue externe IP zugewiesen bekommen hat.

Zuletzt prüfen Sie, ob die Backend-Anwendungen ebenfalls auf HTTP-Anfragen antworten. Bitte beachten Sie Erstellen der Ambassador Edge Stack Backend-Services bezüglich der im Starter-Kit-Tutorial verwendeten Backend-Anwendungen.

Der nächste Schritt befasst sich mit der Sicherung und Wiederherstellung des gesamten Clusters.

Schritt 5 – Beispiel für die Sicherung und Wiederherstellung des gesamten Clusters

A typical ClusterBackupPlan manifest targeting multiple namespaces looks like this:

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: starter-kit-cluster-backup-plan
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
  backupComponents:
    - namespace: ambassador
    - namespace: backend
    - namespace: monitoring

In diesem Schritt simulieren Sie ein Szenario für die Wiederherstellung nach einem Desaster. Der gesamte DOKS-Cluster wird gelöscht und dann werden die wichtigen Anwendungen aus einem früheren Backup wiederhergestellt.

Erstellen des Backups des DOKS-Clusters

cd Kubernetes-Starter-Kit-Developers

Die Hauptidee hier ist, ein DOKS-Cluster-Backup durchzuführen, indem alle wichtigen Namensräume einbezogen werden, die Ihre wesentlichen Anwendungen und Konfigurationen enthalten.

code 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup-plan.yaml
code 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup.yaml

Beachten Sie, dass kube-system (oder andere DOKS-Cluster-bezogene Namensräume) nicht in der Liste enthalten sind. Normalerweise sind diese nicht erforderlich, es sei denn, es gibt einen speziellen Fall, der erfordert, dass einige Einstellungen auf dieser Ebene persistiert werden müssen.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup-plan.yaml
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup.yaml

Ändern Sie zunächst das Verzeichnis, in dem das Git-Repository des Starter Kits auf Ihrem lokalen Rechner geklont wurde:

kubectl get clusterbackupplan starter-kit-cluster-backup-plan -n tvk

Öffnen und inspizieren Sie dann die bereitgestellten Manifestdateien ClusterBackupPlan und ClusterBackup im Starter Kit Repository mit einem Editor Ihrer Wahl (vorzugsweise mit YAML-Lint-Unterstützung).

NAME                              TARGET             ...   STATUS
starter-kit-cluster-backup-plan   trilio-s3-target   ...   Available

Erstellen Sie abschließend die Ressourcen ClusterBackupPlan und ClusterBackup mit kubectl:

kubectl get clusterbackup starter-kit-cluster-backup -n tvk

Inspektieren Sie nun den Status des ClusterBackupPlan mit kubectl:

NAME                        BACKUPPLAN                        BACKUP TYPE   STATUS      ...   PERCENTAGE COMPLETE
starter-kit-cluster-backup  starter-kit-cluster-backup-plan   Full          Available   ...   100

Die Ausgabe sieht ähnlich aus wie folgt. Beachten Sie den Wert in der Spalte STATUS, der auf Verfügbar gesetzt sein sollte.

Die Ausgabe sieht ähnlich aus wie folgt. Beachten Sie den Wert in der Spalte STATUS, der ebenfalls auf Verfügbar gesetzt sein sollte, sowie den Wert von PROZENTUALER ABSCHLUSS, der auf 100 gesetzt ist.

Wenn die Ausgabe wie oben aussieht, wurden alle wichtigen Anwendungsnamensräume erfolgreich gesichert.

Es kann eine Weile dauern, bis das vollständige Cluster-Backup abgeschlossen ist, je nachdem, wie viele Namensräume und zugehörige Ressourcen am Prozess beteiligt sind.

Sie können auch das Hauptdashboard der Webkonsole öffnen und das Multi-Namespace-Backup überprüfen (achten Sie darauf, wie alle wichtigen Namespaces, die gesichert wurden, in grüner Farbe hervorgehoben sind, in einer Wabenstruktur):

doctl kubernetes cluster delete <DOKS_CLUSTER_NAME>

Neuerstellen des DOKS-Clusters und Wiederherstellen von Anwendungen

Ein wichtiger Aspekt, den Sie im Auge behalten sollten, ist, dass jedes Mal, wenn Sie einen DOKS-Cluster zerstören und dann wiederherstellen, auch ein neuer Lastenausgleicher mit einer neuen externen IP-Adresse erstellt wird, wenn TVK Ihren Ingress-Controller wiederherstellt. Stellen Sie daher sicher, dass Sie Ihre DigitalOcean-DNS-A-Records entsprechend aktualisieren.

Löschen Sie jetzt den gesamten DOKS-Cluster (stellen Sie sicher, dass Sie die Platzhalter <> entsprechend ersetzen):

Als nächstes erstellen Sie den Cluster neu, wie in Einrichten von DigitalOcean Kubernetes beschrieben.

Um die Wiederherstellung durchzuführen, müssen Sie die TVK-Anwendung installieren, wie in Schritt 1 – Installation von TrilioVault für Kubernetes beschrieben. Es ist wichtig, die gleiche Helm Chart-Version zu verwenden.

Nachdem die Installation erfolgreich abgeschlossen wurde, konfigurieren Sie das TVK-Ziel gemäß Schritt 2 – Erstellen eines TrilioVault-Ziels zum Speichern von Backups und weisen Sie es auf denselben S3-Bucket hin, in dem sich Ihre Backup-Daten befinden. Stellen Sie außerdem sicher, dass das Zielbrowsen aktiviert ist.

Als Nächstes überprüfen und aktivieren Sie eine neue Lizenz gemäß dem Abschnitt TrilioVault Anwendungs Lizenzierung.

Um Zugriff auf die Benutzeroberfläche der Webkonsole zu erhalten, konsultieren Sie bitte den Abschnitt Zugriff auf die TVK-Webverwaltungskonsole erhalten.

Anschließend navigieren Sie zu Ressourcenverwaltung -> TVK-Namespace -> Ziele (im Falle des Starter-Kits ist der TVK-Namespace tvk):

Weiterhin durchsuchen Sie das Ziel und listen die verfügbaren Backups auf, indem Sie auf die Schaltfläche Aktionen klicken. Wählen Sie dann die Option Browser starten aus dem Popup-Menü. Damit dies funktioniert, muss die enableBrowsing-Flag auf true gesetzt sein.

Klicken Sie nun auf das Element starter-kit-cluster-backup-plan in der Liste und klicken Sie dann auf das Element starter-kit-cluster-backup im rechten Unterfenster, um es zu erweitern:

kubectl get all --all-namespaces

Um den Wiederherstellungsprozess zu starten, klicken Sie auf die Schaltfläche Wiederherstellen.

Überprüfen des Zustands von DOKS-Clusteranwendungen

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

Zunächst überprüfen Sie alle Kubernetes-Ressourcen im Cluster.

Dann stellen Sie sicher, dass Ihre DNS-A-Einträge aktualisiert sind, um auf die externe IP Ihres neuen Lastenausgleichers zu verweisen.

Außerdem sollten die Backend-Anwendungen auch auf HTTP-Anfragen antworten. Bitte beachten Sie die Anleitung zum Erstellen der Backend-Services des Ambassador Edge Stack im Starter-Kit-Tutorial.

Im nächsten Schritt erfahren Sie, wie Sie geplante (oder automatische) Backups für Ihre DOKS-Clusteranwendungen durchführen können.

kind: Policy
apiVersion: triliovault.trilio.io/v1
metadata:
  name: scheduled-backup-every-5min
  namespace: tvk
spec:
  type: Schedule
  scheduleConfig:
    schedule:
      - "*/5 * * * *" Schritt 6 - Geplante Backups

Automatische Backups gemäß einem Zeitplan zu erstellen, ist eine wirklich nützliche Funktion. Sie ermöglicht es Ihnen, die Zeit zurückzudrehen und das System auf einen früheren funktionierenden Zustand wiederherzustellen, wenn etwas schief geht. Dieser Abschnitt bietet ein Beispiel für ein automatisches Backup im 5-Minuten-Intervall (der Namespace kube-system wurde ausgewählt).

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: kube-system-ns-backup-plan-5min-schedule
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    schedulePolicy:
      fullBackupPolicy:
        name: scheduled-backup-every-5min
        namespace: tvk
  backupComponents:
    - namespace: kube-system
    - namespace: backend

Zuerst müssen Sie eine Policy-CRD vom Typ Schedule erstellen, die den Sicherungsplan im Cron-Format definiert (genauso wie bei Linux cron). Zeitplanrichtlinien können für BackupPlan– oder ClusterBackupPlan-CRDs verwendet werden. Eine typische Zeitplanrichtlinien-CRD sieht wie folgt aus (definiert einen Zeitplan von 5 Minuten):

# trigger alle 5 Minuten

Als nächstes können Sie die Zeitplanrichtlinie auf eine ClusterBackupPlan-CRD anwenden, wie im folgenden Beispiel gezeigt:

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/scheduled-backup-every-5min.yaml

Sie können feststellen, dass es sich um eine grundlegende ClusterBackupPlan-CRD handelt, die über das Feld spec.backupConfig.schedulePolicy auf die zuvor definierte Policy-CRD verweist. Sie können separate Richtlinien für vollständige oder inkrementelle Sicherungen erstellen, daher können fullBackupPolicy oder incrementalBackupPolicy in der Spezifikation angegeben werden.

kubectl get policies -n tvk

Bitte erstellen Sie nun die Zeitplan-Policy mithilfe des im Starter Kit-Tutorial bereitgestellten Beispieldokuments.

NAME                          POLICY     DEFAULT
scheduled-backup-every-5min   Schedule   false

Wechseln Sie das Verzeichnis zum Ort, an dem das Git-Repository des Starter Kits auf Ihrem lokalen Rechner geklont wurde.

Überprüfen Sie, ob die Richtlinienressource erstellt wurde:
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/kube-system-ns-backup-plan-scheduled.yaml

Die Ausgabe sieht ähnlich wie folgt aus. Beachten Sie den Typ POLICY, der auf Schedule festgelegt ist.
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/kube-system-ns-backup-scheduled.yaml

Erstellen Sie abschließend die Ressourcen für die geplanten Backups im kube-system-Namespace:

kubectl get clusterbackupplan kube-system-ns-backup-plan-5min-schedule -n tvk

# Erstellen Sie zuerst den Sicherungsplan für den Namespace kube-system

NAME                                       TARGET             ...   FULL BACKUP POLICY            STATUS
kube-system-ns-backup-plan-5min-schedule   trilio-s3-target   ...   scheduled-backup-every-5min   Available

# Erstellen und Auslösen des geplanten Backups für den Namespace kube-system

kubectl get clusterbackup kube-system-ns-full-backup-scheduled -n tvk

Überprüfen Sie den Status des geplanten Sicherungsplans für kube-system:

NAME                                   BACKUPPLAN                                 BACKUP TYPE   STATUS      ...
kube-system-ns-full-backup-scheduled   kube-system-ns-backup-plan-5min-schedule   Full          Available   ...

Die Ausgabe sieht ähnlich aus wie folgt. Beachten Sie den Wert FULL BACKUP POLICY, der auf die zuvor erstellte Ressource für den Sicherungsplan scheduled-backup-every-5min gesetzt ist, sowie den STATUS, der Available sein sollte.

Überprüfen Sie den Status der geplanten Sicherung für kube-system:

Die Ausgabe sieht ähnlich aus wie folgt. Beachten Sie den Wert BACKUPPLAN, der auf den zuvor erstellten Sicherungsplan verweist, sowie den STATUS, der Available sein sollte.

Jetzt können Sie überprüfen, ob Sicherungen in regelmäßigen Abständen (alle 5 Minuten) durchgeführt werden, indem Sie die Sicherungsressource des Clusters abfragen und die Spalte START TIME überprüfen (kubectl get clusterbackup -n tvk). Es sollte den 5-Minuten-Abstand widerspiegeln, wie im Bild unten hervorgehoben:

Im nächsten Schritt erfahren Sie, wie Sie eine Aufbewahrungspolitik für Ihre Sicherungen einrichten.

Schritt 7 – Aufbewahrungspolitik für Sicherungen

apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: sample-policy
spec:
  type: Retention
  retentionConfig:
    latest: 2
    weekly: 1
    dayOfWeek: Wednesday
    monthly: 1
    dateOfMonth: 15
    monthOfYear: March
    yearly: 1

Die Aufbewahrungspolitik ermöglicht es Ihnen, die Anzahl der zu behaltenden Sicherungen und den Zeitplan zum Löschen von Sicherungen gemäß den Compliance-Anforderungen festzulegen. Die Aufbewahrungspolitik CRD bietet eine einfache YAML-Spezifikation, um die Anzahl der zu behaltenden Sicherungen in Tagen, Wochen, Monaten, Jahren, die neueste Sicherung usw. festzulegen.

• Verwendung von Aufbewahrungspolicen
• Aufbewahrungspolicen können für die CRDs BackupPlan oder ClusterBackupPlan verwendet werden. Ein typisches Manifest für eine Policy-Aufbewahrung sieht wie folgt aus:
• Die oben genannte Aufbewahrungspolice wird wie folgt übersetzt:
• Jede Woche wird eine Sicherung am Mittwoch aufbewahrt.

Jeden Monat wird eine Sicherung am 15. Tag aufbewahrt.

A typical ClusterBackupPlan example configuration that has a retention set looks like:

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: kube-system-ns-backup-plan-5min-schedule
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    retentionPolicy:
      fullBackupPolicy:
        name: ambassador-backups-retention-policy
        namespace: tvk
  backupComponents:
    - namespace: kube-system
    - namespace: backend

Jedes Jahr wird im März eine Sicherung aufbewahrt.

Insgesamt sollten die 2 neuesten Sicherungen verfügbar sein.

Der grundlegende Ablauf zur Erstellung einer Ressource für eine Aufbewahrungspolice erfolgt genauso wie bei geplanten Sicherungen. Sie benötigen einen definierten BackupPlan oder einen ClusterBackupPlan CRD, um die Aufbewahrungspolice zu referenzieren, und dann einen Backup– oder ClusterBackup-Objekt, um den Prozess auszulösen.

apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: garbage-collect-policy
spec:
  type: Cleanup
  cleanupConfig:
    backupDays: 5

Beachten Sie, dass hier ein retentionPolicy-Feld verwendet wird, um auf die betreffende Police zu verweisen. Natürlich können Sie einen Backup-Plan haben, der beide Arten von Policen hat, sodass er geplante Backups durchführen kann und auch Aufbewahrungsstrategien berücksichtigt.

Verwendung von Bereinigungspolicen

Sie benötigen eine Möglichkeit, alle Objekte zu bereinigen, die nicht mehr verwendet werden. Dazu müssen Sie das Cleanup Policy CRD einführen:

Die oben genannte Bereinigungsrichtlinie muss im TVK-Installationsnamespace definiert sein. Anschließend wird automatisch ein Cron-Job für Sie erstellt, der alle 30 Minuten ausgeführt wird und fehlgeschlagene Backups basierend auf dem im Feld backupdays angegebenen Wert löscht.

Fazit

• In diesem Tutorial haben Sie gelernt, wie Sie sowohl einmalige als auch geplante Backups durchführen und alles wiederherstellen können.
• Alle im Tutorial erklärten grundlegenden Aufgaben und Operationen sollen Ihnen eine grundlegende Einführung und Verständnis dafür geben, wozu TrilioVault für Kubernetes fähig ist.
• Weitere Informationen

Backup und Wiederherstellung von DOKS-Daten mit Velero