1. Restauración de clusters de Kubernetes basada en instantáneas de etcd
  2. Configuración para Disaster Recovery

Configuración para Disaster Recovery

Puede utilizar los procedimientos y scripts proporcionados con este cuaderno de estrategias de solución para crear una instantánea 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.

Note:

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.

Note:

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 proporcionadas en este manual no comprueban la capacidad ni la configuración de los recursos, el plano de control ni el nodo de trabajador.

La restauración, como se describe aquí, se puede aplicar en clusters que "reflejan" el nodo principal (el mismo número de nodos de plano de control y 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 en el sistema secundario se configuran para imitar el principal, como se describe en los párrafos siguientes. A continuación, el cluster secundario se crea también con kubeadm (solo de nuevo DESPUÉS de que se tenga en cuenta 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 en el principal estén disponibles en el secundario.
    Esto incluye montajes de almacenamiento compartido, equilibradores de carga y bases de datos utilizados por 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 de trabajador sean válidos en 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 del plano de control, el nombre de host de 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 secundario (después de utilizar kubeadm para crear el cluster y agregar los nodos de trabajador) utilizará exactamente los mismos nombres de nodo, incluso si se difieren las IP internas y otros valores.
    [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 "aliasing de nombre de host" similar para la dirección de front-end kube-api.

    Note:

    El cluster de Kubernetes principal NO debe utilizar direcciones IP para el frontend kube-api. Debe utilizar un nombre de host para que este frontend 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 direcciones kube-api de la 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
    Puede lograrlo mediante hosts virtuales, resolución /etc/hosts local o un servidor DNS diferente 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 /etc/hosts del host 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 los nombres de host mediante el DNS en el host, convierta la entrada dns en la primera entrada para el parámetro 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 uso del archivo /etc/nsswitch.conf de resolución de nombres de host DNS: 

      hosts: dns files nis

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

    La técnica de "aliasing de nombre de host" se ha utilizado durante muchos años en los sistemas Disaster Protection for 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 relacionados con 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 kube-api de frontend 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 principal. Los tiempos de ejecución de 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 el nodo 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 el nodo principal para confirmar el estado del plano de control y del nodo de trabajador, el rol, la 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
    A continuación, se presenta un ejemplo de la salida.
    [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 principal 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 secundario para confirmar el estado del plano de control y del nodo de trabajador, el rol, la 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@k8dramsnewbastion ~]$ kubectl get node -o wide
    A continuación, se presenta un ejemplo de la salida.
    [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 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 principal y secundario. Si el cluster en el secundario necesita utilizar diferentes puertos, debe modificar las secuencias de comandos para manejarlo. Puede utilizar diferentes ubicaciones de almacenamiento en la base de datos etcds principal y secundaria. Los scripts se encargarán de restaurar en la ubicación adecuada que el cluster secundario está utilizando para etcd.

  7. Instale etcdctl en las ubicaciones principal y 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 de etcd. Para instalar etcdctl, consulte la documentación de https://github.com/etcd-io/etcd/releases.
  8. Asegúrese de que se han establecido 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 tendrán que acceder al cluster con kubectl y llegar a los diferentes nodos mediante SSH y HTTP (para comandos de shell y operaciones etcdctl).

Configurar

Configurar para recuperación ante desastres.

Los pasos para una restauración implican lo siguiente:

  1. Realice una copia de seguridad de etcd en una ubicación principal.
  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 para DR de instantánea etcd desde la sección "Descargar código" de este documento.

      Note:

      Todas las secuencias de comandos deben estar en la misma ruta porque las secuencias de comandos principales utilizan otras secuencias de comandos 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 se ha personalizado etcd para utilizar un puerto init y advertise diferente en cada nodo, debe personalizar los scripts para tenerlos en cuenta. 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 su entorno.
      A continuación, se muestra un archivo maak8s.env de ejemplo:
      [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:
      • Directorio en el que 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 las 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 etiquetado con la fecha. Si el directorio especificado en el argumento de 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 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 DR de instantánea etcd de la sección "Descargar código" al nodo de región secundario que ejecutará la restauración.
      Recuerde que este nodo también debe tener instalado etcdctl y acceso kubectl al cluster secundario.

      Note:

      Debido a que las secuencias de comandos principales utilizan otras secuencias de comandos auxiliares, debe tener todas las secuencias de comandos en la misma ruta al ejecutar los diferentes pasos.
    2. Edite el script maak8s.env y actualice las variables según su 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 el nodo principal.
      A continuación, se muestra un archivo maak8s.env de ejemplo:
      [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 mediante el script maak8-etcd-restore.sh. Proporcione, como argumentos, el directorio raíz en el que se copió la copia de seguridad de la base de datos principal a la base de datos 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

      La secuencia de comandos busca en el directorio /restore-volume un subdirectorio denominado etcd_snapshot_date. Con el ejemplo, utilizará /restore-volume/etcd_snapshot_2022-08-29_15-56-59.

      La restauración realiza las siguientes tareas:
      • La fuerza detiene el plano de control en secundario, si está en funcionamiento
      • Restaura la instantánea etcd en todos los nodos del 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 llevarlo a 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 principal 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 en el principal.
    Por defecto, los pods y 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. Consulte 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 encontraba 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) Devolución.

    Además de los logs de restauración, se crea una copia de seguridad de la configuración anterior de /etc/kubernetes 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 ejecutar la restauración.