Práticas recomendadas para continuidade dos negócios e recuperação de desastres no Serviço de Kubernetes do Azure (AKS)

À medida que você vai gerenciando clusters no Serviço de Kubernetes do Azure (AKS), o tempo de atividade do aplicativo vai ficando mais importante. Por padrão, o AKS fornece alta disponibilidade usando vários nós em um VMSS (conjunto de dimensionamento de máquinas virtuais). Esses vários nós não o protegem contra uma falha de região. Para maximizar o tempo de atividade, planeje com antecedência para manter a continuidade dos negócios e prepare-se para a recuperação de desastres.

Este artigo aborda considerações de continuidade dos negócios e recuperação de desastres no AKS. Você aprenderá como:

  • Planeje clusters do AKS em várias regiões.
  • Roteie o tráfego entre vários clusters com o Gerenciador de Tráfego do Azure.
  • Use a replicação geográfica em seus registros de imagem de contêiner.
  • Planeje o estado do aplicativo entre vários clusters.
  • Replique o armazenamento em várias regiões.

Planejar para implantações em várias regiões

Prática recomendada

Ao implantar vários clusters AKS, escolha as regiões onde o AKS está disponível. Use regiões emparelhadas.

Um cluster do AKS é implantado em uma única região. Para se proteger contra falhas de região, implante seu aplicativo em vários clusters do AKS em regiões diferentes. Ao planejar onde implantar o cluster do AKS, considere:

  • Disponibilidade de região do AKS
    • Escolha regiões perto de seus usuários.
    • O AKS se expande continuamente em novas regiões.
  • Regiões emparelhadas do Azure
    • Para a sua área geográfica, escolha duas regiões emparelhadas.
    • As atualizações da plataforma AKS (manutenção planejada) são serializadas com um atraso de pelo menos 24 horas entre as regiões emparelhadas.
    • Os esforços de recuperação para regiões emparelhadas são priorizados quando necessário.
  • Disponibilidade do serviço
    • Decida se as regiões emparelhadas devem ser em hot/hot, hot/warm ou hot/cold.
    • Deseja executar ambas as regiões ao mesmo tempo, com uma região pronta para começar a receber o tráfego? Ou,
    • Deseja dar a uma região tempo para se preparar para atender ao tráfego?

A disponibilidade de região do AKS e as regiões emparelhadas são consideradas em conjunto. Implante os clusters do AKS em regiões emparelhadas projetadas para gerenciar a recuperação de desastre da região em conjunto. Por exemplo, o AKS está disponível no Leste dos EUA e no Oeste dos EUA. Essas regiões também estão emparelhadas. Escolha essas duas regiões ao criar uma estratégia de BC/DR do AKS.

Ao implanta seu aplicativo, adicione outra etapa ao pipeline de CI/CD para implantar esses vários clusters do AKS. Atualizar os pipelines de implantação evita que os aplicativos sejam implantados em apenas uma de 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.

Usar o Gerenciador de Tráfego do Azure para rotear o tráfego

Prática recomendada

O Gerenciador de Tráfego do Azure pode direcioná-lo para a instância do aplicativo e o cluster do AKS mais próximo. Para obter melhor desempenho e redundância, direcione todo o tráfego do aplicativo por meio do Gerenciador de Tráfego antes que ele vá para o cluster do AKS.

Se tiver vários clusters do AKS em regiões diferentes, use o Gerenciador de Tráfego para controlar o fluxo de tráfego para os aplicativos em execução em cada cluster. O Gerenciador de Tráfego do Azure é um balanceador de carga de tráfego com base em DNS que pode distribuir o tráfego de rede entre regiões. Use o Gerenciador de Tráfego para rotear os usuários com base no tempo de resposta do cluster ou com base na área geográfica.

AKS with Traffic Manager

Se tiver um único cluster do AKS, normalmente será conectado ao IP de serviço ou ao nome DNS de um determinado aplicativo. Em uma implantação com vários clusters, será necessário conectar a um nome DNS do Gerenciador de Tráfego que aponta para os serviços em cada cluster do AKS. Defina esses serviços usando os pontos de extremidade do Gerenciador de Tráfego. Cada ponto de extremidade é o IP do balanceador de carga do serviço. Usar essa configuração para direcionar o tráfego de rede do ponto de extremidade do Gerenciador de Tráfego em uma região para o ponto de extremidade em uma região diferente.

Geographic routing through Traffic Manager

O Gerenciador de Tráfego realiza pesquisas de DNS e retorna o ponto de extremidade mais adequado. Perfis aninhados podem priorizar um local primário. Por exemplo, é necessário conectar a região geográfica mais próxima. Se essa região apresentar algum problema, o Gerenciador de Tráfego direcionará para uma região secundária. Essa abordagem garante que será possível conectar-se a uma instância do aplicativo, mesmo se a região geográfica mais próxima estiver indisponível.

Para saber as informações sobre como configurar pontos de extremidade e roteamento, confira Configurar o método geográfico de roteamento de tráfego usando o Gerenciador de Tráfego.

Roteamento de aplicativo com o Azure Front Door Service

Usando o protocolo anycast baseado em TCP dividido, oAzure Front Door Service conecta imediatamente os usuários finais ao Front Door POP (Ponto de Presença) mais próximo. Mais recursos do Azure Front Door Service:

  • Encerramento de TLS
  • Domínio personalizado
  • Firewall do aplicativo Web
  • Regravação de URL
  • Afinidade de sessão

Examine as necessidades de seu tráfego de aplicativo para entender qual é a solução mais adequada.

Regiões de interconexão com emparelhamento de rede virtual global

Para habilitar a comunicação entre os clusters, conecte ambas as redes virtuais entre si por meio de emparelhamento de rede virtual. O emparelhamento de rede virtual interconecta redes virtuais, fornecendo alta largura de banda em toda a rede de backbone da Microsoft, mesmo em diferentes regiões geográficas.

Antes de fazer o emparelhamento de redes virtuais com os clusters do AKS em execução, use o Balanceador de Carga padrão no cluster do AKS. Esse pré-requisito torna os serviços do Kubernetes acessíveis por meio do emparelhamento de rede virtual.

Habilitar a replicação geográfica para imagens de contêiner

Prática recomendada

Armazene as imagens de contêiner no Registro de Contêiner do Azure e faça a replicação geográfica do registro para cada região AKS.

Para implantar e executar seus aplicativos no AKS, você precisará ter uma maneira de armazenar e efetuar pull das imagens de contêiner. O Registro de Contêiner pode se integrar ao AKS para que possa armazenar suas imagens de contêiner ou gráficos do Helm com segurança. O Registro de Contêiner dá suporte à replicação geográfica com vários mestres para replicar automaticamente suas imagens para regiões do Azure em todo o mundo.

Para melhorar o desempenho e a disponibilidade:

  1. Use a replicação geográfica do Registro de Contêiner para criar um registro em cada região onde há um cluster do AKS.
  2. Cada cluster do AKS efetua pull de imagens de contêiner do registro contêiner local na mesma região:

Container Registry geo-replication for container images

Ao usar a replicação geográfica do Registro de Contêiner para efetuar pull de imagens da mesma região, os resultados são:

  • Mais rápidos: extraia imagens de pull de rede de alta velocidade e baixa latência na mesma região do Azure.
  • Mais confiável: se uma região não estiver disponível, o cluster do AKS extrairá as imagens de um registro de contêiner disponível.
  • Mais baratos: sem encargo de saída de rede entre datacenters.

A replicação geográfica é um recurso de registro de contêiner de SKU Premium. Para obter informações sobre como configurar a replicação geográfica, consulte Replicação geográfica do Registro de Contêiner

Remover o estado do serviço de dentro dos contêineres

Prática recomendada

Não armazene o estado do serviço dentro do contêiner. Em vez disso, use uma plataforma como serviço (PaaS) do Azure com suporte para replicação multirregional.

Estado do serviço refere-se aos dados em disco ou na memória que um serviço requer para funcionar. O estado inclui as estruturas de dados e variáveis de membro que o serviço lê e grava. Dependendo de como o serviço é estruturado, o estado também pode incluir arquivos ou outros recursos armazenados no disco. Por exemplo, o estado pode incluir os arquivos que um banco de dados usa para armazenar os logs de transações e de registros.

O estado pode ser externalizado ou localizado junto com o código que manipula o estado. Normalmente, a externalização do estado é feita usando um banco de dados ou outro armazenamento de dados executado em máquinas diferentes na rede ou executado fora do processo no mesmo computador.

Os contêineres e microsserviços são mais resilientes quando os processos que são executados dentro deles não retêm o estado. Como os aplicativos quase sempre contêm algum estado, use uma solução de PaaS, como:

  • Azure Cosmos DB
  • Banco de Dados do Azure para PostgreSQL
  • Banco de Dados do Azure para MySQL
  • Banco de Dados SQL do Azure

Para criar aplicativos portáteis, confira as seguintes diretrizes:

Criar um plano de migração de armazenamento

Prática recomendada

Se usar o Armazenamento do Microsoft Azure, prepare e teste como migrar o armazenamento da região primária para a região de backup.

Os aplicativos podem usar o Armazenamento do Azure para seus dados. Nesse caso, os aplicativos estão distribuídos entre vários clusters do AKS em diferentes regiões. É necessário manter o armazenamento sincronizado. Seguem duas maneiras comuns de replicar o armazenamento:

  • Replicação assíncrona baseada em infraestrutura
  • Replicação assíncrona baseada em aplicativo

Replicação assíncrona baseada em infraestrutura

Seus aplicativos poderão exigir armazenamento persistente, mesmo depois de um pod ser excluído. No Kubernetes, você pode usar volumes persistentes para persistir dados de armazenamento. Esses volumes persistentes são montados na VM do nó e, em seguida, expostos aos pods. Volumes persistentes seguem os pods, mesmo quando os pods são movidos para um nó diferente dentro do mesmo cluster.

A estratégia de replicação usada depende da solução de armazenamento. As seguintes soluções de armazenamento comum fornecem suas próprias diretrizes sobre recuperação de desastre e replicação:

Normalmente, você fornece um ponto de armazenamento comum onde os aplicativos gravam os dados. Esses dados são replicados entre regiões e acessados localmente.

Infrastructure-based asynchronous replication

Se usar o Managed Disks do Azure, é possível usar oVelero no Azure e oKasten para processar a replicação e a recuperação de desastre. Essas opções são soluções de backup nativas, mas sem suporte pelo Kubernetes.

Replicação assíncrona baseada em aplicativo

Atualmente, o Kubernetes não oferece nenhuma implementação nativa para replicação assíncrona baseada em aplicativo. Como os contêineres e o Kubernetes são acoplados de forma flexível, os aplicativos tradicionais ou a abordagem de linguagem deve funcionar. Normalmente, os próprios aplicativos replicam as solicitações de armazenamento que são, então, gravadas no armazenamento de dados subjacente de cada cluster.

Application-based asynchronous replication

Próximas etapas

Este artigo aborda considerações de continuidade dos negócios e recuperação de desastres para clusters do AKS. Para obter mais informações sobre operações de cluster no AKS, consulte estes artigos sobre melhores práticas: