Usar Snapshots de Artefato para Proteger seus Clusters do Kubernetes contra Desastres

Para garantir a continuidade dos negócios no caso de desastres, você vai querer implementar uma estratégia de recuperação de desastres (DR) para aplicativos em execução no Cluster do Kubernetes que fornece proteção de dados e permite 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 DR como um aplicativo tradicional (Oracle Java SE, Oracle Java EE etc.). Você deve manter uma cópia consistente e atualizada o mais 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.

O Oracle Maximum Availability Architecture (MAA) fornece recomendações e utilitários que permitem a recuperação em cenários de desastre que afetam um local e o redirecionamento de cargas de trabalho para um site de réplica. O foco deste livro é a replicação de configuração do Kubernetes para aplicativos. Os aplicativos executados em Clusters do Kubernetes dependem de muitos componentes diferentes para a operação, incluindo nós de plano de controle, nós de trabalho, balanceadores de carga e armazenamento. Ao mesmo tempo, os dados de runtime gerados por aplicativos em execução no Kubernetes apresentam os mesmos desafios que os aplicativos tradicionais - durante os aplicativos de runtime, eles podem gerar, ler e atualizar dados persistentes. Este manual de soluções fornece recomendações para replicar a configuração de um aplicativo em execução no Kubernetes. A proteção contra desastres dos 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, incluindo o seguinte:

Evite persistência poliglota. O uso de diferentes tipos de armazenamentos persistentes para dados de runtime é um problema quase impossível de resolver, de acordo com o Theorem BAC (Backup Availability Consistency).
Use uma única loja para todos os diferentes tipos de dados, microsserviços e aplicativos com dependências, o máximo possível.
Consulte as melhores práticas do Oracle MAA para Oracle Database para obter proteção contra desastres para seus dados de runtime.

Além disso, proteja o plano de controle Cluster do Kubernetes. Use os snapshots etcd apropriados para evitar danos, falhas e para fornecer um flashback para clusters de trabalho. Embora o Oracle Maximum Availability ofereça as melhores práticas para a proteção do plano de controle contra desastres, está fora do escopo deste documento descrever as técnicas necessárias nessa área.

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 necessária do Kubernetes (K8s) é replicada por meio de snapshots do ETCD para proteção do plano de controle e com snapshots do YAML para proteção da configuração do aplicativo. Você pode usar snapshots de artefato ou pode usar cópias etcd ou snapshots de artefato para proteção de configuração específica do aplicativo para proteção de configuração específica do aplicativo. Consulte restauração de Clusters do Kubernetes com base em snapshots do etcd para obter mais detalhes. As imagens que o contêiner usa são hospedadas em registros, sejam locais para cada cluster ou em repositórios externos (as imagens não são consideradas por si mesmas uma configuração de cluster do Kubernetes).

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-multiregion-dr.png

kubernetes-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.
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.
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.
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 namespaces do Kubernetes envolvidos 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.
Imagens de Contêiner apresentam um paradigma semelhante aos binários: As imagens não mudam com a frequência que a 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.

Embora este playbook apresente um exemplo usando o Oracle Cloud Infrastructure, as recomendações são genéricas para Clusters Kubernetes personalizados instalados em sistemas locais. Você pode usar as etapas e os scripts fornecidos entre um Cluster principal do Kubernetes em execução no Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) e um cluster secundário em execução em um Cluster do Kubernetes local ou personalizado. Você também pode usar as etapas e os scripts entre um Cluster principal do Kubernetes em execução no OKE e um cluster secundário em execução também no OKE ou entre dois Clusters do Kubernetes locais ou personalizados.

Sobre Funções e Produtos Necessários

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

Cluster do Kubernetes
Nó bastion capaz de gerenciar o sistema kubernetes
OCI (Oracle Cloud Infrastructure)
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 que não estão localizados no OCI.

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

Nome do Serviço: Atribuição	Obrigatório para...
Oracle Cloud Infrastructure: `admin`	provisione e configure recursos e serviços se você estiver usando uma ou mais regiões do OCI.
Cluster do Kubernetes (principal): `administrator`	executar todos os scripts.
Nós Kubernetes (principais): usuário do SO com permissões de execução e permissões ssh para secundários	execute os seguintes scripts: `maak8-get-all-artifacts.sh` `maak8DR-apply.sh`
Cluster do Kubernetes (secundário): `administrator`	executar todos os scripts.
Nós do Kubernetes (secundários): usuário do SO com permissões de execução	execute os seguintes scripts: `removeyamlblock.sh` `apply-artifacts.sh` `maak8-push-all-artifacts.sh`

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

Alterar Log

Este log lista alterações significativas:

12 de julho de 2023

Revisou o diagrama da arquitetura.
Melhorou o conteúdo.