1. Kubernetes-Cluster werden basierend auf etcd-Snapshots wiederhergestellt
  2. Für Disaster Recovery konfigurieren

Für Disaster Recovery konfigurieren

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

Hinweis:

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

Konfiguration planen

Planen Sie die Ressourcen und die Konfiguration im sekundären System basierend auf dem primären System.

Hinweis:

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

Die Wiederherstellung kann, wie hier beschrieben, in Clustern angewendet werden, die primär "spiegeln" (gleiche Anzahl von Control-Plane-Knoten, gleiche Anzahl von Worker-Knoten). Bei den Prozeduren wird davon ausgegangen, dass ein primäres Kubernetes-Cluster vorhanden ist, das mit kubeadm erstellt wurde. Hostnamen im sekundären System sind so konfiguriert, dass sie primäre Namen nachahmen, wie in den nächsten Absätzen beschrieben. Dann wird das sekundäre Cluster auch mit kubeadm erstellt (wieder nur NACH der erforderlichen Hostnamensauflösung).

Befolgen Sie die folgenden Anforderungen für Restore bei der Konfigurationsplanung:

  1. Stellen Sie sicher, dass die erforderlichen Worker-Knoten und Ressourcen im primären Knoten im sekundären Knoten verfügbar sind.
    Dazu gehören Shared Storage-Mounts, Load Balancer und Datenbanken, die von den Pods und Systemen verwendet werden, die in den wiederherzustellenden Namespaces verwendet werden.
  2. Konfigurieren Sie die Auflösung des Hostnamens so, dass die von der Control- und Worker-Ebene verwendeten Hostnamen in der sekundären Ebene gültig sind.

    Beispiel: Wenn Ihre primäre Site das Cluster wie folgt auflöst:

    [opc@olk8-m1 ~]$ kubectl get nodes -A
NAME      STATUS   ROLES           AGE      VERSION
olk8-m1   Ready    control-plane   552d     v1.25.12
olk8-m2   Ready    control-plane   552d     v1.25.12
olk8-m3   Ready    control-plane   2y213d   v1.25.12
olk8-w1   Ready    <none>          2y213d   v1.25.12
olk8-w2   Ready    <none>          2y213d   v1.25.12
olk8-w3   Ready    <none>          2y213d   v1.25.12
[opc@olk8-m1 ~]$ nslookup olk8-m1
Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   olk8-m1.k8dbfrasubnet.k8dbvcn.oraclevcn.com
Address: 10.11.0.16
    Dann muss Ihre sekundäre Site dieselben Knotennamen verwenden. Im vorherigen Beispielknoten in der Control Plane ist der Hostname in Region 2 derselbe, der einer anderen IP zugeordnet ist.
    [opc@k8dramsnewbastion ~]$ nslookup olk8-m1
Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   olk8-m1.sub01261629121.k8drvcnams.oraclevcn.com
Address: 10.5.176.144

[opc@k8dramsnewbastion ~]$
    Die resultierende sekundäre Konfiguration (nach der Verwendung von kubeadm zum Erstellen des Clusters und Hinzufügen der Worker-Knoten) verwendet genau dieselben Knotennamen, auch wenn interne IPs und andere Werte verzögert werden.
    [opc@k8dramsnewbastion ~]$ kubectl get nodes -A
NAME      STATUS   ROLES           AGE      VERSION
olk8-m1   Ready    control-plane   552d     v1.25.11
olk8-m2   Ready    control-plane   552d     v1.25.11
olk8-m3   Ready    control-plane   2y213d   v1.25.11
olk8-w1   Ready    <none>          2y213d   v1.25.11
olk8-w2   Ready    <none>          2y213d   v1.25.11
olk8-w3   Ready    <none>          2y213d   v1.25.11
  3. Verwenden Sie ein ähnliches Aliasing für den Hostnamen für die Frontend-Adresse kube-api.

    Hinweis:

    Ihr primäres Kubernetes-Cluster darf keine IP-Adressen für das Frontend kube-api verwenden. Sie müssen einen Hostnamen verwenden, damit dieses Frontend im sekundären System mit einem Alias versehen werden kann. Ein Beispiel zum Hinzufügen eines Hostnamenalias zu Ihrem vorhandenen primären kube-api-System finden Sie im Skript maak8s-kube-api-alias.sh.

    Beispiel: Wenn die kube-api-Adressauflösung der Primärdatenbank wie folgt lautet: 
    [opc@olk8-m1 ~]$  grep server .kube/config
    server: https://k8lbr.paasmaaoracle.com:6443
[opc@olk8-m1 ~]$  grep k8lbr.paasmaaoracle.com /etc/hosts
132.145.247.187 k8lbr.paasmaaoracle.com k8lbr
    Dann sollte die sekundäre Datei kube-api denselben Hostnamen verwenden (Sie können sie einer anderen IP zuordnen): 
    [opc@k8dramsnewbastion ~]$ grep server .kube/config
    server: https://k8lbr.paasmaaoracle.com:6443
[opc@k8dramsnewbastion ~]$ grep k8lbr.paasmaaoracle.com /etc/hosts
144.21.37.81 k8lbr.paasmaaoracle.com k8lbr
    Sie können dies erreichen, indem Sie virtuelle Hosts, eine lokale /etc/hosts-Auflösung oder verschiedene DNS-Server an jedem Speicherort verwenden. Um die Methode zur Auflösung des Hostnamens zu bestimmen, die von einem bestimmten Host verwendet wird, suchen Sie nach dem Wert des Hosts-Parameters in der Datei /etc/nsswitch.conf auf dem Host.

    • Wenn Sie Hostnamen lokal auf dem Host auflösen möchten, machen Sie den Dateieintrag zum ersten Eintrag für den Parameter hosts. Wenn files der erste Eintrag für den Parameter hosts ist, werden Einträge in der Hostdatei /etc/hosts zuerst verwendet, um Hostnamen aufzulösen.

      Verwendung der Auflösung des lokalen Hostnamens in der Datei /etc/nsswitch.conf angeben: 

      hosts: files dns nis

    • Wenn Sie Hostnamen mit DNS auf dem Host auflösen möchten, machen Sie den Eintrag dns zum ersten Eintrag für den hosts-Parameter. Wenn dns der erste Eintrag für den Parameter hosts ist, werden DNS-Servereinträge zuerst verwendet, um Hostnamen aufzulösen.

      Verwendung der Datei /etc/nsswitch.conf zur DNS-Hostnamenauflösung angeben: 

      hosts: dns files nis

    Aus Gründen der Einfachheit und Konsistenz empfiehlt Oracle, dass alle Hosts innerhalb einer Site (Produktionssite oder Standbysite) dieselbe Methode zur Auflösung von Hostnamen verwenden (Hostnamen lokal auflösen oder Hostnamen mit separaten DNS-Servern oder einem globalen DNS-Server auflösen).

    Die "Hostname-Aliasing"-Technik wird seit vielen Jahren im Katastrophenschutz für Middleware-Systeme eingesetzt. Details und Beispiele finden Sie in der Oracle-Dokumentation, einschließlich des Oracle Fusion Middleware Disaster Recovery Guide und anderer Dokumente zum Oracle Cloud Disaster Protection, wie Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery und SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  4. Erstellen Sie das sekundäre Cluster mit demselben Hostnamen für den Frontend-Load Balancer kube-api wie im primären Cluster.
    Führen Sie diesen Schritt aus, nachdem die Auflösung des Hostnamens abgeschlossen ist. Weitere Informationen finden Sie in der Dokumentation zum Kubernetes-Tool kubeadm. Verwenden Sie dieselben kubeadm- und Kubernetes-Versionen wie in der primären Version. Container-Laufzeiten können sich verzögern, Sie sollten jedoch in beiden Regionen dieselben Versionen der Kubernetes-Infrastruktur verwenden.
    Beispiel: Das primäre Cluster wurde wie folgt erstellt:
    kubeadm init --control-plane-endpoint $LBR_HN:$LBR_PORT --pod-network-cidr=10.244.0.0/16 --node-name $mnode1 --upload-certs  --v=9

    Verwenden Sie dann dieselben $LBR_HN:$LBR_PORT- und CIDR-Werte in sekundären Werten wie in primären Werten. Dasselbe gilt, wenn Sie andere Clustererstellungstools verwenden, wie kOps und kubesparay.

  5. Wenn Sie zusätzliche Control Plane- oder Worker-Knoten hinzufügen, stellen Sie sicher, dass Sie dieselben Knotennamen in primären und sekundären Knoten verwenden.
    kubeadm join $LBR_HN:$LBR_PORT --token $token --node-name $host --discovery-token-ca-cert-hash $token_ca  --control-plane --certificate-key $cp_ca
  6. Nachdem das sekundäre Cluster konfiguriert wurde, sollten beim Abrufen der Knoteninformationen aus kubernetes dieselben Hostnamen angezeigt werden.

    Die $host-Variablen, die in der sekundären Ebene für jede Control Plane und jeden Worker-Knoten verwendet werden, müssen mit denen in der primären Ebene identisch sein.

    Primäres Cluster

    Führen Sie den folgenden Befehl auf der Primärdatenbank aus, um den Control Plane- und Worker-Knotenstatus, die Rolle, das Alter, die Version, die interne IP, die externe IP, das BS-Image, die Kernelversion und die Containerlaufzeit zu bestätigen:
    [opc@olk8-m1 ~]$ kubectl get nodes -o wide
    Im Folgenden finden Sie eine Beispielausgabe.
    [opc@olk8-m1 ~]$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
olk8-m1 Ready control-plane 578d v1.25.12 10.11.0.16 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1
olk8-m2 Ready control-plane 578d v1.25.12 10.11.210.212 <none> Oracle Linux Server 7.9 5.4.17-2136.301.1.3.el7uek.x86_64 cri-o://1.26.1
olk8-m3 Ready control-plane 2y238d v1.25.12 10.11.0.18 <none> Oracle Linux Server 7.9 4.14.35-2047.527.2.el7uek.x86_64 cri-o://1.26.1
olk8-w1 Ready <none> 2y238d v1.25.12 10.11.0.20 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1
olk8-w2 Ready <none> 2y238d v1.25.12 10.11.0.21 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1
olk8-w3 Ready <none> 2y238d v1.25.12 10.11.0.22 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1
[opc@olk8-m1 ~]$
    Führen Sie den folgenden Befehl auf der Primärdatenbank aus, um zu ermitteln, wo die Kubernetes-Control Plane und das Core-DNS ausgeführt werden. 
    [opc@olk8-m1 ~]$ kubectl cluster-info

    Sekundäres Cluster

    Führen Sie den folgenden Befehl auf der sekundären Ebene aus, um den Control Plane- und Worker-Knotenstatus, die Rolle, das Alter, die Version, die interne IP, die externe IP, das BS-Image, die Kernelversion und die Containerlaufzeit zu bestätigen:
    [opc@k8dramsnewbastion ~]$ kubectl get node -o wide
    Im Folgenden finden Sie eine Beispielausgabe.
    [opc@k8dramsnewbastion ~]$ kubectl get node -o wide
