Configuration pour la récupération après sinistre

Vous pouvez utiliser les procédures et les scripts fournis avec ce manuel de solutions pour créer un cliché etcd dans un cluster Kubernetes principal et le restaurer dans un autre cluster Kubernetes (secondaire) ou dans le cluster source lui-même. Il est important de planifier la configuration et de comprendre les exigences avant de télécharger et d'utiliser les scripts pour configurer votre instantané.

Remarques :

Cette solution suppose que les clusters Kubernetes, y compris le plan de contrôle et les noeuds de processus actif, existent déjà.

Planification de la configuration

Planifiez les ressources et la configuration sur le système secondaire en fonction du système principal.

Remarques :

Cette solution suppose que les clusters Kubernetes, y compris le plan de contrôle et les noeuds de processus actif, existent déjà. Les recommandations et les utilitaires fournis dans ce manuel ne vérifient pas les ressources, le plan de contrôle ou la capacité et la configuration des noeuds de processus actifs.

La restauration, comme décrit ici, peut être appliquée dans des clusters qui mettent en miroir le noeud principal (même nombre de noeuds de plan de contrôle, même nombre de noeuds de processus actif). Les procédures supposent qu'un cluster Kubernetes principal créé avec kubeadm existe. Les noms d'hôte dans le système secondaire sont configurés pour imiter le serveur principal, comme décrit dans les paragraphes suivants. Ensuite, le cluster secondaire est également créé avec kubeadm (encore une fois, la résolution de nom d'hôte requise est prise en charge).

Suivez les exigences suivantes pour Restore lors de la planification de votre configuration :

Vérifiez que les ressources et les noeuds de processus actif requis dans la base principale sont disponibles dans la base secondaire.
Cela inclut les montages de stockage partagé, les équilibreurs de charge et les bases de données utilisés par les pods et les systèmes utilisés dans les espaces de noms qui seront restaurés.

Configurez la résolution de votre nom d'hôte de sorte que les noms d'hôte utilisés par le contrôle et le plan de travail soient valides en secondaire.

Par exemple, si votre site principal résout le cluster de la manière suivante :

[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

Votre site secondaire doit ensuite utiliser les mêmes noms de noeud. Dans l'exemple de noeud précédent du plan de contrôle, le nom d'hôte de la région 2 sera identique à celui mis en correspondance avec une adresse IP différente.

[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 configuration résultante en secondaire (après avoir utilisé kubeadm pour créer le cluster et ajouter les noeuds de processus actif) utilisera exactement les mêmes noms de noeud, même si les adresses IP internes et les autres valeurs sont différées.

[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

Utilisez un alias de nom d'hôte similaire pour l'adresse frontale kube-api.

Remarques :

Votre cluster Kubernetes principal ne doit PAS utiliser d'adresses IP pour le système frontal kube-api. Vous devez utiliser un nom d'hôte pour que ce système frontal puisse recevoir un alias dans le système secondaire. Pour obtenir un exemple d'ajout d'un alias de nom d'hôte à votre système kube-api principal existant, reportez-vous au script maak8s-kube-api-alias.sh.
Par exemple, si la résolution d'adresse kube-api du serveur principal est la suivante :
```
[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
```
Ensuite, kube-api du secondaire doit utiliser le même nom d'hôte (vous pouvez le mettre en correspondance avec une autre adresse IP) :
```
[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
```
Pour ce faire, vous pouvez utiliser des hôtes virtuels, une résolution /etc/hosts locale ou des serveurs DNS différents à chaque emplacement. Pour déterminer la méthode de résolution de nom d'hôte utilisée par un hôte particulier, recherchez la valeur du paramètre hosts dans le fichier /etc/nsswitch.conf sur l'hôte.
- Si vous voulez résoudre les noms d'hôte localement sur l'hôte, faites de l'entrée de fichiers la première entrée du paramètre hosts. Lorsque files est la première entrée du paramètre hosts, les entrées du fichier d'hôte /etc/hosts sont utilisées en premier pour résoudre les noms d'hôte.
  
  Spécification de l'utilisation de la résolution de nom d'hôte local dans le fichier /etc/nsswitch.conf :
```
hosts: files dns nis
```
- Si vous voulez résoudre des noms d'hôte à l'aide de DNS sur l'hôte, définissez l'entrée dns comme première entrée pour le paramètre hosts. Lorsque dns est la première entrée du paramètre hosts, les entrées de serveur DNS sont utilisées en premier pour résoudre les noms d'hôte.
  
  Spécification de l'utilisation du fichier /etc/nsswitch.conf de résolution de nom d'hôte DNS :
```
hosts: dns files nis
```
Pour plus de simplicité et de cohérence, Oracle recommande que tous les hôtes d'un site (site de production ou site de secours) utilisent la même méthode de résolution de nom d'hôte (résolution locale de noms d'hôte ou résolution de noms d'hôte à l'aide de serveurs DNS distincts ou d'un serveur DNS global).

La technique d'"alias de nom d'hôte" est utilisée depuis de nombreuses années dans la protection contre les catastrophes pour les systèmes Middleware. Vous trouverez des détails et des exemples dans la documentation d'Oracle, notamment le Guide de récupération après sinistre d'Oracle Fusion Middleware et d'autres documents relatifs à Oracle Cloud Disaster Protection, tels qu'Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery et SOA Suite sur Oracle Cloud Infrastructure Marketplace Disaster Recovery.
Créez le cluster secondaire en utilisant le même nom d'hôte pour l'équilibreur de charge kube-api frontal que pour l'équilibreur de charge principal.
Effectuez cette étape une fois la résolution de nom d'hôte prête. Reportez-vous à la documentation de l'outil kubeadm de Kubernetes. Utilisez les mêmes versions kubeadm et Kubernetes que dans la version principale. Les exécutions de conteneur peuvent différer, mais vous devez utiliser les mêmes versions de l'infrastructure Kubernetes dans les deux régions.
Par exemple, si le cluster principal a été créé avec les éléments suivants :
```
kubeadm init --control-plane-endpoint $LBR_HN:$LBR_PORT --pod-network-cidr=10.244.0.0/16 --node-name $mnode1 --upload-certs  --v=9
```
Utilisez ensuite les mêmes valeurs $LBR_HN:$LBR_PORT et CIDR dans le secondaire que dans le primaire. Il en va de même si vous utilisez d'autres outils de création de cluster, tels que kOps et kubesparay.
Lorsque vous ajoutez des noeuds de processus actif ou de plan de contrôle supplémentaires, veillez à utiliser les mêmes noms de noeud dans les noeuds principal et secondaire.
```
kubeadm join $LBR_HN:$LBR_PORT --token $token --node-name $host --discovery-token-ca-cert-hash $token_ca  --control-plane --certificate-key $cp_ca
```

Une fois le cluster secondaire configuré, les mêmes noms d'hôte doivent apparaître lors de l'extraction des informations de noeud à partir de kubernetes.

Les variables $host utilisées dans le secondaire pour chaque plan de contrôle et les noeuds de processus actif doivent être identiques à celles utilisées dans le principal.

Cluster principal

Exécutez la commande suivante sur la base principale pour confirmer le statut du plan de contrôle et du noeud de processus actif, le rôle, l'âge, la version, l'adresse IP interne, l'adresse IP externe, l'image du système d'exploitation, la version du noyau et l'exécution du conteneur :

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

L'exemple suivant illustre la sortie de la commande.

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

Exécutez la commande suivante sur l'instance principale pour identifier l'emplacement d'exécution du plan de contrôle Kubernetes et du DNS de base.

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

Cluster secondaire

Exécutez la commande suivante sur le serveur secondaire pour confirmer le statut du plan de contrôle et du noeud de processus actif, le rôle, l'âge, la version, l'adresse IP interne, l'adresse IP externe, l'image du système d'exploitation, la version du noyau et l'exécution du conteneur :

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

L'exemple suivant illustre la sortie de la commande.

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

Exécutez la commande suivante sur le serveur secondaire pour identifier l'emplacement d'exécution du plan de contrôle Kubernetes et du DNS principal.

[opc@k8dramsnewbastion ~]$ kubectl cluster-info

Avec les paramètres par défaut dans la création du cluster kubeadm, etcd utilisera les mêmes ports dans les ports principal et secondaire. Si le cluster du secondaire doit utiliser des ports différents, vous devez modifier les scripts pour le gérer. Vous pouvez utiliser différents emplacements de stockage dans la base de données principale et secondaire pour la base de données etcds. Les scripts se chargent de la restauration à l'emplacement approprié que le cluster secondaire utilise pour etcd.

Installez etcdctl à la fois dans les emplacements principal et secondaire (noeuds exécutant les scripts de sauvegarde et de restauration).
Les scripts de sauvegarde et de restauration utiliseront etcdctl pour obtenir des informations à partir du cluster et pour créer et appliquer des clichés etcd. Pour installer etcdctl, reportez-vous à la documentation https://github.com/etcd-io/etcd/releases.
Assurez-vous que le pare-feu et les règles de sécurité appropriés sont en place afin que le noeud exécutant les opérations de sauvegarde et de restauration soit activé pour ce type d'accès.
Les scripts devront également accéder au cluster avec kubectl et atteindre les différents noeuds via SSH et HTTP (pour les commandes shell et les opérations etcdctl).

Configurer

Configuration pour la récupération après sinistre.

Les étapes d'une restauration sont les suivantes :

Effectuez une sauvegarde etcd à un emplacement principal.
Expédiez la sauvegarde à l'emplacement secondaire.
Restaurez cette sauvegarde etcd dans un cluster secondaire.

Procédez comme suit :

Créez une sauvegarde etcd dans un cluster Kubernetes principal.
1. Téléchargez TOUS les scripts de récupération après sinistre d'instantané etcd à partir de la section "Télécharger le code" de ce document.
  
  Remarques :
  Tous les scripts doivent se trouver dans le même chemin car les scripts principaux utilisent d'autres scripts auxiliaires.
2. Obtenez le fichier advert_port à partir d'une configuration de noeud de plan de contrôle etcd.
```
[opc@olk8-m1 ~]$ sudo grep etcd.advertise-client-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}'

2379
```
  De même pour init_port :
```
[opc@olk8-m1 ~]$  sudo grep initial-advertise-peer-urls  /etc/kubernetes/manifests/etcd.yaml  | awk -F ":" '{print $NF}'

2380
```
  Ces ports sont les ports par défaut et sont utilisés par tous les pods etcd du plan de contrôle. Dans les rares cas où etcd a été personnalisé pour utiliser un port init et advertise différent dans chaque noeud, vous devez personnaliser les scripts pour les prendre en compte. Vous pouvez également personnaliser la valeur de infra_pod_list si d'autres modules d'extension réseau sont utilisés ou si d'autres pods ou déploiements pertinents doivent être redémarrés après la restauration dans votre cas particulier. Cependant, en général, il peut être défini par défaut sur les valeurs fournies dans le fichier.
3. Modifiez le script maak8s.env et mettez à jour les variables en fonction de votre environnement.
  Voici un exemple de fichier 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. Exécutez le script maak8-etcd-backup.sh et fournissez en tant qu'arguments les champs suivants dans cet ordre :
  - Répertoire dans lequel la sauvegarde sera stockée
  - Un "ETIQUETTE/TEXTE" décrivant la sauvegarde
  - Emplacement de la configuration de cluster pour exécuter les opérations kubectl
  Exemple :
```
[opc@olk8-m1 ~]$  ./maak8-etcd-backup.sh  /backup-volumes/ "ETCD Snapshot after first configuration " /home/opc/.kubenew/config
```
Le script effectue les tâches suivantes :
- Crée un cliché etcd à partir du noeud maître etcd
- Crée une copie de la configuration actuelle de chaque noeud de plan de contrôle (manifestes et certificats pour chaque noeud de plan de contrôle), y compris les clés de signature pour le cluster
- Enregistre la liste des noeuds, des pods, des services et de la configuration du cluster
- Stocke toutes les informations ci-dessus dans un répertoire libellé avec la date. Si le répertoire indiqué dans l'argument de ligne de commande est /backup-volume, la sauvegarde est stockée sous /backup-volume/etcd_snapshot_date de la sauvegarde. Par exemple, /backup-volume/etcd_snapshot_2022-08-29_15-56-59.
Copiez l'intégralité du répertoire (/backup-volume/etcd_snapshot_date) vers le cluster secondaire.
1. Utilisez un outil sftp ou créez un fichier tar avec le répertoire et envoyez-le à l'emplacement secondaire.
2. Décompressez ou décompressez le fichier pour le rendre disponible dans le système secondaire, comme il l'était dans le système principal.
3. Notez le libellé de date dans la sauvegarde (dans l'exemple ci-dessus, il s'agirait du 2022-08-29_15-56-59).
Exemple :
```
[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
```

Une fois la sauvegarde disponible à l'emplacement secondaire, procédez comme suit pour la restaurer :

Téléchargez TOUS les scripts de récupération après sinistre de cliché etcd de la section Télécharger le code vers le noeud de région secondaire qui exécutera la restauration.
N'oubliez pas que etcdctl doit également être installé sur ce noeud et que kubectl doit avoir accès au cluster secondaire.

Remarques :
Etant donné que les scripts principaux utilisent d'autres scripts auxiliaires, vous devez avoir tous les scripts dans le même chemin lors de l'exécution des différentes étapes.

Modifiez le script maak8s.env et mettez à jour les variables en fonction de votre environnement.

Vous pouvez modifier l'utilisateur, la clé SSH et l'emplacement etcdctl en fonction de vos noeuds secondaires, mais les ports advert et init doivent être identiques à ceux utilisés dans le noeud principal.

Voici un exemple de fichier 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"

Exécutez la restauration à l'aide du script maak8-etcd-restore.sh. Indiquez, en tant qu'arguments, le répertoire racine dans lequel la sauvegarde a été copiée de la base de données principale vers la base de données de secours, l'horodatage de la sauvegarde et l'emplacement de la configuration kubectl pour le cluster.

Exemple :

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

Le script recherche dans le répertoire /restore-volume un sous-répertoire nommé etcd_snapshot_date. Dans cet exemple, il utilisera /restore-volume/etcd_snapshot_2022-08-29_15-56-59.

La restauration effectue les tâches suivantes :

Forcer l'arrêt du plan de contrôle dans le secondaire, s'il est en cours d'exécution
Restaure l'instantané etcd dans tous les noeuds de plan de contrôle
Remplace les clés de signature du cluster dans tous les noeuds du plan de contrôle.
Démarre le plan de contrôle
Recycle tous les pods d'infrastructure (proxy, planificateur, contrôleurs) et les déploiements dans le cluster (pour le mettre à un état cohérent)

A la fin de la restauration, un rapport affiche le statut des pods et du sous-système etcd. Exemple :

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

Vérifier

Après avoir exécuté le script maak8DR-apply.sh, vérifiez que tous les artefacts qui existaient dans le cluster principal ont été répliqués vers le cluster secondaire. Examinez le cluster secondaire et vérifiez que les pods du site secondaire sont en cours d'exécution sans erreur.

Vérifiez le statut du pod secondaire jusqu'à ce que les pods requis correspondent à celui du pod principal.
Par défaut, les pods et les déploiements sont démarrés dans la région secondaire. A la fin de la restauration, le statut du cluster secondaire est affiché. Certains pods peuvent prendre plus de temps pour atteindre l'état RUNNING.
Recherchez les éventuelles erreurs dans le journal restore dans le secondaire.
L'emplacement du journal est signalé au début de la restauration. Par défaut, le journal est créé dans le répertoire où se trouvait la sauvegarde elle-même, à l'emplacement /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/restore.log. Un autre journal est créé spécifiquement pour l'opération de restauration de cliché etcd /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log.
(Facultatif) Revenez en arrière.

Outre les journaux de restauration, une sauvegarde de la configuration /etc/kubernetes précédente est créée pour chacun des noeuds de plan de contrôle sous le répertoire /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/current_etc_kubernetes. De même, les bases de données etcd de chaque noeud AVANT la restauration sont copiées dans /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_name. Vous pouvez les utiliser pour rétablir la configuration du cluster qui existait avant l'exécution de la restauration.