1. Restauración de clusters de Kubernetes basada en instantáneas etcd
  2. Configuración para la recuperación ante desastres

Configuración para la recuperación ante desastres

Puede utilizar los procedimientos y scripts proporcionados con este manual de soluciones para crear una instantánea de etcd en un cluster de Kubernetes principal y restaurarlo en otro cluster de Kubernetes (secundario) o en el propio cluster de origen. Es importante planificar la configuración y comprender los requisitos antes de descargar y utilizar los scripts para configurar la instantánea.

Nota:

Esta solución asume que ya existen ambos clusters de Kubernetes, incluidos el plano de control y los nodos de trabajador.

Planificación de la Configuración

Planifique los recursos y la configuración en el sistema secundario según el sistema principal.

Nota:

Esta solución asume que ya existen ambos clusters de Kubernetes, incluidos el plano de control y los nodos de trabajador. Las recomendaciones y utilidades que se proporcionan en este manual no comprueban la capacidad ni la configuración de los recursos, el plano de control o los nodos de trabajador.

La restauración, como se describe aquí, se puede aplicar en clusters que son "reflejados" principales (el mismo número de nodos de plano de control, el mismo número de nodos de trabajador). Los procedimientos suponen que existe un cluster de Kubernetes principal creado con kubeadm. Los nombres de host del sistema secundario se configuran para imitar el principal, como se describe en los siguientes párrafos. A continuación, el cluster secundario se crea también con kubeadm (de nuevo solo DESPUÉS de que se realice la resolución de nombre de host necesaria).

