Saiba Mais sobre a Restauração de Clusters do Kubernetes com Base em Snapshots do etcd

Para garantir a continuidade dos negócios em caso de desastres, você vai querer implementar uma estratégia de recuperação de desastres para aplicativos em execução em clusters do Kubernetes. Use estas recomendações do Oracle Maximum Availability Architecture (Oracle MAA) que fornecem proteção de dados e permitem que você alterne rapidamente para um sistema stand-by com perda mínima de dados e produtividade.

Apesar da tremenda mudança que a adoção do Kubernetes implica para a arquitetura do sistema de TI, um sistema Kubernetes apresenta paradigmas semelhantes de recuperação de desastres (DR) como um aplicativo tradicional (como Oracle Java SE, Oracle Java EE ou JavaScript). Ele deve manter uma cópia consistente e "o mais atualizada possível" do seu sistema principal em um local secundário que possa retomar as cargas de trabalho caso um desastre cause tempo de inatividade na região principal.

Este manual de soluções fornece recomendações e utilitários do Oracle MAA que criarão um sistema Kubernetes secundário e permitirão que você se recupere em cenários de desastre que afetam um local e forçando o redirecionamento de cargas de trabalho para um site de réplica.

Embora este manual de soluções se concentre na restauração de um cluster do Kubernetes em outra região, você pode usar os mesmos scripts e procedimentos para restaurar um cluster no local para um momento anterior. Esta operação pode ser útil em cenários diferentes da recuperação de desastres, como os seguintes:

• Quando o plano de controle estiver configurado incorretamente.
• Quando o banco de dados etcd é perdido, corrompido ou quando etcd não está sendo exibido corretamente.
• Quando uma implantação incorreta ou erro do usuário afeta vários aplicativos ou microsserviços e o cluster deve ser revertido para uma versão ou encarnação anterior. Uma restauração de snapshot ETCD reverterá todos os artefatos até o ponto no tempo em que o snapshot (backup) foi feito.

Este documento se concentra na replicação de dados etcd do Kubernetes para um local secundário. Todas as informações de um cluster do Kubernetes são armazenadas em etcd, que é um armazenamento de valores de chave usado como armazenamento de apoio do Kubernetes para os dados do cluster. Este manual de soluções fornece recomendações para replicar um cluster do Kubernetes criado com a ferramenta kubeadm do Kubernetes (consulte https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) com base em etcd restore. Os procedimentos e scripts de configuração fornecidos podem exigir personalizações para outro tipo de clusters (aqueles não criados com kubeadm), mas, em geral, são válidos desde que haja acesso aos pontos finais etcd que o plano de controle do Kubernetes usa. Esta solução de replicação requer uma configuração específica para o cluster secundário e usará uma cópia de etcd (também chamada de etcd snapshots) para ativar exatamente os mesmos artefatos que existiam no principal.

Você pode usar snapshots de artefatos ou ferramentas de backup do Kubernetes de terceiros para replicar namespaces e aplicativos específicos em sistemas Kubernetes. No entanto, eles não protegem clusters de corrupções de arquivos e configurações incorretas nos metadados do plano de controle. Além de usá-los para proteção contra desastres, você pode usar etcd snapshots para restaurações locais e reverter clusters do Kubernetes para um ponto de trabalho anterior. Se o sistema etcd store e etcd cluster não estiver íntegro, os aplicativos poderão continuar em execução, mas realocações de pods, alterações de configuração, acesso secreto e qualquer outra operação que exija a disponibilidade do plano de controle não funcionará corretamente. É por esse motivo que a preservação etcd deve ser uma parte crítica de qualquer procedimento de ciclo de vida do cluster do Kubernetes.

Além dos dados de configuração do Kubernetes, os aplicativos e microsserviços executados no Kubernetes podem gerar dados no runtime. A proteção contra desastres de dados de tempo de execução está fora do escopo deste documento e deve ser tratada exatamente da mesma forma que nos aplicativos tradicionais em execução nos servidores de aplicativos:

• Evite a persistência Poliglota (o uso de diferentes tipos de armazenamentos persistentes para dados de runtime é "quase" impossível de resolver o problema de acordo com o Teorema BAC)
• Use um único armazenamento para todos os diferentes tipos de dados, microsserviços e aplicativos com dependências o máximo possível
• Consulte Melhores Práticas do Oracle MAA para o Oracle Database para obter proteção contra desastres para seu runtime

Antes de Começar

