Usar Snapshots de Artefato para Proteger os Clusters do OCI Kubernetes Engine contra Desastre
O Oracle Maximum Availability Architecture (Oracle MAA) fornece recomendações e utilitários que permitem a recuperação em cenários de desastre que afetam um local e forçando o redirecionamento de cargas de trabalho para um site de réplica. O foco desse conteúdo é a replicação de configuração do Kubernetes para aplicativos. Os aplicativos executados em clusters do Kubernetes dependem de muitos componentes diferentes para operar, 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 quais os aplicativos de runtime 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 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, incluindo o seguinte:
- 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 da Consistência de Disponibilidade de Backup (BAC).
- Use um único armazenamento para todos os diferentes tipos de dados, microsserviços e aplicativos com dependências, tanto quanto possível.
- Consulte Melhores práticas do Oracle MAA para o Oracle Database para proteção contra desastres para seus dados de runtime.
Além disso, você deve proteger o plano de controle de cluster do Kubernetes. Use os snapshots etcd apropriados para evitar corrupções, falhas e fornecer um flashback para clusters de trabalho. Embora o Oracle MAA forneça as melhores práticas para 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
Verifique o seguinte para obter mais detalhes:
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 (K8s) é replicada por meio de snapshots ETCD para proteção do plano de controle e com snapshots YAML para proteção da configuração do aplicativo. Você pode usar snapshots de artefatos ou pode usar cópias etcd ou snapshots de artefatos 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 etcd para obter mais detalhes. As imagens que o contêiner usa 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-multiregion-dr.png
kubernetes-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 Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores.
- 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.
- 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.
- 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.
- 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-apiserverdo plano de controle do Kubernetes. Ele executa o servidor da API Kubernetes. - Backup ETCD
O ETCD Backup é um backup do componente
etcddo plano de controle do Kubernetes. Oetcdconté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 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 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.
- Imagens apresentam um paradigma semelhante aos binários: As imagens não mudam tão frequentemente quanto 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 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.
Embora este manual 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 OCI Kubernetes Engine (OKE) e um cluster secundário em execução em um cluster do Kubernetes on-premises 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 Produtos e Atribuições Obrigatórios
Esta solução requer os seguintes produtos e funções:
- Cluster do Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine ou OKE)
- Nó de bastion capaz de gerenciar o sistema kubernetes
- 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 que não estão localizados na OCI.
Essas são as atribuições necessárias para cada serviço.
| Nome do Serviço: Atribuição | Obrigatório para ... |
|---|---|
Oracle Cloud Infrastructure : admin |
provisionar e configurar recursos e serviços se você estiver usando uma ou mais regiões da OCI. |
Cluster do Kubernetes Engine (principal): administrator |
executar todos os scripts. |
| Nós (principais) do Kubernetes Engine: Usuário do sistema operacional com permissões de execução e permissões ssh para secundário |
executar os seguintes scripts:
|
Cluster do Kubernetes Engine (secundário): administrator |
executar todos os scripts. |
| Nós (secundários) do Kubernetes Engine: Usuário do sistema operacional com permissões de execução |
executar os seguintes scripts:
|
Consulte Produtos, Soluções e Serviços Oracle para obter o que você precisa.