Configura per disaster recovery

È possibile utilizzare le procedure e gli script forniti con questa guida di soluzione per creare uno snapshot etcd in un cluster Kubernetes primario e ripristinarlo in un altro cluster Kubernetes (secondario) o nel cluster di origine stesso. È importante pianificare la configurazione e comprendere i requisiti prima di scaricare e utilizzare gli script per configurare lo snapshot.

Nota

Questa soluzione presuppone che entrambi i cluster Kubernetes, inclusi il piano di controllo e i nodi di lavoro, esistano già.

Pianificare la configurazione

Pianificare le risorse e la configurazione nel sistema secondario in base al sistema principale.

Nota

Questa soluzione presuppone che entrambi i cluster Kubernetes, inclusi il piano di controllo e i nodi di lavoro, esistano già. I suggerimenti e le utility forniti in questa guida non controllano le risorse, il piano di controllo o la capacità e la configurazione dei nodi di lavoro.

Il ripristino, come descritto qui, può essere applicato nei cluster che "mirror" primari (stesso numero di nodi del piano di controllo, stesso numero di nodi di lavoro). Le procedure presuppongono l'esistenza di un cluster Kubernetes primario creato con kubeadm. I nomi host nel sistema secondario sono configurati per imitare il database primario, come descritto nei paragrafi successivi. Quindi, il cluster secondario viene creato anche con kubeadm (di nuovo solo dopo aver risolto il nome host richiesto).

Quando si pianifica la configurazione, completare i seguenti requisiti per Restore:

Verificare che i nodi di lavoro e le risorse necessarie nel database primario siano disponibili nel database secondario.
Sono inclusi gli accessi dello storage condiviso, i load balancer e i database utilizzati dai pod e dai sistemi utilizzati negli spazi dei nomi che verranno ripristinati.

Configurare la risoluzione del nome host in modo che i nomi host utilizzati dal piano di controllo e lavoratore siano validi come secondari.

Ad esempio, se il sito principale risolve il cluster in modo simile al seguente:

