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

Für Disaster Recovery konfigurieren

Mit den mit 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 sowohl Kubernetes-Cluster, einschließlich der Control-Plane- als auch 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.

Hinweis:

Bei dieser Lösung wird davon ausgegangen, dass sowohl Kubernetes-Cluster, einschließlich der Control-Plane- als auch Worker-Knoten, bereits vorhanden sind. Die in diesem Playbook bereitgestellten Empfehlungen und Utilitys 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 "mirror" sind (gleiche Anzahl von Control-Plane-Knoten, gleiche Anzahl von Worker-Knoten). Bei den Prozeduren wird davon ausgegangen, dass ein primäres Kubernetes-Cluster, das mit kubeadm erstellt wurde, vorhanden ist. Hostnamen im sekundären System sind so konfiguriert, dass sie primär nachahmen, wie in den nächsten Absätzen beschrieben. Dann wird das sekundäre Cluster auch mit kubeadm erstellt (auch wenn die erforderliche Hostnamensauflösung nicht berücksichtigt wird).

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

  1. Bestätigen Sie, dass die erforderlichen Worker-Knoten und -Ressourcen im primären Knoten sekundär 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 Hostnamensauflösung so, dass die von der Steuerungs- und Worker-Ebene verwendeten Hostnamen sekundär 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 die sekundäre Site dieselben Knotennamen verwenden. Im vorherigen Beispielknoten in der Control Plane ist der Hostname in Region 2 mit einem anderen IP identisch.
    [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 Konfiguration in einer sekundären Konfiguration (nach Verwendung von kubeadm zum Erstellen des Clusters und Hinzufügen der Worker-Knoten) verwendet genau dieselben Knotennamen, selbst wenn interne IPs und andere Werte verschoben 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 eine ähnliche "Hostnamen-Aliasing" für die Frontend-Adresse kube-api.

    Hinweis:

    Ihr primäres Kubernetes-Cluster darf keine IPs für das Frontend kube-api verwenden. Sie müssen einen Hostnamen verwenden, damit dieses Frontend im sekundären System verknüpft werden kann. Im Skript maak8s-kube-api-alias.sh finden Sie ein Beispiel dafür, wie Sie Ihrem vorhandenen primären kube-api-System einen Hostnamenalias hinzufügen.

    Beispiel: Die Auflösung der kube-api-Adresse der primären Adresse lautet wie folgt: 
    [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 muss kube-api des sekundären Benutzers denselben Hostnamen verwenden (Sie können ihn 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
    Dazu können Sie virtuelle Hosts, die lokale /etc/hosts-Auflösung oder einen anderen DNS-Server in jedem Speicherort verwenden. Um die Hostnamensauflösungsmethode 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 die Dateieingabe 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 zur Auflösung von Hostnamen verwendet.

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

      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 Parameter "hosts". Wenn DNS der erste Eintrag für den Parameter hosts ist, werden zuerst DNS-Servereinträge verwendet, um Hostnamen aufzulösen.

      Angeben der DNS-Hostnamensauflösungsdatei /etc/nsswitch.conf: 

      hosts: dns files nis

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

    Die "Host Name Aliasing"-Technik wird seit vielen Jahren in Disaster Protection for Middleware Systems eingesetzt. Details und Beispiele finden Sie in der Dokumentation von Oracle, einschließlich des Oracle Fusion Middleware Disaster Recovery Guide und anderer Dokumente zu Oracle Cloud Disaster Protection, wie Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery und SOA Suite auf 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 in der primären Datenbank.
    Führen Sie diesen Schritt aus, nachdem Ihre Hostnamenauflösung bereit 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. Containerlaufzeiten können sich verzögern, Sie sollten jedoch dieselben Versionen der Kubernetes-Infrastruktur in beiden Regionen verwenden.
    Beispiel: Wenn das primäre Cluster wie folgt erstellt wurde:
    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 genau dieselben $LBR_HN:$LBR_PORT- und CIDR-Werte in der sekundären wie in der primären Datenbank. Dasselbe gilt, wenn Sie andere Tools zur Clustererstellung verwenden, wie kOps und kubesparay.

  5. Stellen Sie beim Hinzufügen von zusätzlichen Control-Plane- oder Worker-Knoten sicher, dass Sie dieselben Knotennamen in Primär- und Sekundärknoten 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, müssen beim Abrufen der Knoteninformationen aus kubernetes dieselben Hostnamen angezeigt werden.

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

    Primäres Cluster

    Führen Sie den folgenden Befehl auf der primären Ebene aus, um den Status, 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ären Ebene 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ärseite aus, um den Status, 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 sekundär aus, um anzugeben, wo die Kubernetes-Control Plane und das Core-DNS ausgeführt werden. 
    [opc@k8dramsnewbastion ~]$ kubectl cluster-info

    Wenn die Standardeinstellungen für die Clustererstellung kubeadm lauten, verwendet etcd dieselben Ports in primärer und sekundärer Datenbank. Wenn das Cluster auf der sekundären Seite verschiedene Ports verwenden muss, müssen Sie die Skripte ändern, um es zu verarbeiten. Sie können verschiedene Speicherorte in Primär- und Sekundärspeicherorten für die Datenbank etcds verwenden. Die Skripte kümmern sich um die Wiederherstellung an dem entsprechenden 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, die Backup- und Restore-Skripte ausführen).
    Die Skripte für Backup und Restore verwenden etcdctl, um Informationen aus dem Cluster abzurufen und etcd-Snapshots zu erstellen und anzuwenden. Informationen zur Installation 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 außerdem mit kubectl auf das Cluster zugreifen und die verschiedenen Knoten über SSH und HTTP (für Shellbefehle und etcdctl-Vorgänge) abrufen.

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. Senden Sie das Backup an den sekundären Standort.
  3. Stellen Sie dieses etcd-Backup in einem sekundären Cluster wieder her.

Gehen Sie wie folgt vor:

  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 im selben Pfad befinden, da die Hauptskripte andere Hilfsskripte verwenden.
    2. Rufen Sie die advert_port aus der Konfiguration eines Control-Plane-Knotens etcd ab.
      [opc@olk8-m1 ~]$ sudo grep etcd.advertise-client-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}'

2379
      Und dasselbe für 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 seltenen Fällen, in denen etcd an die Verwendung eines anderen init- und advertise-Ports in jedem Knoten angepasst wurde, müssen Sie die Skripte so anpassen, dass sie diese 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 bestimmten Fall neu gestartet werden müssen. Im Allgemeinen kann es jedoch auf die in der Datei angegebenen Werte gesetzt werden.

    3. Bearbeiten Sie das Skript maak8s.env, und aktualisieren Sie die Variablen entsprechend Ihrer Umgebung.
      Die folgende maak8s.env-Beispieldatei ist:
      [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 die folgenden Felder in dieser Reihenfolge als Argumente an:
      • Das Verzeichnis, in dem das Backup gespeichert wird
      • Ein "LABEL/TEXT" mit einer Beschreibung des Backups
      • Der Speicherort der Clusterkonfiguration zur Ausführung von kubectl-Vorgängen
      Beispiel:
      [opc@olk8-m1 ~]$  ./maak8-etcd-backup.sh  /backup-volumes/ "ETCD Snapshot after first configuration " /home/opc/.kubenew/config

    Das Skript führt die folgenden Schritte aus:

    • Erstellt einen etcd-Snapshot vom 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 mit dem Datum gekennzeichneten Verzeichnis. 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 einen tar mit dem Verzeichnis, und senden Sie ihn an den sekundären Speicherort.
    2. Dekomprimieren oder entpacken Sie die Datei, um sie im sekundären System wie im primären System verfügbar zu machen.
    3. Notieren Sie sich das Datumslabel im Backup (im obigen Beispiel wäre es 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. Wenn 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 etcd-Snapshot DR aus dem Abschnitt "Code herunterladen" in den sekundären Regionsknoten herunter, der die Wiederherstellung ausführt.
      Beachten Sie, dass für diesen Knoten auch etcdctl installiert und kubectl auf das sekundäre Cluster zugreifen muss.

      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-, SSH- und etcdctl-Speicherort entsprechend den sekundären Knoten ändern. Die Ports advert und init müssen jedoch mit den Ports identisch sein, die in der primären Datenbank verwendet werden.
      Die folgende maak8s.env-Beispieldatei ist:
      [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ären in die Standby-Datenbank kopiert wurde, den Zeitstempel des Backups und den Speicherort der kubectl-Konfiguration für das Cluster.
      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. In diesem Beispiel wird /restore-volume/etcd_snapshot_2022-08-29_15-56-59 verwendet.

      Bei der Wiederherstellung werden die folgenden Schritte ausgeführt:
      • Erzwingen, dass die Control Plane in der sekundären Ebene gestoppt wird, wenn sie ausgeführt wird
      • Stellt den Snapshot etcd in allen Control-Plane-Knoten wieder her
      • Ersetzt die Clustersignaturschlüssel in allen Control-Plane-Knoten
      • Startet die Control Plane
      • Schaltet alle Infrastrukturpods (Proxy, Scheduler, Controller) und Deployments im Cluster um (um sie in einen konsistenten Status zu versetzen)

      Am Ende der Wiederherstellung wird in einem Bericht der Status der Pods und des etcd-Subsystems angezeigt. 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

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.
  1. 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.
  2. Prüfen Sie das restore-Log in der sekundären Datei 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 befand, unter /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/restore.log. Ein anderes Log wird speziell für den Snapshot-Wiederherstellungsvorgang /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log von etcd erstellt.
  3. (Optional) Kehren Sie zurück.

    Zusätzlich zu den Restore-Logs 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. Gleichermaßen werden die etcd-Datenbanken in jedem Knoten VOR der Wiederherstellung nach /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_name kopiert. Mit diesen Optionen können Sie die Clusterkonfiguration wiederherstellen, die vor der Ausführung der Wiederherstellung vorhanden war.