Há vários resumos técnicos do Oracle Maximum Availability Architecture (MAA) que descrevem como configurar um sistema de recuperação de desastres (DR) para sistemas de middleware tradicionais. Esses documentos detalham os requisitos de proteção contra desastres para os componentes de infraestrutura externa (como armazenamento, balanceadores de carga e banco de dados) que os aplicativos Kubernetes usam.

Verifique o seguinte para obter mais detalhes:

• Recuperação de Desastre do Oracle WebLogic Server for Oracle Cloud Infrastructure
• Recuperação de Desastre do SOA Suite on Oracle Cloud Infrastructure Marketplace

Consulte Usar snapshots de artefatos para proteger seus clusters do OCI Kubernetes Engine contra desastres para obter detalhes sobre o uso de snapshots de artefatos para proteção de configuração específica do aplicativo.

Arquitetura

Essa arquitetura mostra a topologia do sistema de recuperação de desastres (DR) para o cluster do Kubernetes.

Todas as informações de runtime, configuração e metadados que residem no banco de dados principal são replicadas da Região 1 para a Região 2 com o Oracle Autonomous Data Guard. A configuração necessária do cluster do Kubernetes é replicada por meio de snapshots etcd para proteção do plano de controle. Você pode usar cópias etcd ou snapshots de artefatos para proteção de configuração específica do aplicativo. As imagens usadas pelos contêineres são hospedadas em registros locais para cada cluster ou em repositórios externos (as imagens não são consideradas uma configuração de cluster do Kubernetes por si só).

Observação:

A configuração do Oracle Autonomous Data Guard para o banco de dados de runtime está fora do escopo deste documento.

Descrição da ilustração kubernetes-etcd-multiregion-dr.png

kubernetes-etcd-multi-região-dr-oracle.zip

Essa arquitetura suporta os seguintes componentes:

• Região

  Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

• Balanceador de carga

  O serviço Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores no back-end.

• Gateway de roteamento dinâmico (DRG)

  O DRG é um roteador virtual que fornece um caminho para o tráfego de rede privada entre VCNs na mesma região, entre uma VCN e uma rede fora da região, como uma VCN em outra região do Oracle Cloud Infrastructure, uma rede local ou uma rede em outro provedor de nuvem.

• Data Guard

  O Oracle Data Guard e o Oracle Active Data Guard fornecem um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados stand-by e que permitem que os bancos de dados Oracle de produção permaneçam disponíveis sem interrupção. O Oracle Data Guard mantém esses bancos de dados stand-by como cópias do banco de dados de produção usando replicação na memória. Se o banco de dados de produção ficar indisponível devido a uma interrupção planejada ou não planejada, o Oracle Data Guard poderá alternar qualquer banco de dados stand-by para a atribuição de produção, minimizando o tempo de inatividade associado à interrupção. O Oracle Active Data Guard fornece a capacidade adicional de descarregar cargas de trabalho de leitura principalmente para bancos de dados stand-by e também fornece recursos avançados de proteção de dados.

• Oracle Real Application Clusters (Oracle RAC)

  O Oracle RAC permite que você execute um único Oracle Database em vários servidores para maximizar a disponibilidade e permitir a escalabilidade horizontal, enquanto acessa o armazenamento compartilhado. As sessões do usuário que estabelecem conexão com instâncias do Oracle RAC podem fazer failover e reproduzir alterações com segurança durante interrupções, sem alterações nos aplicativos do usuário final.

• Registro

  O Oracle Cloud Infrastructure Registry é um registro gerenciado pela Oracle que permite simplificar seu desenvolvimento para o workflow de produção. O registro facilita o armazenamento, o compartilhamento e o gerenciamento de artefatos de desenvolvimento, como imagens do Docker. A arquitetura altamente disponível e escalável do Oracle Cloud Infrastructure garante que você possa implantar e gerenciar seus aplicativos de forma confiável.

• Kubernetes Engine

  O Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine ou OKE) é um serviço totalmente gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos em contêineres na nuvem. Você especifica os recursos de computação necessários, e o serviço Kubernetes Engine os provisiona no Oracle Cloud Infrastructure em uma tenancy existente. O OKE usa o Kubernetes para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos em contêineres entre clusters de hosts.

• Cluster do Kubernetes

  Um cluster do Kubernetes é um conjunto de máquinas que executam aplicativos em contêineres. O Kubernetes fornece uma plataforma portátil, extensível e de código aberto para gerenciar cargas de trabalho e serviços em contêineres nesses nós. Um cluster do Kubernetes é formado por nós de trabalho e nós de plano de controle.