[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

Il sito secondario deve quindi utilizzare gli stessi nomi di nodo. Nel nodo di esempio precedente nel piano di controllo, il nome host nell'area 2 sarà lo stesso mappato a un IP diverso.

[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 ~]$

La configurazione risultante in secondaria (dopo aver utilizzato kubeadm per creare il cluster e aggiungere i nodi di lavoro) utilizzerà gli stessi nomi di nodo, anche se gli IP interni e altri valori differiscono.

[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

Utilizzare un "aliasing del nome host" simile per l'indirizzo front-end kube-api.

Nota

Il cluster Kubernetes primario NON deve utilizzare gli indirizzi IP per il frontend kube-api. È necessario utilizzare un nome host in modo che questo frontend possa essere alias nel sistema secondario. Per un esempio su come aggiungere un alias di nome host al sistema kube-api primario esistente, vedere lo script maak8s-kube-api-alias.sh.
Ad esempio, se la risoluzione dell'indirizzo kube-api del primario è la seguente:
```
[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
```
Quindi, kube-api del secondario deve utilizzare lo stesso nome host (è possibile mapparlo a un IP diverso):
```
[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
```
È possibile ottenere questo risultato utilizzando host virtuali, risoluzione /etc/hosts locale o server DNS diversi in ciascuna posizione. Per determinare il metodo di risoluzione dei nomi host utilizzato da un determinato host, cercare il valore del parametro hosts nel file /etc/nsswitch.conf sull'host.
- Se si desidera risolvere i nomi host localmente sull'host, rendere la voce dei file la prima voce per il parametro hosts. Quando files è la prima voce per il parametro hosts, le voci nel file /etc/hosts dell'host vengono utilizzate per risolvere i nomi host.
  
  Specifica dell'utilizzo della risoluzione dei nomi host locali nel file /etc/nsswitch.conf:
```
hosts: files dns nis
```
- Se si desidera risolvere i nomi host utilizzando il DNS sull'host, fare in modo che la voce dns sia la prima voce del parametro hosts. Quando dns è la prima voce per il parametro hosts, le voci del server DNS vengono utilizzate per risolvere i nomi host.
  
  Specifica dell'uso del file /etc/nsswitch.conf di risoluzione del nome host DNS:
```
hosts: dns files nis
```
Per semplicità e coerenza, Oracle consiglia a tutti gli host all'interno di un sito (sito di produzione o sito di standby) di utilizzare lo stesso metodo di risoluzione dei nomi host (risoluzione dei nomi host a livello locale o risoluzione dei nomi host mediante server DNS separati o un server DNS globale).

La tecnica di "host name aliasing" è stata utilizzata per molti anni in Disaster Protection for Middleware systems. Puoi trovare dettagli ed esempi nella documentazione di Oracle, tra cui Oracle Fusion Middleware Disaster Recovery Guide e altri documenti relativi a Oracle Cloud Disaster Protection, come Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery e SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery.
Creare il cluster secondario utilizzando lo stesso nome host per il load balancer kube-api front-end del database primario.
Eseguire questo passo al termine della risoluzione del nome host. Consulta la documentazione sullo strumento kubeadm di Kubernetes. Utilizzare le stesse versioni kubeadm e Kubernetes del database primario. I runtime dei container potrebbero differire, ma dovresti usare le stesse versioni dell'infrastruttura Kubernetes in entrambe le aree.
Ad esempio, se il cluster primario è stato creato con gli elementi riportati di seguito.
```
kubeadm init --control-plane-endpoint $LBR_HN:$LBR_PORT --pod-network-cidr=10.244.0.0/16 --node-name $mnode1 --upload-certs  --v=9
```
Quindi, utilizzare gli stessi valori $LBR_HN:$LBR_PORT e CIDR in secondario come in primario. Lo stesso vale se si utilizzano altri strumenti di creazione cluster, ad esempio kOps e kubesparay.

Quando si aggiungono ulteriori piani di controllo o nodi di lavoro, assicurarsi di utilizzare gli stessi nomi di nodo in primario e secondario.

kubeadm join $LBR_HN:$LBR_PORT --token $token --node-name $host --discovery-token-ca-cert-hash $token_ca  --control-plane --certificate-key $cp_ca

Una volta configurato il cluster secondario, quando si recuperano le informazioni sul nodo da kubernetes devono essere visualizzati gli stessi nomi host.

Le variabili $host utilizzate nelle variabili secondarie per ogni piano di controllo e nodi di lavoro devono essere uguali a quelle utilizzate nelle variabili primarie.

Cluster primario

Eseguire il comando seguente su database primario per confermare lo stato del piano di controllo e del nodo di lavoro, ruolo, età, versione, IP interno, IP esterno, immagine del sistema operativo, versione del kernel e runtime del contenitore:

[opc@olk8-m1 ~]$ kubectl get nodes -o wide

Di seguito viene fornito un esempio di output.

[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 ~]$

Eseguire il comando seguente sul database primario per identificare la posizione in cui sono in esecuzione il piano di controllo Kubernetes e il DNS di base.

[opc@olk8-m1 ~]$ kubectl cluster-info

Cluster secondario

Eseguire il comando seguente su secondario per confermare lo stato del piano di controllo e del nodo di lavoro, ruolo, età, versione, IP interno, IP esterno, immagine del sistema operativo, versione del kernel e runtime del contenitore:

[opc@k8dramsnewbastion ~]$ kubectl get node -o wide

Di seguito viene fornito un esempio di output.

[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 ~]$

Eseguire il comando seguente su secondario per identificare la posizione in cui sono in esecuzione il piano di controllo Kubernetes e il DNS principale.

[opc@k8dramsnewbastion ~]$ kubectl cluster-info

Con le impostazioni predefinite nella creazione del cluster kubeadm, etcd utilizzerà le stesse porte in primaria e secondaria. Se il cluster in secondario deve utilizzare porte diverse, è necessario modificare gli script per gestirlo. È possibile utilizzare posizioni di memorizzazione diverse nel database primario e secondario per il database etcds. Gli script si occuperanno del ripristino nella posizione appropriata utilizzata dal cluster secondario per etcd.

Installare etcdctl sia nella posizione primaria che in quella secondaria (nodi che eseguono gli script di backup e ripristino).
Gli script per il backup e il ripristino utilizzeranno etcdctl per ottenere informazioni dal cluster e per creare e applicare snapshot etcd. Per installare etcdctl, consultare la documentazione https://github.com/etcd-io/etcd/releases.
Assicurarsi che il firewall e le regole di sicurezza appropriate siano in vigore in modo che il nodo che esegue le operazioni di backup e ripristino sia abilitato per questo tipo di accesso.
Gli script dovranno inoltre accedere al cluster con kubectl e raggiungere i diversi nodi tramite SSH e HTTP (per i comandi della shell e le operazioni etcdctl).

Configura

Configurazione per il disaster recovery.

I passi per un ripristino includono quanto segue:

Eseguire un backup etcd in una posizione primaria.
Spedire il backup nella posizione secondaria.
Ripristinare il backup etcd in un cluster secondario.

Effettuare le seguenti operazioni:

Creare un backup etcd in un cluster Kubernetes primario.
1. Scaricare TUTTI gli script per lo snapshot DR etcd dalla sezione "Scarica codice" di questo documento.
  
  Nota
  Tutti gli script devono trovarsi nello stesso percorso perché gli script principali utilizzano altri script ausiliari.
2. Ottenere advert_port da una configurazione del nodo del piano di controllo etcd.
```
[opc@olk8-m1 ~]$ sudo grep etcd.advertise-client-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}'

2379
```
  E lo stesso per il init_port:
```
[opc@olk8-m1 ~]$  sudo grep initial-advertise-peer-urls  /etc/kubernetes/manifests/etcd.yaml  | awk -F ":" '{print $NF}'

2380
```
  Queste porte sono quelle predefinite e vengono utilizzate da tutti i pod etcd del piano di controllo. Nelle rare situazioni in cui etcd è stato personalizzato per utilizzare una porta init e advertise diversa in ciascun nodo, è necessario personalizzare gli script in modo da considerarli. È inoltre possibile personalizzare il valore per infra_pod_list se vengono utilizzati altri plugin di rete oppure se altri pod o distribuzioni pertinenti devono essere riavviati dopo il ripristino nel caso specifico. Tuttavia, in generale, può essere utilizzato come valore predefinito i valori forniti nel file.
3. Modificare lo script maak8s.env e aggiornare le variabili in base all'ambiente in uso.
  Il file maak8s.env di esempio è il seguente:
```
[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. Eseguire lo script maak8-etcd-backup.sh e fornire come argomenti i seguenti campi in questo ordine:
  - La directory in cui verrà memorizzato il backup
  - Un "LABEL/TEXT" che descrive il backup
  - La posizione della configurazione cluster per eseguire le operazioni kubectl
  Ad esempio:
```
[opc@olk8-m1 ~]$  ./maak8-etcd-backup.sh  /backup-volumes/ "ETCD Snapshot after first configuration " /home/opc/.kubenew/config
```
Lo script esegue i task riportati di seguito.
- Crea uno snapshot etcd dal nodo principale etcd
- Crea una copia della configurazione corrente di ogni nodo del piano di controllo (manifesti e certificati per ogni nodo del piano di controllo), incluse le chiavi di firma per il cluster
- Registra la lista di nodi, pod, servizi e configurazione cluster
- Memorizza tutte le informazioni precedenti in una directory con etichetta data. Se la directory specificata nell'argomento della riga di comando è /backup-volume, il backup viene memorizzato in /backup-volume/etcd_snapshot_date del backup. Ad esempio, /backup-volume/etcd_snapshot_2022-08-29_15-56-59.
Copiare l'intera directory (/backup-volume/etcd_snapshot_date) nel cluster secondario.
1. Utilizzare uno strumento sftp o creare un file tar con la directory e inviarlo alla posizione secondaria.
2. Decomprimere o decomprimere il file per renderlo disponibile nel sistema secondario, come nel sistema primario.
3. Prendere nota dell'etichetta data nel backup (nell'esempio sopra sarebbe 2022-08-29_15-56-59).
Di seguito sono riportati alcuni esempi.
```
[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
```

Una volta che il backup è disponibile nella posizione secondaria, segui questi passaggi per ripristinarlo:

Scaricare TUTTI gli script per il DR dello snapshot etcd dalla sezione "Scarica codice" al nodo dell'area secondaria che eseguirà il ripristino.
Tenere presente che in questo nodo devono essere installati anche etcdctl e l'accesso kubectl al cluster secondario.

Nota
Poiché gli script principali utilizzano altri script ausiliari, è necessario disporre di tutti gli script nello stesso percorso durante l'esecuzione dei vari passi.

Modificare lo script maak8s.env e aggiornare le variabili in base all'ambiente in uso.

È possibile modificare l'utente, la chiave SSH e la posizione etcdctl in base ai nodi secondari, ma le porte advert e init devono essere uguali a quelle utilizzate nei nodi primari.

Il file maak8s.env di esempio è il seguente:

[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"

Eseguire il ripristino utilizzando lo script maak8-etcd-restore.sh. Fornire, come argomenti, la directory radice in cui il backup è stato copiato dal database primario al database in standby, l'indicatore orario del backup e la posizione della configurazione kubectl per il cluster.

Di seguito sono riportati alcuni esempi.

[opc@k8dramsnewbastion ~]$ ./maak8-etcd-restore.sh /restore-volume 2022-08-29_15-56-59 /home/opc/.kube/config

Lo script cerca nella directory /restore-volume una sottodirectory denominata etcd_snapshot_date. Utilizzando l'esempio, verrà utilizzato /restore-volume/etcd_snapshot_2022-08-29_15-56-59.

Il ripristino esegue i task riportati di seguito.

Forza ferma il piano di controllo in secondario, se è in esecuzione
Ripristina lo snapshot etcd in tutti i nodi del piano di controllo
Sostituisce le chiavi di firma del cluster in tutti i nodi del piano di controllo
Avvia il piano di controllo
Ricicla tutti i pod dell'infrastruttura (proxy, scheduler, controller) e le distribuzioni nel cluster (per portarlo a uno stato coerente)

Al termine del ripristino, un report visualizza lo stato dei pod e del sottosistema etcd. Di seguito sono riportati alcuni esempi.

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 ~]$

Verifica

Dopo aver eseguito lo script maak8DR-apply.sh, verificare che tutti gli artifact esistenti nel cluster primario siano stati replicati nel cluster secondario. Esaminare il cluster secondario e verificare che i pod nel sito secondario siano in esecuzione senza errori.

Controllare lo stato del secondario fino a quando i pod richiesti non corrispondono allo stato in primario.
Per impostazione predefinita, i pod e le distribuzioni vengono avviati nell'area secondaria. Al termine del ripristino, viene visualizzato lo stato del cluster secondario. Alcuni pod potrebbero richiedere più tempo per raggiungere lo stato RUNNING.
Controllare la presenza di eventuali errori nel login secondario restore.
La posizione del log viene segnalata all'inizio del ripristino. Per impostazione predefinita, il log viene creato nella directory in cui si trovava il backup stesso, in /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/restore.log. Viene creato un altro log specifico per l'operazione di ripristino dello snapshot etcd /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log.
(Facoltativo) Ripristinare.

Oltre ai log di ripristino, viene creato un backup della configurazione /etc/kubernetes precedente per ciascuno dei nodi dei piani di controllo nella directory /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/current_etc_kubernetes. Analogamente, i database etcd in ogni nodo PRIMA del ripristino vengono copiati in /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_name. È possibile utilizzarle per ripristinare la configurazione cluster esistente prima dell'esecuzione del ripristino.