NAME      STATUS   ROLES           AGE      VERSION    INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                  KERNEL-VERSION                     CONTAINER-RUNTIME
olk8-m1   Ready    control-plane   579d     v1.25.11   10.5.176.144   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.21
olk8-m2   Ready    control-plane   579d     v1.25.11   10.5.176.167   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.21
olk8-m3   Ready    control-plane   2y239d   v1.25.11   10.5.176.154   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.21
olk8-w1   Ready    <none>          2y239d   v1.25.11   10.5.176.205   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.22
olk8-w2   Ready    <none>          2y239d   v1.25.11   10.5.176.247   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.22
olk8-w3   Ready    <none>          2y239d   v1.25.11   10.5.176.132   <none>        Oracle Linux Server 8.7   5.15.0-101.103.2.1.el8uek.x86_64   containerd://1.6.22
[opc@k8dramsnewbastion ~]$ kubectl cluster-info
Kubernetes control plane is running at https://k8lbr.paasmaaoracle.com:6443
CoreDNS is running at https://k8lbr.paasmaaoracle.com:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
[opc@k8dramsnewbastion ~]$
    Führen Sie den folgenden Befehl auf der sekundären Ebene aus, um zu ermitteln, wo die Kubernetes-Control Plane und das Core-DNS ausgeführt werden. 
    [opc@k8dramsnewbastion ~]$ kubectl cluster-info

    Mit den Standardeinstellungen beim Erstellen des kubeadm-Clusters verwendet etcd dieselben Ports in Primär- und Sekundärports. Wenn das Cluster in der sekundären Datenbank verschiedene Ports verwenden muss, müssen Sie die Skripte ändern, um sie zu verarbeiten. Sie können verschiedene Speicherorte in Primär- und Sekundärspeicher für die Datenbank etcds verwenden. Die Skripte übernehmen die Wiederherstellung an dem geeigneten Speicherort, den das sekundäre Cluster für etcd verwendet.

  7. Installieren Sie etcdctl sowohl im primären als auch im sekundären Verzeichnis (Knoten, auf denen die Backup- und Restore-Skripte ausgeführt werden).
    Die Skripte für Backup und Restore verwenden etcdctl, um Informationen aus dem Cluster abzurufen und etcd-Snapshots zu erstellen und anzuwenden. Informationen zum Installieren von etcdctl finden Sie in der Dokumentation https://github.com/etcd-io/etcd/releases.
  8. Stellen Sie sicher, dass die entsprechenden Firewall- und Sicherheitsregeln vorhanden sind, damit der Knoten, der die Backup- und Restore-Vorgänge ausführt, für diesen Zugriffstyp aktiviert ist.
    Die Skripte müssen auch mit kubectl auf das Cluster zugreifen und die verschiedenen Knoten über SSH und HTTP erreichen (für Shellbefehle und etcdctl-Vorgänge).

Konfigurieren

Für Disaster Recovery konfigurieren.

Die Schritte für eine Wiederherstellung umfassen:

  1. Erstellen Sie ein etcd-Backup an einem primären Speicherort.
  2. Versenden Sie das Backup an den sekundären Speicherort.
  3. Stellen Sie dieses etcd-Backup in einem sekundären Cluster wieder her.

Führen Sie die folgenden Schritte durch:

  1. Erstellen Sie ein etcd-Backup in einem primären Kubernetes-Cluster.
    1. Laden Sie ALLE Skripte für etcd Snapshot DR aus dem Abschnitt "Code herunterladen" dieses Dokuments herunter.

      Hinweis:

      Alle Skripte müssen sich in demselben Pfad befinden, da die Hauptskripte andere Hilfsskripte verwenden.
    2. Rufen Sie die advert_port von einer Konfiguration des Control-Plane-Knotens etcd ab.
      [opc@olk8-m1 ~]$ sudo grep etcd.advertise-client-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}'

2379
      Gleiches gilt für die init_port: 
      [opc@olk8-m1 ~]$  sudo grep initial-advertise-peer-urls  /etc/kubernetes/manifests/etcd.yaml  | awk -F ":" '{print $NF}'

2380

      Diese Ports sind die Standardports und werden von allen etcd-Pods der Control Plane verwendet. In den seltenen Fällen, in denen etcd angepasst wurde, um einen anderen init- und advertise-Port in jedem Knoten zu verwenden, müssen Sie die Skripte anpassen, um diese zu berücksichtigen. Sie können den Wert für infra_pod_list auch anpassen, wenn andere Netzwerk-Plug-ins verwendet werden oder andere relevante Pods oder Deployments nach der Wiederherstellung in Ihrem speziellen Fall neu gestartet werden müssen. Im Allgemeinen können jedoch die in der Datei angegebenen Werte vorgegeben werden.

    3. Bearbeiten Sie das Skript maak8s.env, und aktualisieren Sie die Variablen entsprechend Ihrer Umgebung.
      Im Folgenden finden Sie eine Beispieldatei maak8s.env:
      [opc@olk8-m1 ~]$ cat maak8s.env
