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

Configurar para Recuperação de Desastre

Você pode usar os procedimentos e scripts fornecidos com este manual de soluções para criar um snapshot do 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 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 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 playbook não verificam recursos, plano de controle ou capacidade e configuração do nó de trabalho.

A restauração, conforme descrito aqui, pode ser aplicada em clusters que "espelho" principal (mesmo número de nós de plano de controle, mesmo número de nós de trabalho). Os procedimentos pressupõem que existe 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 é criado também com kubeadm (novamente apenas APÓS a resolução de nome de host obrigatória é 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 em 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 a resolução de nome de host para que os nomes de host usados pelo plano de controle e colaborador sejam válidos em secundário.

    Por exemplo, se o 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 outro IP.
    [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ária (depois de usar kubeadm para criar o cluster e adicionar os nós de trabalho) usará exatamente os mesmos nomes de nó, mesmo se os IPs internos e outros valores forem 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 "alias de nome de host" semelhante para o endereço front-end kube-api.

    Observação:

    Seu cluster de kubernetes principal NÃO deve usar IPs 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 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 secundário 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 conseguir isso usando hosts virtuais, resolução local /etc/hosts ou diferentes servidores DNS 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, faça com que a entrada de arquivos seja a primeira entrada para o 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 para o 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 de resolução de nome de host DNS: 

      hosts: dns files nis

    Para simplicidade e consistência, a Oracle recomenda que todos os hosts de um site (site de produção ou 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 "host name aliasing" tem sido usada há muitos anos na Proteção de Desastres para sistemas de 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 no Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  4. Crie o cluster secundário usando o mesmo nome de host para o balanceador de carga kube-api front-end como 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 kubeadm e Kubernetes como principal. Os tempos de execução do contêiner podem diferir, 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 como no principal. O mesmo se aplica se você usar outras ferramentas de criação de cluster, como kOps e kubesparay.

  5. Ao adicionar mais nós de plano de controle ou de trabalho, 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 é configurado, os mesmos nomes de host devem aparecer ao recuperar as informações do nó do kubernetes.

    As variáveis $host usadas em secundário para cada plano de controle e nós de trabalho devem ser iguais às usadas em principal.

    Cluster Principal

    Execute o seguinte comando em 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 SO, 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 seguinte comando em principal para identificar onde o plano de controle do Kubernetes e o DNS Básico estão em execução. 
    [opc@olk8-m1 ~]$ kubectl cluster-info

    Cluster Secundário

    Execute o seguinte comando em 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 SO, 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 em secundário para identificar onde o plano de controle do Kubernetes e o DNS Básico estão em execução. 
    [opc@k8dramsnewbastion ~]$ kubectl cluster-info

    Com as definições padrão na criação do cluster kubeadm, etcd usará as mesmas portas em principal e secundária. Se o cluster secundário precisar usar portas diferentes, modifique os scripts para tratá-lo. Você pode usar diferentes locais de armazenamento em 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 o etcdctl nos locais principal e secundário (nós que executam os scripts de backup e restauração).
    Os scripts de backup e restauração usarão etcdctl para obter informações do cluster e criar e aplicar snapshots etcd. Para instalar o etcdctl consulte a documentação https://github.com/etcd-io/etcd/releases.
  8. Certifique-se de que o firewall apropriado e as regras de segurança 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 descobrir os diferentes nós por meio de SSH e HTTP (para comandos shell e operações etcdctl).

Configurar

Configure 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 de DR do snapshot etcd na seção "Código de Download" 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ó de 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 portas padrão e são usadas por todos os pods etcd do plano de controle. Nas situações raras em que etcd foi personalizado para usar uma porta init e advertise diferente em cada nó, você deve personalizar os scripts para considerá-los. Você também pode personalizar o valor de infra_pod_list se outros plug-ins de rede forem usados ou outros pods ou implantações relevantes tiverem de 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 "LABEL/TEXT" descrevendo 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 em principal.
    3. Anote o rótulo de data no backup (no exemplo acima, ele 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 de DR do snapshot etcd da seção "Código de Download" para o nó da região secundária que executará a restauração.
      Lembre-se de que este nó também deve ter acesso etcdctl instalado e 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 as mesmas que as 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 standby, 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:
      • 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 levá-lo a 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 para o cluster secundário. Verifique o cluster secundário e verifique se os pods do site secundário estão em execução sem erro.
  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 atingir o estado de RUNNING.
  2. Verifique possíveis erros no log restore no secundário.
    A localização do log é reportada no início da restauração. Por padrão, o log é criado no diretório em que o próprio backup foi 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 de a restauração ser executada.