Modelos de implantação de várias regiões para o AKS (Serviço de Kubernetes do Azure)

O AKS (Serviço de Kubernetes do Azure) fornece um ambiente gerenciado do Kubernetes para implantar, gerenciar e dimensionar aplicativos em contêineres. Para fornecer resiliência a interrupções regionais para seus aplicativos em execução no AKS, você pode implementar vários modelos de implantação de várias regiões. Este artigo fornece uma visão geral desses modelos, seus prós e contras e práticas recomendadas para manter o tempo de atividade do aplicativo.

O AKS fornece uma variedade de recursos que dão suporte a ALTA DISPONIBILIDADE (HA) e recuperação de desastre (DR) para o cluster e os aplicativos em execução no AKS. Para obter mais informações sobre como o AKS dá suporte a requisitos de confiabilidade, consulte Confiabilidade no AKS.

Considerações

Abaixo estão algumas considerações importantes ao implementar modelos de implantação de várias regiões no AKS:

Recursos regionais e globais

Os recursos regionais são provisionados como parte de um selo de implantação em uma única região do Azure. Esses recursos são independentes dos recursos de outras regiões e podem ser removidos ou replicados para outras regiões, se necessário. Para saber mais, confira Recursos reginais.

Os recursos globais compartilham o tempo de vida do sistema e podem ficar disponíveis globalmente no contexto de uma implantação em várias regiões. Para saber mais, confira Recursos globais.

Balanceamento de carga global

Os serviços de balanceamento de carga global distribuem o tráfego por back-ends regionais, nuvens ou serviços híbridos locais. Esses serviços roteiam o tráfego do usuário final para o back-end disponível mais próximo. Eles também se adaptam a alterações na confiabilidade ou no desempenho dos serviços para otimizar a disponibilidade e o desempenho. Os seguintes serviços do Azure oferecem balanceamento de carga global:

• Azure Front Door
• Gerenciador de Tráfego do Azure
• Azure Load Balancer entre regiões
• Gerenciador de Frota de Kubernetes do Azure

Definição do escopo

A disponibilidade dos aplicativos é crucial no gerenciamento de clusters do AKS. Por padrão, o AKS fornece alta disponibilidade usando vários nós em um conjunto de dimensionamento de máquinas virtuais, mas esses nós não protegem seu sistema de uma falha na 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 desastre usando as melhores práticas a seguir:

• 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.

Implementações de modelo de implantação de várias regiões

A tabela a seguir resume os três principais modelos de implantação de várias regiões no AKS, juntamente com seus prós e contras:

Modelos de implantação ativo-ativo de alta disponibilidade

No modelo de implantação ativo-ativo de alta disponibilidade (HA), você conta com dois clusters do AKS independentes, situados em duas regiões diferentes do Azure (geralmente regiões pareadas, como Canadá Central e Leste do Canadá ou Leste dos EUA 2 e EUA Central), ambos atendendo tráfego ativamente.

Com este exemplo de arquitetura:

• Você configura dois clusters do AKS em regiões distintas do Azure.
• Durante as operações normais, o tráfego de rede é roteado entre as duas as regiões. Se uma região ficar indisponível, o tráfego será automaticamente roteado para uma região mais próxima do usuário que emitiu a solicitação.
• Cada instância regional do AKS possui um par de conexões hub-spoke. As políticas do Gerenciador de Firewall do Azure gerenciam as regras de firewall entre as regiões.
• O Azure Key Vault é provisionado em cada região para armazenar segredos e chaves.
• O Azure Front Door balanceia a carga e roteia o tráfego para uma instância regional do Gateway de Aplicativo do Azure, que protege cada cluster do AKS.
• As instâncias regionais do Log Analytics são usadas para armazenar as métricas de rede regionais e os logs de diagnóstico.
• As imagens de contêiner da carga de trabalho são armazenadas em um registro de contêiner gerenciado. Um único Registro de Contêiner do Azure é usado para todas as instâncias do Kubernetes no cluster. A replicação geográfica do Registro de Contêiner do Azure permite a replicação das imagens nas regiões selecionadas do Azure e fornece acesso contínuo às imagens, mesmo que uma região enfrente uma interrupção.

Para estabelecer um modelo de implantação ativo-ativo no AKS, siga estes passos:

1. Crie duas implantações idênticas em regiões diferentes do Azure.

2. Criar duas instâncias do seu aplicativo web.

3. Crie um perfil no Azure Front Door com os seguintes recursos:

   • Um ponto de extremidade.
   • Dois grupos de origem, cada um com uma prioridade de one.
   • Uma rota.

4. Limite o tráfego de rede para os aplicativos Web somente da instância do Azure Front Door. 5 Configure todos os outros serviços de back-end do Azure, como bancos de dados, contas de armazenamento e provedores de autenticação.

5. Faça a implantação do código em ambos os aplicativos web de forma contínua.

Para mais informações, confira a Visão geral recomendada para solução de alta disponibilidade ativo-ativo no AKS.

Modelo de implantação de recuperação de desastre ativo-passivo

No modelo de implantação ativo-passivo de recuperação de desastres (DR), você conta com dois clusters do AKS independentes, situados em duas regiões diferentes do Azure (geralmente regiões pareadas, como Canadá Central e Leste do Canadá ou Leste dos EUA 2 e EUA Central), ambos atendendo tráfego ativamente. Apenas um dos clusters atende ativamente o tráfego a todo momento. O outro cluster possui a mesma configuração e dados do aplicativo que o cluster ativo, mas só recebe tráfego quando direcionado por um gerenciador de tráfego.

