Für Disaster Recovery konfigurieren

Mit den mit diesem Lösungs-Playbook bereitgestellten Skripten können Sie einen YAML-Snapshot in einem primären Kubernetes-Cluster erstellen und in einem anderen (sekundären) Kubernetes-Cluster wiederherstellen. Es ist wichtig, die Konfiguration zu planen und die Anforderungen zu verstehen, bevor Sie den YAML-Snapshot herunterladen und mit den Skripten konfigurieren.

Hinweis:

Bei dieser Lösung wird davon ausgegangen, dass beide Kubernetes-Cluster, einschließlich des Kontrollplans und der Worker-Knoten, bereits vorhanden sind.

Konfiguration planen

Planen Sie die Ressourcen und die Konfiguration auf dem sekundären System basierend auf dem primären System. Die Skripte erfordern, dass beide Kubernetes-Cluster bereits vorhanden sind. Sie müssen mit dem Kubernetes-Befehlstool kubectl auf beide Cluster zugreifen können, um Befehle dafür auszuführen.

Hinweis:

Bei dieser Lösung wird davon ausgegangen, dass beide Kubernetes-Cluster, einschließlich des Kontrollplans und der Worker-Knoten, bereits vorhanden sind. Die in diesem Playbook bereitgestellten Empfehlungen und Skripte prüfen nicht die Konfiguration von Ressourcen, Control Plane oder Worker-Knoten.

Das folgende Diagramm zeigt, dass Sie bei der Konfiguration den Artefakt-Snapshot in vollständig anderen Kubernetes-Clustern wiederherstellen können.

Beschreibung der Abbildung kube-api-dr.png

Geben Sie bei der Planung der Konfiguration die folgenden Anforderungen für Restore ein:

Bestätigen Sie, dass die erforderlichen Worker-Knoten und -Ressourcen im primären Knoten sekundär verfügbar sind.
Dazu gehören die Shared Storage Mounts, Load Balancer und Datenbanken des Pods. Es enthält auch alle externen Systeme, die von den wiederhergestellten Namespaces verwendet werden.
Erstellen Sie manuell die erforderlichen persistenten Volumes, die von den beteiligten Namespaces verwendet werden, bevor die Skripte ausgeführt werden.

Dies ist die Standardaktion. Die Skripte erstellen die persistenten Datenträgeransprüche, die in der primären Instanz verwendet werden. Da persistente Volumes jedoch möglicherweise von verschiedenen Claims in verschiedenen Namespaces gemeinsam verwendet werden, erwarten die Automatisierungsskripte, dass Sie persistente Volumes im sekundären Cluster manuell erstellen, bevor Sie die extract-apply-Skripte ausführen.

