1. Restauration des grappes Kubernetes en fonction d'instantanés etcd
  2. Configurer pour la récupération après sinistre

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

Vous pouvez utiliser les procédures et les scripts fournis avec ce livre de jeu de solutions pour créer un instantané etcd dans une grappe Kubernetes principale et le restaurer dans une autre grappe Kubernetes (secondaire) ou dans la grappe source elle-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é.

Note :

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

Planifier la configuration

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

Note :

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

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

Répondez aux exigences suivantes pour Restore lors de la planification de votre configuration :

  1. Vérifiez que les noeuds de travail et les ressources requis dans l'instance principale sont disponibles dans l'instance 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.
  2. Configurez la résolution de votre nom d'hôte de sorte que les noms d'hôte utilisés par le plan de contrôle et le plan de travail soient valides dans le secondaire.

    Par exemple, si votre site principal résout le cluster comme suit :

    [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
    Ensuite, votre site secondaire doit utiliser les mêmes noms de noeud. Dans l'exemple de noeud précédent dans le plan de contrôle, le nom d'hôte de la région 2 sera le même mappé à 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 dans secondaire (après avoir utilisé kubeadm pour créer la grappe et ajouter les noeuds de travail) utilisera exactement les mêmes noms de noeud, même si les adresses IP internes et d'autres valeurs diffèrent.
    [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. Utilisez un alias de nom d'hôte similaire pour l'adresse frontale kube-api.

    Note :

    Votre grappe Kubernetes principale ne doit PAS utiliser d'adresses IP pour le serveur frontal kube-api. Vous devez utiliser un nom d'hôte pour que ce serveur frontal puisse être aliasé dans le système secondaire. Voir le script maak8s-kube-api-alias.sh pour obtenir un exemple sur l'ajout d'un alias de nom d'hôte à votre système kube-api principal existant.

    Par exemple, si la résolution de l'adresse kube-api de l'instance principale 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 mapper à 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 dans chaque emplacement. Pour déterminer la méthode de résolution du nom d'hôte utilisée par un hôte particulier, recherchez la valeur du paramètre d'hôte 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 pour le paramètre hosts. Lorsque files est la première entrée pour le paramètre hôtes, les entrées du fichier /etc/hosts de l'hôte sont utilisées en premier pour résoudre les noms d'hôte.

      Spécification de l'utilisation de la résolution du nom d'hôte local dans le fichier /etc/nsswitch.conf : 

      hosts: files dns nis

    • Si vous voulez résoudre les noms d'hôte à l'aide du DNS sur l'hôte, faites de l'entrée dns la première entrée pour le paramètre d'hôte. Lorsque dns est la première entrée pour le 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 des noms d'hôte localement ou résolution des 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 sur la récupération après sinistre d'Oracle Fusion Middleware et d'autres documents relatifs à la protection contre les catastrophes d'Oracle Cloud, tels que Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery et SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  4. Créez la grappe secondaire à l'aide du même nom d'hôte pour l'équilibreur de charge kube-api frontal que pour l'équilibreur principal.
    Effectuez cette étape une fois que la résolution de votre nom d'hôte est prête. Consultez la documentation sur l'outil kubeadm de Kubernetes. Utilisez les mêmes versions de kubeadm et de 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 la grappe principale a été créée 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 exactement 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 grappe, tels que kOps et kubesparay.

  5. Lors de l'ajout de plans de contrôle ou de noeuds de travail supplémentaires, assurez-vous d'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
  6. Une fois la grappe secondaire configurée, les mêmes noms d'hôte doivent apparaître lors de l'extraction des informations de noeud de kubernetes.

    Les variables $host utilisées en tant que variables secondaires pour chaque plan de contrôle et chaque noeud de travail doivent être les mêmes que celles utilisées en tant que variables principales.

    Grappe principale

    Exécutez la commande suivante sur l'instance principale pour confirmer le statut, le rôle, l'ancienneté, la version, l'adresse IP interne, l'adresse IP externe, l'image de système d'exploitation, la version du noyau et l'exécution du conteneur :
    [opc@olk8-m1 ~]$ kubectl get nodes -o wide
    Voici un exemple de sortie.
    [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

    Grappe secondaire

    Exécutez la commande suivante sur un noeud secondaire pour confirmer le statut, le rôle, l'âge, la version, l'adresse IP interne, l'adresse IP externe, l'image de système d'exploitation, la version du noyau et l'exécution du conteneur :
    [opc@k8dramsnewbastion ~]$ kubectl get node -o wide
    Voici un exemple de sortie.
    [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 une base secondaire pour identifier l'emplacement d'exécution du plan de contrôle Kubernetes et du DNS de base. 
    [opc@k8dramsnewbastion ~]$ kubectl cluster-info

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

  7. Installez etcdctl aux 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 de la grappe et pour créer et appliquer des instantanés etcd. Pour installer etcdctl, consultez la documentation sur https://github.com/etcd-io/etcd/releases.
  8. 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 à la grappe à l'aide de kubectl et atteindre les différents noeuds au moyen de SSH et HTTP (pour les commandes d'interpréteur de commandes et les opérations etcdctl).

Configurer

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

Les étapes d'une restauration sont les suivantes :

  1. Effectuez une sauvegarde etcd dans un emplacement principal.
  2. Expédier la sauvegarde à l'emplacement secondaire.
  3. Restaurez cette sauvegarde etcd dans une grappe secondaire.

Effectuez les étapes suivantes :

  1. Créez une sauvegarde etcd dans une grappe Kubernetes principale.
    1. Téléchargez TOUS les scripts pour la reprise après sinistre de l'instantané etcd à partir de la section "Code de téléchargement" de ce document.

      Note :

      Tous les scripts doivent être dans le même chemin car les scripts principaux utilisent d'autres scripts auxiliaires.
    2. Obtenez advert_port à partir d'une configuration etcd du noeud de plan de contrôle.
      [opc@olk8-m1 ~]$ sudo grep etcd.advertise-client-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}'

2379
      Il en va 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 ceux 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 en tenir compte. Vous pouvez également personnaliser la valeur de infra_pod_list si d'autres plugiciels de 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 attribué par défaut aux 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 indiquez les champs suivants dans l'ordre :
      • Répertoire dans lequel la sauvegarde sera stockée
      • Un "ÉTIQUETTE/TEXT" décrivant la sauvegarde
      • Emplacement de la configuration de grappe pour exécuter les opérations kubectl
      Par 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 instantané etcd à partir du noeud principal etcd
    • Crée une copie de la configuration courante de chaque noeud de plan de contrôle (manifestations et certificats pour chaque noeud de plan de contrôle), y compris les clés de signature du cluster
    • Enregistre la liste des noeuds, pods, services et configuration de grappe
    • Stocke toutes les informations ci-dessus dans un répertoire étiqueté avec la date. Si le répertoire spécifié 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.
  2. Copiez le répertoire entier (/backup-volume/etcd_snapshot_date) dans la grappe 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 c'était le cas dans le système principal.
    3. Notez l'étiquette de date dans la sauvegarde (dans l'exemple ci-dessus, il s'agit de 2022-08-29_15-56-59).
    Par 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
  3. Une fois la sauvegarde disponible dans l'emplacement secondaire, procédez comme suit pour la restaurer :
    1. Téléchargez TOUS les scripts pour la reprise après sinistre de l'instantané etcd à partir de la section "Télécharger le code" vers le noeud de région secondaire qui exécutera la restauration.
      N'oubliez pas que ce noeud doit également disposer de l'accès etcdctl et kubectl à la grappe secondaire.

      Note :

      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.
    2. 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 les mêmes que ceux utilisés dans l'emplacement 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"
    3. Exécutez la restauration à l'aide du script maak8-etcd-restore.sh. Indiquez, en tant qu'arguments, le répertoire racine où la sauvegarde a été copiée de la base principale vers la base de données de secours, l'horodatage de la sauvegarde et l'emplacement de la configuration kubectl pour la grappe.
      Par 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 l'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 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 de grappe dans tous les noeuds de plan de contrôle
      • Démarre le plan de contrôle
      • Recycle tous les pods d'infrastructure (mandataire, programmateur, contrôleurs) et les déploiements dans la grappe (pour les rendre cohérents)

      À la fin de la restauration, un rapport affiche le statut des pods et du sous-système etcd. Par 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 la grappe principale ont été répliqués vers la grappe secondaire. Examinez la grappe secondaire et vérifiez que les pods du site secondaire s'exécutent sans erreur.
  1. Vérifiez le statut du module secondaire jusqu'à ce que les modules de réseautage requis correspondent à l'état du module principal.
    Par défaut, les pods et les déploiements sont démarrés dans la région secondaire. À la fin de la restauration, le statut du cluster secondaire est affiché. Certains pods peuvent prendre plus de temps pour atteindre l'état RUNNING.
  2. Vérifiez dans le journal restore secondaire les erreurs possibles.
    L'emplacement du journal est indiqué au début de la restauration. Par défaut, le journal est créé sous le répertoire où se trouvait la sauvegarde elle-même, à l'adresse /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 d'instantané etcd /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log.
  3. (Facultatif) Revenez en arrière.

    En plus des 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 de grappe qui existait avant l'exécution de la restauration.