Com este exemplo de arquitetura:

• Você configura dois clusters do AKS em regiões distintas do Azure.
• Em condições normais de operação, o tráfego de rede é direcionado para o cluster do AKS principal, conforme definido nas configurações do Azure Front Door.
  • A prioridade deve ser estabelecida entre 1–5, sendo 1 a mais alta e 5 a mais baixa.
  • Você pode definir vários clusters para o mesmo nível de prioridade e pode especificar o peso de cada um.
• Se o cluster primário ficar indisponível (em caso de desastre), o tráfego será roteado automaticamente para a próxima região selecionada no Azure Front Door.
  • Todo o tráfego precisa passar pelo gerenciador de tráfego do Azure Front Door para que o sistema funcione corretamente.
• O Azure Front Door roteia o tráfego para o Gateway de Aplicativo do Azure na região principal (o cluster deve estar marcado com prioridade 1). Se essa região falhar, o serviço redirecionará o tráfego para o próximo cluster na lista de prioridades, seguindo as regras estabelecidas pelo Azure Front Door.
  • As regras vêm do Azure Front Door.
• Um par hub-spoke é implantado em cada instância regional do AKS. As políticas do Gerenciador de Firewall do Azure gerenciam as regras de firewall entre as regiões.
• O Azure Key Vault é provisionado em cada região para armazenar segredos e chaves.
• As instâncias regionais do Log Analytics são usadas para armazenar as métricas de rede regionais e os logs de diagnóstico.
• As imagens de contêiner da carga de trabalho são armazenadas em um registro de contêiner gerenciado. Um único Registro de Contêiner do Azure é usado para todas as instâncias do Kubernetes no cluster. A replicação geográfica do Registro de Contêiner do Azure permite a replicação das imagens nas regiões selecionadas do Azure e fornece acesso contínuo às imagens, mesmo que uma região enfrente uma interrupção.

Para estabelecer um modelo de implantação ativo-pasivo no AKS, siga estes passos:

1. Crie duas implantações idênticas em regiões diferentes do Azure.

2. Configure regras de dimensionamento automático para o aplicativo secundário, de modo que ela escale para o mesmo número de instâncias do aplicativo primário quando a região primária estiver inativa. Enquanto estiver inativa, não é necessário escalar, o que contribui para a redução de custos. Isso ajuda a reduzir os custos.

3. Crie duas instâncias do seu aplicativo web, com uma em cada cluster.

4. Crie um perfil no Azure Front Door com os seguintes recursos:

   • Um ponto de extremidade.
   • Um grupo de origem com prioridade de um para a região primária.
   • Um segundo grupo de origem com prioridade de dois para a região secundária.
   • Uma rota.

5. Restrinja o tráfego de rede dos aplicativos web somente por meio da instância do Azure Front Door.

6. Configure todos os outros serviços de back-end do Azure, como bancos de dados, contas de armazenamento e provedores de autenticação.

7. Implante o código em ambos os aplicativos web com implantação contínua.

Para mais informações, confira a Visão geral recomendada para solução de recuperação de desastre ativa-passiva no AKS.

Modelo de implantação passivo-frio

O modelo de implantação de failover passivo-frio é configurado da mesma maneira que o modelo de recuperação de desastres ativo-passivo, exceto que os clusters permanecem inativos até que um usuário os ative em caso de desastre. Consideramos essa abordagem fora do escopo porque envolve uma configuração semelhante ao modelo ativo-passivo, porém é mais complexa por causa da intervenção manual para ativar o cluster e acionar um backup.

Com este exemplo de arquitetura:

• Você cria dois clusters do AKS, preferencialmente em regiões ou zonas diferentes para melhor resiliência.
• Quando precisar fazer failover, ative a implantação para assumir o fluxo de tráfego.
• Caso o cluster passivo primário fique inoperante, você precisará ativar manualmente o cluster frio para assumir o fluxo de tráfego.
• Essa condição precisa ser definida por uma entrada manual todas as vezes ou por um evento específico, conforme especificado por você.
• O Azure Key Vault é provisionado em cada região para armazenar segredos e chaves.
• As instâncias regionais do Log Analytics são usadas para armazenar as métricas de rede regionais e os logs de diagnóstico de cada cluster.

Para estabelecer um modelo de implantação de failover passivo-frio no AKS, siga estes passos:

1. Crie duas implantações idênticas em zonas/regiões diferentes.
2. Configure regras de dimensionamento automático para o aplicativo secundário, de modo que ela escale para o mesmo número de instâncias do aplicativo primário quando a região primária estiver inativa. Enquanto inativa, ela não precisa ser escalada, o que ajuda a reduzir custos.
3. Crie duas instâncias do seu aplicativo web, com uma em cada cluster.
4. Configure todos os outros serviços de back-end do Azure, como bancos de dados, contas de armazenamento e provedores de autenticação.
5. Defina uma condição para acionar o cluster frio. Se necessário, utilize um balanceador de carga.

Para mais informações, veja a Visão geral recomendada para solução de failover passivo-frio no AKS.

Para obter mais informações, consulte os seguintes artigos:

• Confiabilidade no AKS
• Sobre o backup do AKS usando o Backup do Azure (em versão prévia)
• Fazer backup do AKS usando o Backup do Azure (em versão prévia)
• Continuidade dos negócios, alta disponibilidade e recuperação de desastres