• Plano de controle do Kubernetes
  Um plano de controle do Kubernetes gerencia os recursos dos nós de trabalho e pods em um cluster do Kubernetes. Os componentes do plano de controle detectam e respondem a eventos, executam a programação e movem recursos do cluster. Estes são os componentes do plano de controle:

  • kube-apiserver: Executa o servidor de API do Kubernetes.
  • etcd: Armazenamento de chave/valor distribuído para todos os dados do cluster.
  • kube-scheduler: Determina em qual nó novos pods não designados serão executados.
  • kube-controller-manager: Executa processos do controlador.
  • cloud-controller-manager: vincula seu cluster à API específica da nuvem.
• Nó de trabalho do Kubernetes

  Um nó de trabalho do Kubernetes é uma máquina de trabalho que executa aplicativos conteinerizados em um cluster do Kubernetes. Cada cluster tem pelo menos um nó de trabalho.

• Controlador de Entrada

  Um controlador de Entrada é um componente que é executado em um cluster do Kubernetes e gerencia os recursos de Entrada. Ele recebe tráfego da rede externa, o roteia para o serviço correto e executa balanceamento de carga e terminação SSL. O controlador de Entrada normalmente é executado como um pod separado no cluster e pode ser dimensionado independentemente dos serviços que gerencia.

• API de Ponto Final KUBE

  A API KUBE-Endpoint é o componente kube-apiserver do plano de controle do Kubernetes. Ele executa o servidor da API Kubernetes.

• Backup ETCD

  O ETCD Backup é um backup do componente etcd do plano de controle do Kubernetes. O etcd contém o armazenamento de chave/valor distribuído para todos os dados do cluster. É importante criar um Backup ETCD para recuperar clusters Kubernetes para recuperação de desastres.

• Snapshots YAML

  Um snapshot YAML é uma cópia pontual dos arquivos (YAML) que contêm a definição dos artefatos em um cluster do Kubernetes. O snapshot é um arquivo tar que você pode usar para restaurar esses artefatos no mesmo cluster do Kubernetes ou em outro cluster.

Considerações sobre a Proteção contra Desastres do Kubernetes

Ao implementar a proteção contra desastres para Kubernetes, considere o seguinte:

• Recuperação de desastre simétrico (DR): A Oracle recomenda o uso exato da mesma capacidade e configuração de recursos no principal e no secundário. Os clusters do Kubernetes nas duas regiões devem ter recursos semelhantes disponíveis, como o número de nós de trabalho (e sua capacidade de hardware) e outra infraestrutura (armazenamento compartilhado, balanceadores de carga, bancos de dados etc.). Os recursos dos quais o cluster do Kubernetes na região secundária depende devem ser capazes de acompanhar as mesmas cargas de trabalho que as principais. Além disso, os dois sistemas devem ser consistentes funcionalmente com os mesmos serviços dos quais o sistema restaurado depende, carros laterais, mapas de configuração (CMs) devem ser usados em ambos os locais.
• Alias de nome de host e virtualização: É importante planejar os nomes de host usados pelos nós no site secundário. Os nomes de host ou nomes de host de alias do plano de controle e dos nós de trabalho devem estar "ativos" no local secundário antes de restaurar um snapshot etcd de um cluster principal do Kubernetes. Os nomes de nós são armazenados em diferentes artefatos de um cluster do Kubernetes para identificar nós de trabalho, para marcar alocações de pod, em mapas de configuração (config) que descrevem o próprio cluster e em vários arquivos e entradas de configuração. Seu local secundário deve identificar os endereços kube-api do worker, do plano de controle e do front-end com os mesmos nomes de host usados no cluster principal do Kubernetes (um nome totalmente qualificado pode ser diferente no nome do domínio, mas o nome do host deve ser o mesmo. Sem o alias do nome do host, uma restauração de snapshot etcd não funcionará corretamente, pois kubelets, schedulers, controladores e, em geral, os serviços do plano de controle não poderão atingir os pontos finais e hosts apropriados usados pela configuração replicada. Não use endereços IP para identificar nós no Kubernetes; em vez disso, sempre use nomes de host.
• Imagens apresentam um paradigma semelhante aos binários: As imagens podem não ser alteradas com a frequência da configuração do Kubernetes e talvez você não precise atualizar imagens com cada replicação de cluster do Kubernetes. As imagens usadas pelo sistema primário devem ser as mesmas usadas no sistema secundário ou podem ocorrer inconsistências e falhas. No entanto, a replicação de imagens está fora do escopo deste manual. Há várias estratégias que você pode usar para manter um uso consistente de imagens entre dois locais, incluindo o seguinte:
  • Salve imagens no nó de trabalho principal e carregue nos nós de trabalho secundários. Essa abordagem é muito fácil de implementar, mas incorre em sobrecarga de gerenciamento. O uso de registros de contêiner tem benefícios consideráveis e salvar imagens localmente dificulta o gerenciamento de versões e atualizações.
  • As imagens podem residir em registros de Contêiner totalmente externos em diferentes regiões ou data centers dos usados pelo principal e pelo stand-by. Produtos e bibliotecas externos são mantidos por terceiros e sua disponibilidade é normalmente implícita em seus lançamentos.
  • As imagens podem residir em Registros de Contêiner localizados no principal e no stand-by. Cada região é atualizada em paralelo quando uma nova versão de uma imagem é liberada. Isso fornece melhor controle sobre o software usado, mas incorre em maior sobrecarga de gerenciamento. É necessário duplicar imagens e gerenciar as credenciais para acessar dois registros diferentes. As ferramentas de CI/CD geralmente são usadas para essa abordagem.
• Diferenças entre o cluster primário e o secundário: Espera-se (como é em geral para sistemas de DR) que o primário e o secundário sejam uma réplica um do outro em termos de versões e configuração usadas. Os seguintes aspectos são especialmente relevantes:
  1. Versões do Kubernetes
  2. Versão do runtime e do runtime do contêiner
  3. Versões de plug-in de rede e plug-in de rede
  4. podSubnet e servicesubnet
  5. Diretório hostpath etcd e versão da imagem etcd
  6. Plug-in de rede e versão da imagem dns
  7. Repositório de imagens para pods do plano de controle

  As Configurações de Proteção contra Desastres com pequenas diferenças entre sites na versão do Kubernetes podem funcionar, mas podem deixar o cluster em um estado inconsistente após uma restauração do snapshot etcd de um principal. Informações sobre soquetes de runtime do contêiner, versão do Kubernetes etc. são armazenadas no próprio Kubernetes. Por exemplo, as informações cri-socket são específicas de cada nó com base no runtime do contêiner que está sendo usado e são armazenadas em mapas de configuração internos. Muitas informações usadas para upgrades por kubeadm se baseiam em mapas de configuração no namespace kube-system. Portanto, é importante que tanto o primário quanto o secundário usem as mesmas informações nesses configmaps. Você pode usar esse comando para armazenar todas as informações relevantes dos configmaps importantes nos arquivos principal e stand-by nos arquivos yaml.

  [prompt]$ kubectl get cm -n kube-system | grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get cm "$1" -o yaml -n kube-system > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}

  Da mesma forma, você pode fazer uma cópia da configuração do nó em cada site com o seguinte comando:

  [prompt]$ kubectl get node |grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get node "$1" -o yaml > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}
  

Este manual de soluções apresenta um exemplo usando clusters do Kubernetes criados com a ferramenta kubeadm. As recomendações são genéricas para clusters Kubernetes personalizados instalados em sistemas locais, mas a maioria dos scripts pode exigir modificações para clusters que não são criados com a ferramenta kubeadm. Você deve usar as etapas e os scripts fornecidos entre os clusters do Kubernetes que executam a mesma versão do etcd e do Kubernetes. A restauração de snapshots etcd em diferentes versões do Kubernetes pode levar a inconsistências e clusters etcd instáveis.

Sobre Produtos e Atribuições Obrigatórios

Esta solução requer os seguintes produtos e funções:

• Cluster do Kubernetes
• Bastion capaz de gerenciar o sistema Kubernetes, acessar os pontos finais etcd do cluster e acessar os diferentes nós do plano de controle com ssh
• (Opcional) Oracle Cloud Infrastructure (OCI)

  Este manual é baseado no uso de regiões e recursos da OCI para as regiões principal e secundária. No entanto, essa solução também é aplicável a clusters do Kubernetes localizados on-premises.

Essas são as atribuições necessárias para cada serviço.

Nome do Serviço: Atribuição	Obrigatório para ...
Cluster do Kubernetes (principal): administrator	executar todos os scripts.
Nós (principais) do Kubernetes: usuário com direitos sudo para raiz	executar os seguintes scripts: maak8s-force-stop-cp.sh maak8-etcd-backup.sh maak8-etcd-restore.sh
Cluster do Kubernetes (secundário): administrator	executar todos os scripts.
Nós do Kubernetes (secundários): usuário com direitos sudo para raiz	executar os seguintes scripts: maak8s-force-stop-cp.sh maak8-etcd-backup.sh maak8-etcd-restore.sh

Consulte Produtos, Soluções e Serviços Oracle para obter o que você precisa.