#sudo ready user to ssh into the control plane nodes
export user=opc
#ssh key for the ssh
export ssh_key=/home/opc/KeyMAA.ppk
#etcdctl executable's location
export etcdctlhome=/scratch/etcdctl/
#etcd advertise port
export advert_port=2379
#etcd init cluster port
export init_port=2380
#infrastructure pods that will be restarted  on restore
export infra_pod_list="flannel proxy controller scheduler"
    4. Führen Sie das Skript maak8-etcd-backup.sh aus, und geben Sie als Argumente die folgenden Felder in dieser Reihenfolge an:
      • Das Verzeichnis, in dem das Backup gespeichert wird
      • Ein "LABEL/TEXT", der das Backup beschreibt
      • Der Speicherort der Clusterkonfiguration, in der kubectl-Vorgänge ausgeführt werden sollen
      Beispiel:
      [opc@olk8-m1 ~]$  ./maak8-etcd-backup.sh  /backup-volumes/ "ETCD Snapshot after first configuration " /home/opc/.kubenew/config

    Das Skript führt folgende Schritte aus:

    • Erstellt einen etcd-Snapshot aus dem Masterknoten etcd
    • Erstellt eine Kopie der aktuellen Konfiguration jedes Control-Plane-Knotens (Manifeste und Certs für jeden Control-Plane-Knoten), einschließlich der Signaturschlüssel für das Cluster
    • Zeichnet die Liste der Knoten, Pods, Services und Clusterkonfiguration auf
    • Speichert alle oben genannten Informationen in einem Verzeichnis mit dem Datum. Wenn das im Befehlszeilenargument angegebene Verzeichnis /backup-volume lautet, wird das Backup unter /backup-volume/etcd_snapshot_date des Backups gespeichert. Beispiel: /backup-volume/etcd_snapshot_2022-08-29_15-56-59.
  2. Kopieren Sie das gesamte Verzeichnis (/backup-volume/etcd_snapshot_date) in das sekundäre Cluster.
    1. Verwenden Sie ein sftp-Tool, oder erstellen Sie ein TAR mit dem Verzeichnis, und senden Sie es an den sekundären Speicherort.
    2. Dekomprimieren oder entpacken Sie die Datei, um sie im sekundären System verfügbar zu machen, wie es in der primären Datei war.
    3. Notieren Sie sich das Datumslabel im Backup (im obigen Beispiel wäre das 2022-08-29_15-56-59).
    Beispiel: 
    [opc@olk8-m1 ~]$ scp -i KeyMAA.ppk -qr /backup-volume/etcd_snapshot_2022-08-29_15-56-59 154.21.39.171:/restore-volume
[opc@olk8-m1 ~]$ ssh -i KeyMAA.ppk 154.21.39.171 "ls -lart /restore-volume"
total 4
drwxrwxrwt. 6 root root  252 Aug 30 15:11 ..
drwxrwxr-x. 3 opc  opc    47 Aug 30 15:12 .
drwxrwxr-x. 5 opc  opc  4096 Aug 30 15:12 etcd_snapshot_2022-08-29_15-56-59
  3. Nachdem das Backup im sekundären Speicherort verfügbar ist, führen Sie die folgenden Schritte aus, um es wiederherzustellen:
    1. Laden Sie ALLE Skripte für die Snapshot-DR etcd vom Abschnitt "Code herunterladen" auf den sekundären Regionsknoten herunter, der die Wiederherstellung ausführt.
      Beachten Sie, dass auf diesem Knoten auch etcdctl und kubectl-Zugriff auf das sekundäre Cluster installiert sein müssen.

      Hinweis:

      Da die Hauptskripte andere Hilfsskripte verwenden, müssen sich bei der Ausführung der verschiedenen Schritte alle Skripte im selben Pfad befinden.
    2. Bearbeiten Sie das Skript maak8s.env, und aktualisieren Sie die Variablen entsprechend Ihrer Umgebung.
      Sie können den Benutzer, den SSH-Schlüssel und das Verzeichnis etcdctl entsprechend Ihren sekundären Knoten ändern. Die Ports advert und init müssen jedoch mit den Ports identisch sein, die in der Primärdatenbank verwendet werden.
      Im Folgenden finden Sie eine Beispieldatei maak8s.env:
      [opc@olk8-m1 ~]$ cat maak8s.env
#sudo ready user to ssh into the control plane nodes
export user=opc
#ssh key for the ssh
export ssh_key=/home/opc/KeyMAA.ppk
#etcdctl executable's location
export etcdctlhome=/scratch/etcdctl/
#etcd advertise port
export advert_port=2379
#etcd init cluster port
export init_port=2380
#infrastructure pods that will be restarted  on restore
export infra_pod_list="flannel proxy controller scheduler"
    3. Führen Sie die Wiederherstellung mit dem Skript maak8-etcd-restore.sh aus. Geben Sie als Argumente das Root-Verzeichnis an, in das das Backup von der Primär- in die Standbydatenbank kopiert wurde, den Zeitstempel des Backups und den Speicherort der kubectl-Konfiguration für das Cluster an.
      Beispiel: 
      [opc@k8dramsnewbastion ~]$ ./maak8-etcd-restore.sh /restore-volume 2022-08-29_15-56-59 /home/opc/.kube/config

      Das Skript sucht im Verzeichnis /restore-volume nach einem Unterverzeichnis namens etcd_snapshot_date. Im Beispiel wird /restore-volume/etcd_snapshot_2022-08-29_15-56-59 verwendet.

      Bei der Wiederherstellung gehen Sie wie folgt vor:
      • Force stoppt die Kontrollebene im sekundären Modus, wenn sie ausgeführt wird
      • Stellt den Snapshot etcd in allen Control-Plane-Knoten wieder her
      • Ersetzt die Cluster-Signaturschlüssel in allen Control-Plane-Knoten
      • Startet die Control Plane
      • Recycelt alle Infrastruktur-Pods (Proxy, Scheduler, Controller) und Deployments im Cluster (um sie in einen konsistenten Status zu versetzen)

      Am Ende der Wiederherstellung zeigt ein Bericht den Status der Pods und des etcd-Subsystems an. Beispiel: 

      NAMESPACE      NAME                                         READY   STATUS              RESTARTS       AGE
default        dnsutils                                     1/1     Running             0              27d
default        nginx-deployment-566ff9bd67-6rl7f            1/1     Running             0              19s
default        nginx-deployment-566ff9bd67-hnx69            1/1     Running             0              17s
default        nginx-deployment-566ff9bd67-hvrwq            1/1     Running             0              15s
default        test-pd                                      1/1     Running             0              26d
kube-flannel   kube-flannel-ds-4f2fz                        1/1     Running             3 (22d ago)    35d
kube-flannel   kube-flannel-ds-cvqzh                        1/1     Running             3 (22d ago)    35d
kube-flannel   kube-flannel-ds-dmbhp                        1/1     Running             3 (22d ago)    35d
kube-flannel   kube-flannel-ds-skhz2                        1/1     Running             3 (22d ago)    35d
kube-flannel   kube-flannel-ds-zgkkp                        1/1     Running             4 (22d ago)    35d
kube-flannel   kube-flannel-ds-zpbn7                        1/1     Running             3 (22d ago)    35d
kube-system    coredns-8f994fbf8-6ghs4                      0/1     ContainerCreating   0              15s
kube-system    coredns-8f994fbf8-d79h8                      1/1     Running             0              19s
kube-system    coredns-8f994fbf8-wcknd                      1/1     Running             0              12s
kube-system    coredns-8f994fbf8-zh8w4                      1/1     Running             0              19s
kube-system    etcd-olk8-m1                                 1/1     Running             22 (89s ago)   44s
kube-system    etcd-olk8-m2                                 1/1     Running             59 (88s ago)   44s
kube-system    etcd-olk8-m3                                 1/1     Running             18 (88s ago)   26s
kube-system    kube-apiserver-olk8-m1                       1/1     Running             26 (89s ago)   44s
kube-system    kube-apiserver-olk8-m2                       1/1     Running             60 (88s ago)   42s
kube-system    kube-apiserver-olk8-m3                       1/1     Running             18 (88s ago)   27s
kube-system    kube-controller-manager-olk8-m1              1/1     Running             19 (89s ago)   10s
kube-system    kube-controller-manager-olk8-m2              1/1     Running             18 (88s ago)   10s
kube-system    kube-controller-manager-olk8-m3              1/1     Running             18 (88s ago)   10s
kube-system    kube-flannel-ds-62dcq                        1/1     Running             0              19s
kube-system    kube-flannel-ds-bh5w7                        1/1     Running             0              19s
kube-system    kube-flannel-ds-cc2rk                        1/1     Running             0              19s
kube-system    kube-flannel-ds-p8kdk                        1/1     Running             0              19s
kube-system    kube-flannel-ds-vj8r8                        1/1     Running             0              18s
kube-system    kube-flannel-ds-wz2kv                        1/1     Running             0              18s
kube-system    kube-proxy-28d98                             1/1     Running             0              14s
kube-system    kube-proxy-2gb99                             1/1     Running             0              15s
kube-system    kube-proxy-4dfjd                             1/1     Running             0              14s
kube-system    kube-proxy-72l5q                             1/1     Running             0              14s
kube-system    kube-proxy-s8zbs                             1/1     Running             0              14s
kube-system    kube-proxy-tmqnm                             1/1     Running             0              14s
kube-system    kube-scheduler-olk8-m1                       0/1     Pending             0              5s
kube-system    kube-scheduler-olk8-m2                       1/1     Running             18 (88s ago)   5s
kube-system    kube-scheduler-olk8-m3                       1/1     Running             18 (88s ago)   5s
newopns        weblogic-operator-5d74f56886-mtjp6           0/1     Terminating         0              26d
newopns        weblogic-operator-webhook-768d9f6f79-tdt8b   0/1     Terminating         0              26d
soans          soaedgdomain-adminserver                     0/1     Running             0              22d
soans          soaedgdomain-soa-server1                     0/1     Running             0              22d
soans          soaedgdomain-soa-server2                     0/1     Running             0              22d
+--------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|   ENDPOINT   |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+--------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| olk8-m1:2379 | 63c63522f0be24a6 |   3.5.6 |  146 MB |      true |      false |         2 |       1195 |               1195 |        |
| olk8-m2:2379 | 697d3746d6f10842 |   3.5.6 |  146 MB |     false |      false |         2 |       1195 |               1195 |        |
| olk8-m3:2379 |  7a23c67093a3029 |   3.5.6 |  146 MB |     false |      false |         2 |       1195 |               1195 |        |
+--------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
+------------------+---------+---------+----------------------+---------------------------+------------+
|        ID        | STATUS  |  NAME   |      PEER ADDRS      |       CLIENT ADDRS        | IS LEARNER |
+------------------+---------+---------+----------------------+---------------------------+------------+
|  7a23c67093a3029 | started | olk8-m3 | https://olk8-m3:2380 | https://10.5.176.154:2379 |      false |
| 63c63522f0be24a6 | started | olk8-m1 | https://olk8-m1:2380 | https://10.5.176.144:2379 |      false |
| 697d3746d6f10842 | started | olk8-m2 | https://olk8-m2:2380 | https://10.5.176.167:2379 |      false |
+------------------+---------+---------+----------------------+---------------------------+------------+
Restore completed at 2023-08-30_15-18-22
[opc@k8dramsnewbastion ~]$

Verifizieren

Nachdem Sie das Skript maak8DR-apply.sh ausgeführt haben, prüfen Sie, ob alle Artefakte, die im primären Cluster vorhanden waren, im sekundären Cluster repliziert wurden. Prüfen Sie das sekundäre Cluster, und prüfen Sie, ob die Pods auf der sekundären Site fehlerfrei ausgeführt werden.
  1. Prüfen Sie den Status des Sekundärs, bis die erforderlichen Pods mit dem Status des Primärs ü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.
  2. Prüfen Sie das restore-Log in der Sekundärdatei auf mögliche Fehler.
    Der Logspeicherort wird zu Beginn der Wiederherstellung gemeldet. Standardmäßig wird das Log unter dem Verzeichnis erstellt, in dem sich das Backup selbst befindet, unter /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/restore.log. Ein anderes Log wird speziell für den Snapshot-Wiederherstellungsvorgang etcd /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log erstellt.
  3. (Optional) Zurücksetzen.

    Zusätzlich zu den Wiederherstellungslogs wird ein Backup der vorherigen /etc/kubernetes-Konfiguration für jeden der Control-Plane-Knoten unter dem Verzeichnis /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/current_etc_kubernetes erstellt. Ebenso werden die etcd-Datenbanken in jedem Knoten vor der Wiederherstellung in /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_name kopiert. Mit diesen können Sie die Clusterkonfiguration wiederherstellen, die vor der Ausführung der Wiederherstellung vorhanden war.