Melhores práticas para continuidade do negócio e recuperação após desastre no Azure Kubernetes Service (AKS)
À medida que gere clusters no Azure Kubernetes Service (AKS), o tempo de atividade da aplicação torna-se importante. Por predefinição, o AKS fornece elevada disponibilidade ao utilizar vários nós num Conjunto de Dimensionamento de Máquinas Virtuais (VMSS). No entanto, estes múltiplos nós não protegem o seu sistema contra uma falha na região. Para maximizar o tempo de atividade, planeie com antecedência para manter a continuidade do negócio e preparar-se para a recuperação após desastre.
Este artigo foca-se em como planear a continuidade do negócio e a recuperação após desastre no AKS. Saiba como:
- Planeie clusters do AKS em várias regiões.
- Encaminhe o tráfego em vários clusters com o Gestor de Tráfego do Azure.
- Utilize a georreplicação para os registos de imagens de contentor.
- Planear o estado da aplicação em vários clusters.
- Replicar o armazenamento em várias regiões.
Planear a implementação de várias regiões
Melhores práticas
Quando implementar vários clusters do AKS, selecione regiões onde o AKS está disponível. Utilize regiões emparelhadas.
Um cluster do AKS é implementado numa única região. Para proteger o sistema contra falhas na região, implemente a sua aplicação em vários clusters do AKS em diferentes regiões. Ao planear onde implementar o cluster do AKS, considere:
Disponibilidade da região do AKS
- Selecione regiões próximas dos seus utilizadores.
- O AKS expande-se continuamente para novas regiões.
-
- Para a área geográfica, selecione duas regiões emparelhadas.
- As atualizações da plataforma AKS (manutenção planeada) são serializadas com um atraso de, pelo menos, 24 horas entre regiões emparelhadas.
- Os esforços de recuperação para regiões emparelhadas são priorizados sempre que necessário.
Disponibilidade do serviço
- Decida se as regiões emparelhadas devem estar quentes/quentes, quentes/quentes ou quentes/frias.
- Pretende executar ambas as regiões ao mesmo tempo, com uma região pronta para começar a servir o tráfego? ou
- Pretende dar tempo a uma região para se preparar para servir o tráfego?
A disponibilidade da região do AKS e as regiões emparelhadas são uma consideração conjunta. Implemente os clusters do AKS em regiões emparelhadas concebidas para gerir a recuperação após desastre da região em conjunto. Por exemplo, o AKS está disponível nos E.U.A. Leste e E.U.A. Oeste. Estas regiões estão emparelhadas. Escolha estas duas regiões quando estiver a criar uma estratégia AKS BC/DR.
Quando implementar a sua aplicação, adicione outro passo ao pipeline CI/CD para implementar nestes múltiplos clusters do AKS. Atualizar os pipelines de implementação impede que as aplicações sejam implementadas apenas numa das suas regiões e clusters do AKS. Nesse cenário, o tráfego do cliente direcionado para uma região secundária não receberá as atualizações de código mais recentes.
Utilizar o Gestor de Tráfego do Azure para encaminhar o tráfego
Melhores práticas
Para obter o melhor desempenho e redundância, direcione todo o tráfego da aplicação através do Gestor de Tráfego antes de aceder ao cluster do AKS.
Se tiver vários clusters do AKS em diferentes regiões, utilize o Gestor de Tráfego para controlar o fluxo de tráfego para as aplicações em execução em cada cluster. O Gestor de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS que pode distribuir o tráfego de rede entre regiões. Utilize o Gestor de Tráfego para encaminhar utilizadores com base no tempo de resposta do cluster ou com base na prioridade.
Se tiver um único cluster do AKS, normalmente liga-se ao IP do serviço ou ao nome DNS de uma determinada aplicação. Numa implementação de vários clusters, deve ligar a um nome DNS do Gestor de Tráfego que aponte para os serviços em cada cluster do AKS. Defina estes serviços com os pontos finais do Gestor de Tráfego. Cada ponto final é o IP do balanceador de carga do serviço. Utilize esta configuração para direcionar o tráfego de rede do ponto final do Gestor de Tráfego numa região para o ponto final numa região diferente.
O Gestor de Tráfego realiza pesquisas DNS e devolve o ponto final mais adequado. Com o encaminhamento prioritário, pode ativar um ponto final de serviço primário e vários pontos finais de cópia de segurança caso o principal ou um dos pontos finais de cópia de segurança não esteja disponível.
Para obter informações sobre como configurar pontos finais e encaminhamento, veja Configurar o método de encaminhamento de tráfego prioritário no Gestor de Tráfego.
Encaminhamento de aplicações com o Azure Front Door Service
Com o protocolo anycast baseado em TCP dividido, o Azure Front Door Service liga rapidamente os seus utilizadores finais ao POP do Front Door mais próximo (Ponto de Presença). Mais funcionalidades do Azure Front Door Service:
- Terminação TLS
- Domínio personalizado
- Firewall de aplicações Web
- Reescrita de URLs
- Afinidade de sessão
Reveja as necessidades do tráfego da aplicação para compreender qual a solução mais adequada.
Interligar regiões com peering de rede virtual global
Ligue ambas as redes virtuais entre si através do peering de rede virtual para ativar a comunicação entre clusters. O peering de rede virtual interliga redes virtuais, proporcionando uma largura de banda elevada na rede principal da Microsoft, mesmo em diferentes regiões geográficas.
Antes de peering de redes virtuais com clusters do AKS em execução, utilize o Balanceador de Carga padrão no cluster do AKS. Este pré-requisito torna os serviços do Kubernetes acessíveis em todo o peering de rede virtual.
Ativar a georreplicação para imagens de contentor
Melhores práticas
Armazene as imagens de contentor no Azure Container Registry e replice georreplicar o registo para cada região do AKS.
Para implementar e executar as suas aplicações no AKS, precisa de uma forma de armazenar e extrair as imagens de contentor. O Container Registry integra-se com o AKS, para que possa armazenar de forma segura as suas imagens de contentor ou gráficos Helm. O Container Registry suporta a georreplicação multimaster para replicar automaticamente as suas imagens para regiões do Azure em todo o mundo.
Para melhorar o desempenho e a disponibilidade, utilize a georreplicação do Container Registry para criar um registo em cada região onde tenha um cluster do AKS. Cada cluster do AKS irá, em seguida, extrair imagens de contentor do registo de contentor local na mesma região.
Utilizar a georreplicação do Container Registry para extrair imagens da mesma região tem os seguintes benefícios:
- Mais rápido: extraia imagens de ligações de rede de alta velocidade e de baixa latência na mesma região do Azure.
- Mais fiável: se uma região não estiver disponível, o cluster do AKS extrai as imagens de um registo de contentor disponível.
- Mais barato: sem custos de saída de rede entre datacenters.
A georreplicação é uma funcionalidade de registo de contentor de SKU Premium . Para obter informações sobre como configurar a georreplicação, veja Georreplicação do Container Registry.
Remover o estado do serviço de contentores internos
Melhores práticas
Evite armazenar o estado do serviço dentro do contentor. Em vez disso, utilize uma plataforma como um serviço (PaaS) do Azure que suporte a replicação de várias regiões.
O estado do serviço refere-se aos dados dentro da memória ou no disco exigidos por um serviço para funcionar. O estado inclui as estruturas de dados e as variáveis de membro que o serviço lê e escreve. Dependendo da forma como o serviço é arquitetado, o estado também pode incluir ficheiros ou outros recursos armazenados no disco. Por exemplo, o estado pode incluir os ficheiros que uma base de dados utiliza para armazenar dados e registos de transações.
O estado pode ser externalizado ou co-localizado com o código que manipula o estado. Normalmente, pode externalizar o estado ao utilizar uma base de dados ou outro arquivo de dados que é executado em diferentes máquinas através da rede ou que fica sem processo no mesmo computador.
Os contentores e microsserviços são mais resilientes quando os processos que são executados dentro dos mesmos não mantêm o estado. Uma vez que as aplicações contêm quase sempre algum estado, utilize uma solução PaaS, como:
- Azure Cosmos DB
- Base de Dados do Azure para PostgreSQL
- Base de Dados do Azure para MySQL
- Base de Dados SQL do Azure
Para criar aplicações portáteis, veja as seguintes diretrizes:
Criar um plano de migração de armazenamento
Melhor prática
Se utilizar o Armazenamento do Azure, prepare e teste como migrar o armazenamento da região primária para a região de cópia de segurança.
As aplicações podem utilizar o Armazenamento do Azure para os respetivos dados. Se assim for, as aplicações são distribuídas por vários clusters do AKS em regiões diferentes. Tem de manter o armazenamento sincronizado. Eis duas formas comuns de replicar o armazenamento:
- Replicação assíncrona baseada na infraestrutura
- Replicação assíncrona baseada na aplicação
Replicação assíncrona baseada na infraestrutura
As aplicações podem necessitar de armazenamento persistente mesmo depois de um pod ser eliminado. No Kubernetes, pode utilizar volumes persistentes para manter o armazenamento de dados. Os volumes persistentes são montados numa VM de nó e, em seguida, expostos aos pods. Os volumes persistentes seguem pods mesmo que os pods sejam movidos para um nó diferente dentro do mesmo cluster.
A estratégia de replicação que utilizar depende da sua solução de armazenamento. As seguintes soluções de armazenamento comuns fornecem as suas próprias orientações sobre a recuperação após desastre e a replicação:
Normalmente, fornece um ponto de armazenamento comum onde as aplicações escrevem os respetivos dados. Em seguida, estes dados são replicados entre regiões e acedidos localmente.
Se utilizar o Azure Managed Disks, pode utilizar o Velero no Azure e o Kasten para processar a replicação e a recuperação após desastre. Estas opções são soluções de cópia de segurança nativas, mas não suportadas pelo Kubernetes.
Replicação assíncrona baseada na aplicação
Atualmente, o Kubernetes não fornece nenhuma implementação nativa para a replicação assíncrona baseada em aplicações. Uma vez que os contentores e o Kubernetes estão livremente acoplados, qualquer abordagem tradicional de aplicação ou idioma deve funcionar. Normalmente, as próprias aplicações replicam os pedidos de armazenamento, que são depois escritos no armazenamento de dados subjacente de cada cluster.
Passos seguintes
Este artigo centra-se nas considerações de continuidade de negócio e recuperação após desastre para clusters do AKS. Para obter mais informações sobre as operações de cluster no AKS, veja estes artigos sobre as melhores práticas: