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

Para garantir a continuidade dos negócios no 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 na 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 atualizado 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 ponto anterior no tempo. Essa operação pode ser útil em cenários diferentes da recuperação de desastres, como os seguintes:

Quando o plano de controle está configurado incorretamente.
Quando o banco de dados etcd é perdido, corrompido ou quando o etcd não está aparecendo corretamente.
Quando uma implantação incorreta ou um 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 do ETCD reverterá todos os artefatos para o ponto no momento em que o snapshot (backup) foi feito.

O foco deste documento é replicar dados etcd do Kubernetes em um local secundário. Todas as informações de um cluster do Kubernetes são armazenadas no etcd, que é um armazenamento de valor 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 Kubernetes criado com a ferramenta kubeadm do Kubernetes (consulte https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) com base na restauração etcd. Os procedimentos de configuração e os scripts fornecidos podem exigir personalizações para outros tipos de clusters (os que não foram criados com kubeadm), mas, em geral, são válidos desde que haja acesso aos pontos finais do etcd que o plano de controle do Kubernetes usa. Essa solução de replicação requer uma configuração específica para o cluster secundário e usará uma cópia do etcd (também chamada de snapshots etcd) para criar os mesmos artefatos existentes 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 corrompimentos 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 snapshots do etcd para restaurações locais e reverter Clusters do Kubernetes para um ponto de trabalho anterior no tempo. Se o seu sistema de armazenamento etcd e cluster etcd não estiverem íntegros, os aplicativos poderão continuar sendo executados, mas realocações de pod, 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 do 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 em 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 persistência poliglota (o uso de diferentes tipos de armazenamentos persistentes para dados de runtime é um "quase" impossível de resolver o problema de acordo com o Teorema BAC)
Use uma única loja 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 Oracle Database para obter proteção contra desastres em 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 dos componentes de infraestrutura externa (como armazenamento, balanceadores de carga e banco de dados) que os aplicativos Kubernetes usam.

Para obter mais detalhes, consulte o seguinte:

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 de cluster do Kubernetes necessária é replicada por meio de snapshots do 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. Consulte Usar snapshots de artefatos para proteger seus Clusters do Kubernetes contra desastre para obter mais detalhes. 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 conta própria).

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-multiregion-dr-oracle.zip

Essa arquitetura suporta os seguintes componentes:

Região
Uma 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 de tráfego automatizada 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 fornece um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados standby para permitir 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 standby como cópias do banco de dados de produção. Em seguida, se o banco de dados de produção ficar indisponível por causa de 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 indisponibilidade associado à interrupção.
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 se conectam às instâncias do Oracle RAC podem fazer failover e reproduzir com segurança as alterações durante interrupções, sem qualquer alteração nas aplicações do usuário final.
Registro de Contêiner
O Oracle Cloud Infrastructure Registry é um registro gerenciado pela Oracle que permite simplificar seu workflow de desenvolvimento para produção. O registro facilita o armazenamento, o compartilhamento e o gerenciamento de artefatos e imagens de desenvolvimento. 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.
Container Engine para Kubernetes
O Oracle Cloud Infrastructure Container Engine for Kubernetes é um serviço totalmente gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos de contêineres para a nuvem. Você especifica os recursos de computação necessários para os seus aplicativos, e o Container Engine for Kubernetes os provisiona no Oracle Cloud Infrastructure em uma tenancy existente. O Container Engine for Kubernetes usa o Kubernetes para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos de contêineres em 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 de código-fonte aberto portátil, extensível 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 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 de 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 atribuídos 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 em contêiner dentro de um cluster do Kubernetes. Cada cluster tem pelo menos um nó de trabalho.
Controladora 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 geralmente é executado como um pod separado no cluster e pode ser dimensionado independentemente dos serviços que ele gerencia.
API KUBE-Endpoint
A API KUBE-Endpoint é o componente kube-apiserver do plano de controle Kubernetes. Ele executa o servidor de API do Kubernetes.
Backup de 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 do Kubernetes para recuperação de desastres.
Instantâneos YAML
Um snapshot do 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.

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

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

Recuperação de desastre simétrica (DR): A Oracle recomenda o uso exato da mesma capacidade e configuração de recurso em primária e secundária. 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 a principal. 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 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 do colaborador, do plano de controle e do front-end kube-api com os mesmos nomes de host usados no cluster principal do Kubernetes (um nome totalmente qualificado pode diferir no nome do domínio, mas o nome do host deve ser o mesmo. Sem a criação de alias de nome de host, uma restauração de snapshot etcd não funcionará corretamente, pois kubelets, schedulers, controladores e, em geral, os serviços de plano de controle não conseguirão acessar os pontos finais e hosts apropriados usados pela configuração replicada. Não use IPs para identificar nós no kubernetes; sempre use nomes de host.
Imagens de Contêiner 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 principal 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:
- Salvar imagens em principal e carregar nos nós de trabalho secundários. Essa abordagem é muito fácil de implementar, mas implica em custos indiretos de gerenciamento. O uso de registros de contêineres tem benefícios consideráveis e a gravação de imagens localmente torna mais difícil gerenciar 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 stand-by. Os produtos e bibliotecas externos são mantidos por terceiros e sua disponibilidade geralmente é implícita em suas versões.
- As imagens podem residir em Registros de Contêiner localizados em principal e 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 acarreta maior sobrecarga de gerenciamento. Ele requer a duplicação de imagens e o gerenciamento das credenciais para acessar dois registros diferentes. As ferramentas CI/CD geralmente são usadas para essa abordagem.

Este manual de soluções apresenta um exemplo usando clusters do Kubernetes criados usando a ferramenta kubeadm. As recomendações são genéricas para clusters personalizados do Kubernetes 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 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 Funções e Produtos Necessários

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

Cluster do Kubernetes
Bastion capaz de gerenciar o sistema Kubernetes para acessar os pontos finais etcd do cluster e acessar os diferentes nós de plano de controle com ssh
(Opcional) Oracle Cloud Infrastructure (OCI)
Este manual é baseado no uso de regiões e recursos do OCI para as regiões primária e secundária. No entanto, essa solução também se aplica a clusters do Kubernetes localizados no local.

Estas 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 Kubernetes (principais): usuário com direitos sudo para root	execute 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 root	execute os seguintes scripts: `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`

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