1. Restauração de clusters do Kubernetes com base em snapshots etcd
  2. Configurar para Recuperação de Desastres

Configurar para Recuperação de Desastres

Você pode usar os procedimentos e scripts fornecidos com este manual de soluções para criar um snapshot etcd em um cluster principal do Kubernetes e restaurá-lo em outro cluster (secundário) do Kubernetes ou no próprio cluster de origem. É importante planejar a configuração e entender os requisitos antes de fazer download e usar os scripts para configurar seu instantâneo.

Observação:

Essa solução pressupõe que ambos os clusters do Kubernetes, incluindo o plano de controle e os nós de trabalho, já existam.

Planejar a Configuração

Planeje os recursos e a configuração no sistema secundário com base no sistema principal.

Observação:

Essa solução pressupõe que ambos os clusters do Kubernetes, incluindo o plano de controle e os nós de trabalho, já existam. As recomendações e os utilitários fornecidos neste manual não verificam recursos, o plano de controle ou a capacidade e a configuração do nó de trabalho.

A restauração, conforme descrito aqui, pode ser aplicada em clusters que "espelho" primário (mesmo número de nós de plano de controle, mesmo número de nós de trabalho). Os procedimentos pressupõem que exista um cluster principal do Kubernetes criado com kubeadm. Os nomes de host no sistema secundário são configurados para imitar o principal, conforme descrito nos próximos parágrafos. Em seguida, o cluster secundário também é criado com kubeadm (novamente apenas APÓS a resolução do nome do host necessário ser tratada).