Alternativ können Sie pv zur Variable nons_artifacts_types in der Datei maak8DR-apply.env hinzufügen (d.h. export nons_artifacts_types="crd clusterrole clusterrolebinding pv verwenden). Dadurch werden die Skripte angewiesen, die persistenten Volumes sekundär zu erstellen. In diesem zweiten Fall müssen Sie feststellen, ob Konflikte mit anderen Persistent Volume Claims auftreten können.
Vergewissern Sie sich, dass das sekundäre Cluster über den entsprechenden Zugriff auf die Containerimages verfügt, die von den replizierten Namespaces verwendet werden:
- Secrets für den Zugriff auf Container-Registrys, die in den zu replizierenden Namespaces vorhanden sind, werden von den mit diesem Playbook bereitgestellten Skripten kopiert. Wenn die Zugangsdaten für die Registrys in anderen Namespaces gespeichert sind, müssen Sie sie manuell in der sekundären Datei erstellen. Alternativ können Sie die Zugangsdaten mit maak8sapply: my_ns beschriften (wobei my_ns der Namespace ist, der wiederhergestellt wird), sodass das Secret auch im YAML-Snapshot enthalten ist. Beispiel:
```
kubectl label secret regcredfra -n other_namespace 
maak8sapply=namespace_being_backedup
```
- Wenn Sie Bilder verwenden, die manuell in die primären Worker-Knoten geladen wurden, müssen Sie sie auch manuell in die sekundären Worker-Knoten laden.
  
  Hinweis:
  Die bereitgestellten Skripte melden die Bilder, die in den replizierten Namespaces verwendet werden.
Bieten Sie Zugriff auf das primäre und das sekundäre Cluster über Bastionknoten, die kubectl-Vorgänge für die Kube-API-Endpunkte jedes Clusters ausführen können.
Sie können einen dritten Knoten verwenden, der sowohl ssh als auch scp (primär und Standby) verwenden und die DR-Synchronisierung koordinieren kann. Um jedoch unnötigen Hops und Session-Overhead zu vermeiden, empfiehlt Oracle, die primäre Bastion als DR-Koordinator zu verwenden. Andere Optionen erfordern eine Anpassung der bereitgestellten Skripte.
Verwenden Sie das Label maak8sapply: my_ns, wenn beim Wiederherstellen von my_ns namespace nicht benannte Ressourcen im Backup sekundär angewendet werden sollen.

Bei diesen Artefakten, die sich in der Root des Clusters befinden (also nicht Teil eines genauen Namespace), suchen die Skripte nach den Feldreferenzen namespace: und group:, die die Namespace-Namen enthalten. Wenn Sie weitere Ressourcen benötigen, die nicht im Namespace enthalten sind, können Sie diese als Label angeben, das hinzugefügt werden soll.

Beispiel: Die benutzerdefinierte Ressourcendefinition domains.weblogic.oracle ist nicht Bestandteil eines Namespace. Sie können sie jedoch mit dem folgenden Label in den Vorgang apply aufnehmen: kubectl label crd domains.weblogic.oracle maak8sapply=opns.

Konfigurieren

Konfigurieren Sie das Recovery von YAML-Snapshots.

Laden Sie alle Disaster Recovery-Skripte für YAML-Snapshots von "Code herunterladen" herunter.

Hinweis:
Alle Skripte müssen sich im selben Pfad befinden, da die Hauptskripte andere Hilfsskripte verwenden.
Bearbeiten Sie das Skript maak8DR-apply.env, und aktualisieren Sie die Adressen und den SSH-Schlüssel, die für den Zugriff auf das sekundäre System erforderlich sind.
Beispiel:
```
export user_sec=opc
export ssh_key_sec=/home/opc/Key.ppk
#Secondary bastion node
export sechost=10.10.0.23
```
Passen Sie die Werte für exclude_list und nons_artifacts_types nach Bedarf an.
- exclude_list: Dies ist eine durch Leerzeichen getrennte Liste dieser Namespaces, die aus dem Backup ausgeschlossen werden sollen, selbst wenn versucht wird, ALLE benutzerdefinierten Namespaces zu sichern. Dadurch wird verhindert, dass Namespaces mit zugehörigen Control Plane kopiert werden, die auf der sekundären Ebene nicht anwendbar sind.
- nons_artifacts_types: Dies ist die Liste oder Artefakte, die zum Root-Baum gehören (d.h. nicht zu einem genauen Namespace), aber auch im Snapshot enthalten sein müssen. Das Framework sucht in diesem Bereich nach Referenzen zu den zu sichernden Namespaces.
Im Allgemeinen können Sie die in der Datei angegebenen Standardwerte verwenden:
```
#List of namespaces that will be excluded from the backup
export exclude_list="kube-system kube-flannel kube-node-lease kube-public"
#Root artifacts that will be included
export nons_artifacts_types="crd clusterrole clusterrolebinding"
```
Führen Sie das Skript maak8DR-apply.sh aus, das die ausgewählten Namespaces als Argumente für die Replikation bereitstellt.
- Wenn Sie keine Argumente angeben, replizieren die Skripte ALLE Namespaces mit Ausnahme der Namespaces, die in der Variable exclude_list angegeben sind.
- Wenn Sie eine präzise Liste von Namespaces verwenden, müssen Sie diese basierend auf den Abhängigkeiten mit anderen Namespaces sortieren.
  
  Das heißt, wenn der Namespace soans von Services im Namespace opns abhängt oder verwendet, muss opns zuerst in der Liste angezeigt werden. Beispiel: Führen Sie anstelle von ./maak8DR-apply.sh soans opns Folgendes aus:
```
./maak8DR-apply.sh opns soans
```

Verifizieren

Prüfen Sie nach der Ausführung des Skripts maak8DR-apply.sh, ob alle im primären Cluster vorhandenen Artefakte im sekundären Cluster repliziert wurden. Prüfen Sie das sekundäre Cluster, und stellen Sie sicher, dass die Pods in der sekundären Site fehlerfrei ausgeführt werden.

Wenn Sie das Skript maak8DR-apply.sh ausführen, erstellt das Framework das Verzeichnis working_dir als /tmp/backup.date. Wenn Sie die Skripte maak8-get-all-artifacts.sh und maak8-push-all-artifacts.sh einzeln ausführen, wird das Arbeitsverzeichnis jeweils als Argument in der Befehlszeile bereitgestellt.

Prüfen Sie den Status der Sekundärinstanz, bis die erforderlichen Pods mit dem Status in der Primärdatenbank übereinstimmen.
Standardmäßig werden die Pods und Deployments in der sekundären Region gestartet. Am Ende der Wiederherstellung wird der Status des sekundären Clusters angezeigt. Einige Pods benötigen möglicherweise zusätzliche Zeit, um den Status RUNNING zu erreichen.
Prüfen Sie die Datei $working_dir/date/backup-operations.log in der primären Datei auf mögliche Fehler in den Extraktions- und Apply-Vorgängen.
Prüfen Sie die Dateien $working_dir/restore.log und $working_dir/date/restore-operations.log in der sekundären Datei auf mögliche Fehler in den Extraktions- und Apply-Vorgängen.
Die Datei restore-operations.log enthält die detaillierten Wiederherstellungsvorgänge.