Configurar para Recuperação de Desastres

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

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. Os scripts exigem que os dois clusters do Kubernetes já existam. Você deve poder acessar os dois clusters com a ferramenta de linha de comando Kubernetes, kubectl, para executar comandos neles.

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 scripts fornecidos neste manual não verificam recursos, o plano de controle ou a configuração do nó de trabalho.

O diagrama a seguir mostra que, quando configurado, você pode restaurar o snapshot do artefato em clusters do Kubernetes completamente diferentes.

Veja a seguir a descrição da kube-api-dr.png

Descrição da ilustração kube-api-dr.png

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 no secundário.
Isso inclui montagens de armazenamento compartilhado, balanceadores de carga e bancos de dados do pod. Ele também inclui quaisquer sistemas externos usados pelos namespaces que estão sendo restaurados.
Crie manualmente os volumes persistentes necessários usados pelos namespaces envolvidos antes de executar os scripts.

Esta é a ação padrão. Os scripts criarão as reivindicações de volume persistente usadas no principal. No entanto, como os volumes persistentes podem ser compartilhados por diferentes reivindicações em namespaces diferentes, os scripts de automação esperam que você crie manualmente volumes persistentes no cluster secundário antes de executar os scripts extract-apply.

Como alternativa, você pode adicionar pv à variável nons_artifacts_types no arquivo maak8DR-apply.env (ou seja, use export nons_artifacts_types="crd clusterrole clusterrolebinding pv"). Isso instrui os scripts a TAMBÉM criar os volumes persistentes no secundário. Neste segundo caso, cabe a você determinar se podem surgir conflitos com outras reivindicações de volume persistentes.
Confirme se o cluster secundário tem acesso apropriado às imagens do contêiner usadas pelos namespaces que estão sendo replicados:
- Os segredos usados para acessar registros de contêiner existentes nos namespaces a serem replicados são copiados pelos scripts fornecidos com este manual. Se as credenciais dos registros estiverem armazenadas em outros namespaces, você deverá criá-las manualmente em secundário. Como alternativa, você pode rotular as credenciais com maak8sapply: my_ns (em que my_ns é o namespace que está sendo restaurado) para que o segredo também seja incluído no snapshot YAML. Por exemplo,
```
kubectl label secret regcredfra -n other_namespace 
maak8sapply=namespace_being_backedup
```
- Se você estiver usando imagens carregadas manualmente nos nós de trabalho principais, também deverá carregá-las manualmente nos nós de trabalho secundários.
  
  Observação:
  Os scripts fornecidos reportarão as imagens usadas nos namespaces que estão sendo replicados.
Forneça acesso aos clusters principal e secundário por meio de nós bastions capazes de executar operações kubectl nos pontos finais da API Kube de cada cluster.
É possível usar um terceiro nó que possa ssh ou scp para ambos (principal e stand-by) e coordenar a sincronização de DR. No entanto, para evitar saltos desnecessários e sobrecarga de sessão, a Oracle recomenda o uso do bastion principal como coordenador de DR. Outras opções exigem a personalização dos scripts fornecidos.
Use o label maak8sapply: my_ns se quiser que os recursos sem namespace incluídos no backup sejam aplicados na secundária ao restaurar o my_ns namespace.

Para os artefatos que residem na raiz do cluster (ou seja, não fazem parte de um namespace preciso), os scripts procuram referências de campo namespace: e group: que contenham os nomes dos namespaces. Se você precisar de outros recursos sem namespace incluídos no backup, poderá rotulá-los para serem adicionados.

Por exemplo, a definição de recurso personalizado domains.weblogic.oracle não faz parte de nenhum namespace, mas você pode usar o seguinte para incluí-la no label da operação apply: kubectl label crd domains.weblogic.oracle maak8sapply=opns.

Configurar

Configure a recuperação de desastre de snapshot YAML.

Faça download de todos os scripts de recuperação de desastre de snapshot YAML em "Download Code".

Observação:
Todos os scripts devem estar no mesmo caminho porque os scripts principais usam outros scripts auxiliares.
Edite o script maak8DR-apply.env e atualize os endereços e a chave ssh necessários para acessar o sistema secundário.
Por exemplo,
```
export user_sec=opc
export ssh_key_sec=/home/opc/Key.ppk
#Secondary bastion node
export sechost=10.10.0.23
```
Personalize os valores para exclude_list e nons_artifacts_types, conforme necessário.
- exclude_list: Esta é uma lista separada por espaços desses namespaces que devem ser excluídos do backup mesmo ao tentar fazer backup de TODOS os namespaces personalizados. Isso é para evitar copiar namespaces relacionados ao plano de controle que não serão aplicáveis no secundário.
- nons_artifacts_types: Esta é a lista ou os artefatos que pertencem à árvore raiz (ou seja, não fazem parte de um namespace preciso), mas que também devem ser incluídos no snapshot. A estrutura procurará referências nos namespaces que estão sendo submetidos a backup.
Geralmente, você pode usar os valores padrão fornecidos no arquivo:
```
#List of namespaces that will be excluded from the backup
export exclude_list="kube-system kube-flannel kube-node-lease kube-public"
#Root artifacts that will be included
export nons_artifacts_types="crd clusterrole clusterrolebinding"
```
Execute o script maak8DR-apply.sh fornecendo como argumentos os namespaces selecionados para replicação.
- Se você não fornecer argumentos, os scripts replicarão TODOS os namespaces, excluindo os namespaces fornecidos na variável exclude_list.
- Se você usar uma lista precisa de namespaces, deverá ordená-los com base nas dependências com outros namespaces.
  
  Ou seja, se o namespace soans depender ou usar serviços no namespace opns, opns deverá aparecer primeiro na lista. Por exemplo, em vez de ./maak8DR-apply.sh soans opns, execute o seguinte:
```
./maak8DR-apply.sh opns soans
```

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.

Quando você executa o script maak8DR-apply.sh, o framework cria o diretório working_dir como /tmp/backup.date. Quando você executa os scripts maak8-get-all-artifacts.sh e maak8-push-all-artifacts.sh individualmente, o diretório de trabalho é fornecido em cada caso como um argumento na linha de comando.

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.
Verifique no arquivo $working_dir/date/backup-operations.log principal possíveis erros nas operações de extração e aplicação.
Verifique os arquivos $working_dir/restore.log e $working_dir/date/restore-operations.log no secundário para possíveis erros nas operações de extração e aplicação.
O arquivo restore-operations.log contém as operações de restauração detalhadas.