Complete los siguientes requisitos para Restore al planificar la configuración:

  1. Confirme que los nodos de trabajador y los recursos necesarios del principal estén disponibles en el secundario.
    Esto incluye montajes de almacenamiento compartido, equilibradores de carga y bases de datos que utilizan los pods y sistemas utilizados en los espacios de nombres que se restaurarán.
  2. Configure la resolución de nombre de host para que los nombres de host utilizados por el plano de control y trabajador sean válidos en el secundario.

    Por ejemplo, si el sitio principal resuelve el cluster de forma similar a la siguiente:

    [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
    A continuación, el sitio secundario debe utilizar los mismos nombres de nodo. En el nodo de ejemplo anterior en el plano de control, el nombre de host en la región 2 será el mismo asignado a una IP diferente.
    [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 configuración resultante en secundaria (después de utilizar kubeadm para crear el cluster y agregar los nodos de trabajador) utilizará exactamente los mismos nombres de nodo, incluso si las IP internas y otros valores se retrasan.
    [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. Utilice un "alias de nombre de host" similar para la dirección de front-end kube-api.

    Nota:

    El cluster de kubernetes principal NO debe utilizar IP para el front-end kube-api. Debe utilizar un nombre de host para que este front-end pueda tener un alias en el sistema secundario. Consulte la secuencia de comandos maak8s-kube-api-alias.sh para obtener un ejemplo sobre cómo agregar un alias de nombre de host al sistema kube-api principal existente.

    Por ejemplo, si la resolución de la dirección kube-api del principal es la siguiente: 
    [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
    A continuación, kube-api del secundario debe utilizar el mismo nombre de host (puede asignarlo a una IP diferente): 
    [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
    Para ello, utilice hosts virtuales, resolución /etc/hosts local o servidores DNS diferentes en cada ubicación. Para determinar el método de resolución de nombres de host utilizado por un host concreto, busque el valor del parámetro hosts en el archivo /etc/nsswitch.conf del host.

    • Si desea resolver los nombres de host localmente en el host, convierta la entrada de archivos en la primera entrada para el parámetro hosts. Cuando files es la primera entrada para el parámetro hosts, las entradas del archivo host /etc/hosts se utilizan primero para resolver los nombres de host.

      Especificación del uso de la resolución de nombre de host local en el archivo /etc/nsswitch.conf: 

      hosts: files dns nis

    • Si desea resolver nombres de host mediante DNS en el host, convierta la entrada dns en la primera entrada para el parámetro de hosts. Cuando dns es la primera entrada para el parámetro hosts, las entradas del servidor DNS se utilizan primero para resolver los nombres de host.

      Especificación del archivo /etc/nsswitch.conf de resolución de nombre de host DNS: 

      hosts: dns files nis

    Para mayor simplicidad y coherencia, Oracle recomienda que todos los hosts de un sitio (sitio de producción o en espera) utilicen el mismo método de resolución de nombres de host (resolver nombres de host localmente o resolver nombres de host mediante servidores DNS independientes o un servidor DNS global).

    La técnica de "alias de nombre de host" se ha utilizado durante muchos años en sistemas de protección ante desastres para middleware. Puede encontrar detalles y ejemplos en la documentación de Oracle, incluida la Guía de recuperación ante desastres de Oracle Fusion Middleware y otros documentos relativos a la protección ante desastres de Oracle Cloud, como Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery y SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  4. Cree el cluster secundario con el mismo nombre de host para el equilibrador de carga front-end kube-api que en el principal.
    Realice este paso después de que la resolución del nombre de host esté lista. Consulte la documentación de la herramienta kubeadm de Kubernetes. Utilice las mismas versiones de kubeadm y Kubernetes que en la primaria. Los tiempos de ejecución del contenedor pueden diferir, pero debe utilizar las mismas versiones de la infraestructura de Kubernetes en ambas regiones.
    Por ejemplo, si el cluster primario se creó con lo siguiente:
    kubeadm init --control-plane-endpoint $LBR_HN:$LBR_PORT --pod-network-cidr=10.244.0.0/16 --node-name $mnode1 --upload-certs  --v=9

    A continuación, utilice exactamente los mismos valores $LBR_HN:$LBR_PORT y CIDR en el secundario que en el principal. Lo mismo se aplica si utiliza otras herramientas de creación de clusters, como kOps y kubesparay.

  5. Al agregar nodos de trabajador o plano de control adicionales, asegúrese de utilizar los mismos nombres de nodo en los nodos principal y secundario.
    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. Una vez configurado el cluster secundario, deben aparecer los mismos nombres de host al recuperar la información del nodo de kubernetes.

    Las variables $host utilizadas en el secundario para cada plano de control y nodos de trabajador deben ser las mismas que las utilizadas en el principal.

    Cluster primario

    Ejecute el siguiente comando en la base de datos primaria para confirmar el estado del nodo de trabajo y el plano de control, el rol, la antigüedad, la versión, la IP interna, la IP externa, la imagen del sistema operativo, la versión del núcleo y el tiempo de ejecución del contenedor:
    [opc@olk8-m1 ~]$ kubectl get nodes -o wide
    La siguiente es una salida de ejemplo.
    [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 ~]$
    Ejecute el siguiente comando en la base de datos primaria para identificar dónde se están ejecutando el plano de control de Kubernetes y el DNS principal. 
    [opc@olk8-m1 ~]$ kubectl cluster-info

    Cluster secundario

    Ejecute el siguiente comando en el secundario para confirmar el estado, el rol, la antigüedad, la versión, la IP interna, la IP externa, la imagen del sistema operativo, la versión del núcleo y el tiempo de ejecución del contenedor del plano de control y del nodo de trabajo:
    [opc@k8dramsnewbastion ~]$ kubectl get node -o wide
    La siguiente es una salida de ejemplo.
    [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 ~]$
    Ejecute el siguiente comando en el secundario para identificar dónde se están ejecutando el plano de control de Kubernetes y el DNS principal. 
    [opc@k8dramsnewbastion ~]$ kubectl cluster-info

    Con la configuración por defecto en la creación del cluster kubeadm, etcd utilizará los mismos puertos en el primario y el secundario. Si el cluster secundario necesita utilizar puertos diferentes, debe modificar los scripts para manejarlo. Puede utilizar diferentes ubicaciones de almacenamiento en la base de datos primaria y secundaria para la base de datos etcds. Los scripts se encargarán de la restauración en la ubicación adecuada que esté utilizando el cluster secundario para etcd.

  7. Instale etcdctl tanto en la ubicación primaria como en la secundaria (nodos que ejecutan las secuencias de comandos de copia de seguridad y restauración).
    Los scripts para la copia de seguridad y restauración utilizarán etcdctl para obtener información del cluster y para crear y aplicar instantáneas etcd. Para instalar etcdctl, consulte la documentación de https://github.com/etcd-io/etcd/releases.
  8. Asegúrese de que se aplican las reglas de seguridad y firewall adecuadas para que el nodo que ejecuta las operaciones de copia de seguridad y restauración esté activado para este tipo de acceso.
    Los scripts también deberán acceder al cluster con kubectl y a los distintos nodos a través de SSH y HTTP (para comandos de shell y operaciones etcdctl).

Configuración

Configurar para la recuperación de fallos.

Los pasos para una restauración implican lo siguiente:

  1. Realice una copia de seguridad etcd en una ubicación primaria.
  2. Envíe la copia de seguridad a la ubicación secundaria.
  3. Restaure esa copia de seguridad etcd en un cluster secundario.

Realice los siguientes pasos:

  1. Cree una copia de seguridad etcd en un cluster de Kubernetes principal.
    1. Descargue TODOS los scripts de DR de instantánea etcd de la sección "Código de descarga" de este documento.

      Nota:

      Todos los scripts deben estar en la misma ruta porque los scripts principales utilizan otros scripts auxiliares.
    2. Obtenga advert_port de una configuración de nodo de plano de control etcd.
      [opc@olk8-m1 ~]$ sudo grep etcd.advertise-client-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}'

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

2380

      Estos puertos son los predeterminados y son utilizados por todos los pods etcd del plano de control. En las raras situaciones en las que etcd se ha personalizado para utilizar un puerto init y advertise diferente en cada nodo, debe personalizar los scripts para considerarlos. También puede personalizar el valor de infra_pod_list si se utilizan otros plugins de red u otros pods o despliegues relevantes se deben reiniciar después de la restauración en su caso concreto. Sin embargo, en general, se puede establecer por defecto en los valores proporcionados en el archivo.

    3. Edite el script maak8s.env y actualice las variables según el entorno.
      A continuación, se muestra un ejemplo de archivo 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. Ejecute el script maak8-etcd-backup.sh y proporcione como argumentos los siguientes campos en este orden:
      • El directorio donde se almacenará la copia de seguridad
      • Un "LABEL/TEXT" que describe la copia de seguridad
      • Ubicación de la configuración del cluster para ejecutar operaciones kubectl
      Por ejemplo:
      [opc@olk8-m1 ~]$  ./maak8-etcd-backup.sh  /backup-volumes/ "ETCD Snapshot after first configuration " /home/opc/.kubenew/config

    La secuencia de comandos realiza las siguientes tareas:

    • Crea una instantánea etcd desde el nodo maestro etcd
    • Crea una copia de la configuración actual de cada nodo de plano de control (manifiestos y certificados para cada nodo de plano de control), incluidas las claves de firma para el cluster.
    • Registra la lista de nodos, pods, servicios y configuración de cluster
    • Almacena toda la información anterior en un directorio con la fecha. Si el directorio especificado en el argumento de la línea de comandos es /backup-volume, la copia de seguridad se almacena en /backup-volume/etcd_snapshot_date de la copia de seguridad. Por ejemplo, /backup-volume/etcd_snapshot_2022-08-29_15-56-59.
  2. Copie todo el directorio (/backup-volume/etcd_snapshot_date) en el cluster secundario.
    1. Utilice una herramienta sftp o cree un archivo tar con el directorio y envíelo a la ubicación secundaria.
    2. Descomprima o descomprima el archivo para que esté disponible en el sistema secundario, como en el principal.
    3. Anote la etiqueta de fecha en la copia de seguridad (en el ejemplo anterior, sería 2022-08-29_15-56-59).
    Por ejemplo:
    [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. Una vez que la copia de seguridad esté disponible en la ubicación secundaria, siga estos pasos para restaurarla:
    1. Descargue TODOS los scripts para la DR de instantánea etcd de la sección "Código de descarga" al nodo de región secundaria que ejecutará la restauración.
      Recuerde que este nodo también debe tener instalado etcdctl y acceso kubectl al cluster secundario.

      Nota:

      Debido a que los scripts principales utilizan otros scripts auxiliares, debe tener todos los scripts en la misma ruta de acceso al ejecutar los distintos pasos.
    2. Edite el script maak8s.env y actualice las variables según el entorno.
      Puede modificar el usuario, la clave ssh y la ubicación etcdctl, según corresponda, a los nodos secundarios, pero los puertos advert y init deben ser los mismos que los que se utilizan en la base de datos primaria.
      A continuación, se muestra un ejemplo de archivo 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. Ejecute la restauración con el script maak8-etcd-restore.sh. Proporcione, como argumentos, el directorio raíz en el que se ha copiado la copia de seguridad de principal a en espera, el registro de hora de la copia de seguridad y la ubicación de la configuración kubectl para el cluster.
      Por ejemplo: 
      [opc@k8dramsnewbastion ~]$ ./maak8-etcd-restore.sh /restore-volume 2022-08-29_15-56-59 /home/opc/.kube/config

      El script busca en el directorio /restore-volume un subdirectorio denominado etcd_snapshot_date. Mediante el ejemplo, utilizará /restore-volume/etcd_snapshot_2022-08-29_15-56-59.

      La restauración realiza las siguientes tareas:
      • Forzar para el plano de control en secundario, si se está ejecutando
      • Restaura la instantánea etcd en todos los nodos de plano de control
      • Sustituye las claves de firma de cluster en todos los nodos de plano de control
      • Inicia el plano de control
      • Recicla todos los pods de infraestructura (proxy, programador, controladores) y despliegues en el cluster (para que tengan un estado consistente)

      Al final de la restauración, un informe muestra el estado de los pods y el subsistema etcd. Por ejemplo: 

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

Verificar

Después de ejecutar el script maak8DR-apply.sh, verifique que todos los artefactos que existían en el cluster primario se hayan replicado en el cluster secundario. Observe el cluster secundario y verifique que los pods del sitio secundario se están ejecutando sin errores.
  1. Compruebe el estado del secundario hasta que los pods necesarios coincidan con el estado del principal.
    Por defecto, los pods y los despliegues se inician en la región secundaria. Al final de la restauración, se muestra el estado del cluster secundario. Algunos pods pueden tardar más tiempo en alcanzar el estado RUNNING.
  2. Compruebe el log restore en el secundario para detectar posibles errores.
    La ubicación del log se informa al principio de la restauración. Por defecto, el log se crea en el directorio donde se encuentra la copia de seguridad, en /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/restore.log. Se crea otro log específicamente para la operación de restauración de instantánea etcd /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log.
  3. (Opcional) Reversión.

    Además de los logs de restauración, se crea una copia de seguridad de la configuración /etc/kubernetes anterior para cada uno de los nodos de planos de control en el directorio /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/current_etc_kubernetes. Del mismo modo, las bases de datos etcd de cada nodo ANTES de la restauración se copian en /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_name. Puede utilizarlos para volver a la configuración del cluster que existía antes de que se ejecutara la restauración.