Preencha os seguintes requisitos para Restore ao planejar sua configuração:

  1. Confirme se os nós de trabalho e os recursos necessários no principal estão disponíveis no secundário.
    Isso inclui montagens de armazenamento compartilhado, balanceadores de carga e bancos de dados usados pelos pods e sistemas usados nos namespaces que serão restaurados.
  2. Configure sua resolução de nome de host para que os nomes de host usados pelo plano de controle e trabalhador sejam válidos em secundário.

    Por exemplo, se o seu site principal resolver o cluster semelhante ao seguinte:

    [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
    Em seguida, seu site secundário deve usar os mesmos nomes de nó. No nó de exemplo anterior no plano de controle, o nome do host na região 2 será o mesmo mapeado para um 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 ~]$
    A configuração resultante em secundário (depois de usar kubeadm para criar o cluster e adicionar os nós de trabalho) usará exatamente os mesmos nomes de nó, mesmo que IPs internos e outros valores sejam adiados.
    [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. Use um "aliasing de nome de host" semelhante para o endereço front-end kube-api.

    Observação:

    Seu cluster principal do Kubernetes NÃO deve usar endereços IP para o front-end kube-api. Você deve usar um nome de host para que esse front-end possa ter alias no sistema secundário. Consulte o script maak8s-kube-api-alias.sh para obter um exemplo de como adicionar um alias de nome de host ao sistema kube-api principal existente.

    Por exemplo, se a resolução de endereço kube-api do principal for a seguinte: 
    [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
    Em seguida, o kube-api da secundária deve usar o mesmo nome de host (você pode mapeá-lo para outro 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
    Você pode fazer isso usando hosts virtuais, resolução /etc/hosts local ou servidores DNS diferentes em cada local. Para determinar o método de resolução de nome de host usado por um host específico, procure o valor do parâmetro hosts no arquivo /etc/nsswitch.conf no host.

    • Se você quiser resolver nomes de host localmente no host, torne a entrada de arquivos a primeira entrada do parâmetro hosts. Quando files é a primeira entrada do parâmetro hosts, as entradas no arquivo /etc/hosts do host são usadas primeiro para resolver nomes de host.

      Especificando o Uso da Resolução de Nome de Host Local no arquivo /etc/nsswitch.conf: 

      hosts: files dns nis

    • Se você quiser resolver nomes de host usando DNS no host, torne a entrada dns a primeira entrada do parâmetro hosts. Quando dns é a primeira entrada do parâmetro hosts, as entradas do servidor DNS são usadas primeiro para resolver nomes de host.

      Especificando o uso do arquivo /etc/nsswitch.conf da resolução de nome de host DNS: 

      hosts: dns files nis

    Para simplificar e consistência, a Oracle recomenda que todos os hosts de um site (site de produção ou site stand-by) usem o mesmo método de resolução de nome de host (resolvendo nomes de host localmente ou resolvendo nomes de host usando servidores DNS separados ou um servidor DNS global).

    A técnica de "aliasing de nome de host" tem sido usada há muitos anos na Proteção de Desastres para sistemas Middleware. Você pode encontrar detalhes e exemplos na documentação da Oracle, incluindo o Oracle Fusion Middleware Disaster Recovery Guide e outros documentos pertencentes ao Oracle Cloud Disaster Protection, como Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery e SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  4. Crie o cluster secundário usando o mesmo nome de host para o balanceador de carga front-end kube-api que no principal.
    Execute esta etapa depois que a resolução do nome do host estiver pronta. Consulte a documentação da ferramenta kubeadm do Kubernetes. Use as mesmas versões do kubeadm e do Kubernetes que no principal. Os runtimes do contêiner podem adiar, mas você deve usar as mesmas versões da infraestrutura do Kubernetes em ambas as regiões.
    Por exemplo, se o cluster principal foi criado com o seguinte:
    kubeadm init --control-plane-endpoint $LBR_HN:$LBR_PORT --pod-network-cidr=10.244.0.0/16 --node-name $mnode1 --upload-certs  --v=9

    Em seguida, use exatamente os mesmos valores $LBR_HN:$LBR_PORT e CIDR em secundário que em principal. O mesmo se aplica se você usar outras ferramentas de criação de cluster, como kOps e kubesparay.

  5. Ao adicionar planos de controle ou nós de trabalho adicionais, certifique-se de usar os mesmos nomes de nó em principal e secundário.
    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. Depois que o cluster secundário for configurado, os mesmos nomes de host deverão aparecer ao recuperar as informações do nó do kubernetes.

    As variáveis $host usadas no secundário para cada plano de controle e nós de trabalho devem ser as mesmas usadas no principal.

    Cluster Principal

    Execute o seguinte comando na instância principal para confirmar o plano de controle e o status do nó de trabalho, a atribuição, a idade, a versão, o IP interno, o IP externo, a imagem do sistema operacional, a versão do kernel e o runtime do contêiner:
    [opc@olk8-m1 ~]$ kubectl get nodes -o wide
    Este é um exemplo de saída.
    [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 ~]$
    Execute o comando a seguir na instância principal para identificar onde o plano de controle do Kubernetes e o DNS Principal estão sendo executados. 
    [opc@olk8-m1 ~]$ kubectl cluster-info

    Cluster Secundário

    Execute o seguinte comando no secundário para confirmar o plano de controle e o status do nó de trabalho, a atribuição, a idade, a versão, o IP interno, o IP externo, a imagem do sistema operacional, a versão do kernel e o runtime do contêiner:
    [opc@k8dramsnewbastion ~]$ kubectl get node -o wide
    Este é um exemplo de saída.
    [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 ~]$
    Execute o comando a seguir no secundário para identificar onde o plano de controle do Kubernetes e o DNS Principal estão sendo executados. 
    [opc@k8dramsnewbastion ~]$ kubectl cluster-info

    Com as definições padrão na criação do cluster kubeadm, etcd usará as mesmas portas no principal e no secundário. Se o cluster secundário precisar usar portas diferentes, você deverá modificar os scripts para tratá-lo. Você pode usar diferentes locais de armazenamento no banco de dados principal e secundário para o banco de dados etcds. Os scripts cuidarão da restauração no local apropriado que o cluster secundário está usando para etcd.

  7. Instale etcdctl nos locais principal e secundário (nós executando os scripts de backup e restauração).
    Os scripts para backup e restauração usarão etcdctl para obter informações do cluster e para criar e aplicar snapshots etcd. Para instalar o etcdctl, consulte a documentação https://github.com/etcd-io/etcd/releases.
  8. Garanta que o firewall e as regras de segurança apropriados estejam em vigor para que o nó que executa as operações de backup e restauração esteja ativado para esse tipo de acesso.
    Os scripts também precisarão acessar o cluster com kubectl e acessar os diferentes nós por meio de SSH e HTTP (para comandos de shell e operações etcdctl).

Configurar

Configurar para recuperação de desastres.

As etapas para uma restauração envolvem o seguinte:

  1. Faça um backup etcd em um local principal.
  2. Envie o backup para o local secundário.
  3. Restaure esse backup etcd em um cluster secundário.

Faça o seguinte:

  1. Crie um backup etcd em um cluster principal do Kubernetes.
    1. Faça download de TODOS os scripts para DR do snapshot etcd na seção "Download de Código" deste documento.

      Observação:

      Todos os scripts devem estar no mesmo caminho porque os scripts principais usam outros scripts auxiliares.
    2. Obtenha o advert_port de uma configuração etcd do nó do plano de controle.
      [opc@olk8-m1 ~]$ sudo grep etcd.advertise-client-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}'

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

2380

      Essas portas são as padrão e são usadas por todos os pods etcd do plano de controle. Nas raras situações em que etcd foi personalizado para usar uma porta init e advertise diferentes em cada nó, você deve personalizar os scripts para considerá-los. Você também poderá personalizar o valor de infra_pod_list se outros plug-ins de rede forem usados ou outros pods ou implantações relevantes precisarem ser reiniciados após a restauração em seu caso específico. No entanto, em geral, ele pode ser padronizado para os valores fornecidos no arquivo.

    3. Edite o script maak8s.env e atualize as variáveis de acordo com seu ambiente.
      Veja a seguir um exemplo de arquivo 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. Execute o script maak8-etcd-backup.sh e forneça como argumentos os seguintes campos nesta ordem:
      • O diretório em que o backup será armazenado
      • Um "RÓTULO/TEXTO" que descreve o backup
      • O local da configuração do cluster para executar operações kubectl
      Por exemplo:
      [opc@olk8-m1 ~]$  ./maak8-etcd-backup.sh  /backup-volumes/ "ETCD Snapshot after first configuration " /home/opc/.kubenew/config

    O script realiza as seguintes tarefas:

    • Cria um snapshot etcd do nó mestre etcd
    • Cria uma cópia da configuração atual de cada nó do plano de controle (manifestos e certificações para cada nó do plano de controle), incluindo as chaves de assinatura do cluster
    • Registra a lista de nós, pods, serviços e configuração de cluster
    • Armazena todas as informações acima em um diretório rotulado com a data. Se o diretório especificado no argumento da linha de comando for /backup-volume, o backup será armazenado em /backup-volume/etcd_snapshot_date do backup. Por exemplo, /backup-volume/etcd_snapshot_2022-08-29_15-56-59.
  2. Copie o diretório inteiro (/backup-volume/etcd_snapshot_date) para o cluster secundário.
    1. Use uma ferramenta sftp ou crie um tar com o diretório e envie-o para o local secundário.
    2. Descompacte ou descompacte o arquivo para disponibilizá-lo no sistema secundário, como estava no principal.
    3. Anote o rótulo de data no backup (no exemplo acima, seria 2022-08-29_15-56-59).
    Por exemplo,
    [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. Depois que o backup estiver disponível no local secundário, siga estas etapas para restaurá-lo:
    1. Faça download de TODOS os scripts para DR do snapshot etcd da seção "Download de Código" para o nó da região secundária que executará a restauração.
      Lembre-se de que esse nó também deve ter etcdctl instalado e acesso kubectl ao cluster secundário.

      Observação:

      Como os scripts principais usam outros scripts auxiliares, você deve ter todos os scripts no mesmo caminho ao executar as diferentes etapas.
    2. Edite o script maak8s.env e atualize as variáveis de acordo com seu ambiente.
      Você pode alterar o usuário, a chave ssh e o local etcdctl, de acordo com seus nós secundários, mas as portas advert e init devem ser iguais às usadas no principal.
      Veja a seguir um exemplo de arquivo 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. Execute a restauração usando o script maak8-etcd-restore.sh. Forneça, como argumentos, o diretório raiz no qual o backup foi copiado do principal para o stand-by, o timestamp do backup e o local da configuração kubectl do cluster.
      Por exemplo, 
      [opc@k8dramsnewbastion ~]$ ./maak8-etcd-restore.sh /restore-volume 2022-08-29_15-56-59 /home/opc/.kube/config

      O script procura no diretório /restore-volume um subdiretório chamado etcd_snapshot_date. Usando o exemplo, ele usará /restore-volume/etcd_snapshot_2022-08-29_15-56-59.

      A restauração executa as seguintes tarefas:
      • A força para o plano de controle em secundário, se estiver em execução
      • Restaura o snapshot etcd em todos os nós do plano de controle
      • Substitui as chaves de assinatura do cluster em todos os nós do plano de controle
      • Inicia o plano de controle
      • Recicla todos os pods de infraestrutura (proxy, scheduler, controladores) e implantações no cluster (para trazê-lo para um estado consistente)

      No final da restauração, um relatório exibe o status dos pods e do subsistema etcd. Por exemplo, 

      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

Depois de executar o script maak8DR-apply.sh, verifique se todos os artefatos existentes no cluster principal foram replicados no cluster secundário. Examine o cluster secundário e verifique se os pods no site secundário estão em execução sem erros.
  1. Verifique o status do secundário até que os pods necessários correspondam ao estado no principal.
    Por padrão, os pods e as implantações são iniciados na região secundária. No final da restauração, o status do cluster secundário é mostrado. Alguns pods podem levar mais tempo para alcançar o estado RUNNING.
  2. Verifique o log restore na secundária quanto a possíveis erros.
    O local do log é reportado no início da restauração. Por padrão, o log é criado no diretório em que o próprio backup estava localizado, em /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/restore.log. Outro log é criado especificamente para a operação de restauração de snapshot etcd /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log.
  3. (Opcional) Reverter.

    Além dos logs de restauração, um backup da configuração /etc/kubernetes anterior é criado para cada um dos nós de planos de controle no diretório /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/current_etc_kubernetes. Da mesma forma, os bancos de dados etcd em cada nó ANTES da restauração são copiados para /backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_name. Você pode usá-los para reverter para a configuração do cluster que existia antes da restauração ser executada.