- Restauração de Clusters do Kubernetes com base em snapshots etcd
- Configurar para Recuperação de Desastre
Configurar para Recuperação de Desastre
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
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:
- 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.
- 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 usarkubeadm
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
- 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 sistemakube-api
principal existente.Por exemplo, se a resolução de endereçokube-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, okube-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
. Quandofiles
é 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. Quandodns
é a primeira entrada do parâmetrohosts
, 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.
-
- 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 ferramentakubeadm
do Kubernetes. Use as mesmas versõeskubeadm
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. - 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
- 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:Este é um exemplo de saída:[opc@olk8-m1 ~]$ kubectl get nodes -o wide
[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 dadosetcds
. Os scripts cuidarão da restauração no local apropriado que o cluster secundário está usando paraetcd
. - 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ãoetcdctl
para obter informações do cluster e criar e aplicar snapshotsetcd
. Para instalar oetcdctl
consulte a documentação https://github.com/etcd-io/etcd/releases. - 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:
- Faça um backup
etcd
em um local principal. - Envie o backup para o local secundário.
- Restaure esse backup
etcd
em um cluster secundário.
Faça o seguinte:
- Crie um backup
etcd
em um cluster principal do Kubernetes.- 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. - 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 oinit_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 queetcd
foi personalizado para usar uma portainit
eadvertise
diferente em cada nó, você deve personalizar os scripts para considerá-los. Você também pode personalizar o valor deinfra_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. - Edite o script
maak8s.env
e atualize as variáveis de acordo com seu ambiente.Veja a seguir um exemplo de arquivomaak8s.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"
- 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ó mestreetcd
- 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
.
- Faça download de TODOS os scripts de DR do snapshot
- Copie o diretório inteiro (
/backup-volume/etcd_snapshot_date
) para o cluster secundário.- Use uma ferramenta
sftp
ou crie um tar com o diretório e envie-o para o local secundário. - Descompacte ou descompacte o arquivo para disponibilizá-lo no sistema secundário, como em principal.
- 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
- Use uma ferramenta
- Depois que o backup estiver disponível no local secundário, siga estas etapas para restaurá-lo:
- 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 acessoetcdctl
instalado ekubectl
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. - 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 localetcdctl
, de acordo com seus nós secundários, mas as portasadvert
einit
devem ser as mesmas que as usadas no principal.Veja a seguir um exemplo de arquivomaak8s.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"
- 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çãokubectl
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 chamadoetcd_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 ~]$
- Faça download de TODOS os scripts de DR do snapshot
Verificar
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.
- 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.
- 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 snapshotetcd
/backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log
. - (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 dadosetcd
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.