Visão geral recomendada da solução de elevada disponibilidade ativa-ativa para o Azure Kubernetes Service (AKS)

Quando crias uma aplicação no Azure Kubernetes Service (AKS) e escolhes uma região do Azure durante a criação de recursos, é uma aplicação de uma única região. No caso de um desastre que torne a região indisponível, a sua candidatura também se torna indisponível. Se criar uma implementação idêntica numa região secundária do Azure, a sua aplicação torna-se menos suscetível a um desastre numa única região, o que garante a continuidade do negócio, e qualquer replicação de dados entre as regiões permite-lhe recuperar o estado da sua última aplicação.

Embora existam vários padrões que podem proporcionar capacidade de recuperação a uma solução AKS, este guia descreve a solução recomendada de alta disponibilidade ativa-ativa para o AKS. Dentro desta solução, implementamos dois clusters AKS independentes e idênticos em duas regiões Azure emparelhadas, com ambos os clusters a servir ativamente o tráfego.

Nota

O seguinte caso de uso pode ser considerado prática padrão dentro do AKS. Foi revisto internamente e avaliado em conjunto com os nossos parceiros da Microsoft.

Visão geral da solução ativo-ativo de alta disponibilidade

Esta solução baseia-se em dois clusters AKS idênticos configurados para servir ativamente o tráfego. Colocas um gestor global de tráfego, como o Azure Front Door, à frente dos dois clusters para distribuir o tráfego entre eles. Deve configurar consistentemente os clusters para alojar uma instância de todas as aplicações necessárias para o funcionamento da solução.

As zonas de disponibilidade são outra forma de garantir alta disponibilidade e tolerância a falhas para o seu cluster AKS dentro da mesma região. As zonas de disponibilidade permitem-lhe distribuir os nós do cluster por múltiplos locais isolados dentro de uma região Azure. Desta forma, se uma zona cair devido a uma falha de energia, falha de hardware ou problema de rede, o seu cluster pode continuar a funcionar e a servir as suas aplicações. As zonas de disponibilidade também melhoram o desempenho e a escalabilidade do seu cluster, ao reduzirem a latência e a contenção entre nós. Para configurar zonas de disponibilidade para o seu cluster AKS, precisa de especificar os números de zona ao criar ou atualizar os seus pools de nós. Para mais informações, veja Quais são as zonas de disponibilidade do Azure?

Nota

Muitas regiões suportam zonas de disponibilidade. Considere usar regiões com zonas de disponibilidade para proporcionar mais resiliência e disponibilidade para as suas cargas de trabalho. Para mais informações, consulte Recuperar de uma interrupção de serviço a nível regional.

Cenários e configurações

Esta solução é melhor implementada ao alojar aplicações sem estado e/ou com outras tecnologias também implementadas em ambas as regiões, como a escalabilidade horizontal. Em cenários em que a aplicação alojada depende de recursos, como bases de dados, que estão ativas apenas numa região, recomendamos, em vez disso, implementar uma solução ativa-passiva para uma potencial redução de custos, uma vez que a arquitetura ativa-passiva implica mais tempo de inatividade do que a ativa-ativa.

Componentes

A solução de alta disponibilidade ativa-ativa utiliza muitos serviços do Azure. Esta secção cobre apenas os componentes únicos desta arquitetura multi-cluster. Para mais informações sobre os componentes restantes, consulte a arquitetura base do AKS.

Múltiplos clusters e regiões: Implementas múltiplos clusters AKS, cada um numa região Azure separada. Durante as operações normais, a configuração do Azure Front Door encaminha o tráfego de rede entre todas as regiões. Se uma região ficar indisponível, o tráfego encaminha para uma região com o tempo de carregamento mais rápido para o utilizador.

Rede hub-and-spoke por região: É implementado um par regional de redes hub-and-spoke para cada instância regional do AKS. As políticas do Azure Firewall Manager gerem as políticas de firewall em todas as regiões.

Armazenamento regional de chaves: Provisiona o Azure Key Vault em cada região para armazenar valores e chaves sensíveis específicos da instância AKS e para suportar serviços encontrados nessa região.

Azure Front Door: O Azure Front Door equilibra o carregamento e encaminha o tráfego para uma instância regional do Gateway de Aplicação do Azure, que se situa em frente a cada cluster AKS. Azure Front Door permite o encaminhamento global de camada sete.

Log Analytics: As instâncias regionais de Log Analytics armazenam métricas de rede regional e registos de diagnóstico. Uma instância partilhada armazena métricas e registos de diagnóstico para todas as instâncias do AKS.

Registo de Contentores: As imagens dos contentores para a carga de trabalho são armazenadas num registo de contentores gerido. Com esta solução, uma única instância do Azure Container Registry é usada para todas as instâncias Kubernetes no cluster. A geo-replicação para o Azure Container Registry permite replicar imagens para as regiões selecionadas do Azure e proporciona acesso contínuo às imagens mesmo que uma região sofra uma falha.

Processo de failover

Se um serviço ou componente de serviço ficar indisponível numa região, o tráfego deve ser encaminhado para uma região onde esse serviço está disponível. Uma arquitetura de várias regiões inclui muitos pontos de falha diferentes. Nesta secção, abordamos os potenciais pontos de falha.

Pods de Aplicação (Regionais)

Um objeto de implementação Kubernetes cria múltiplas réplicas de um pod (ReplicaSet). Se uma não estiver disponível, o tráfego é encaminhado entre as réplicas restantes. O Kubernetes ReplicaSet tenta manter o número especificado de réplicas em funcionamento. Se uma instância falhar, uma nova instância deve ser recriada. As sondas Liveness podem verificar o estado da aplicação ou processo a correr no pod. Se o pod não estiver a responder, a sonda de atividade remove o pod, o que força o ReplicaSet a criar uma nova instância.

Para obter mais informações, consulte Kubernetes ReplicaSet.

Pods de Aplicação (Global)

Quando uma região inteira fica indisponível, os pods no cluster deixam de estar disponíveis para processar solicitações. Neste caso, a instância Azure Front Door encaminha todo o tráfego para as restantes regiões de saúde. Os clusters e pods do Kubernetes nestas regiões continuam a processar pedidos. Para compensar o aumento do tráfego e dos pedidos para o cluster remanescente, tenha em mente as seguintes orientações:

  • Certifique-se de que os recursos de rede e computação têm o tamanho adequado para absorver qualquer aumento súbito de tráfego devido ao failover regional. Por exemplo, ao usar o Azure Container Network Interface (CNI), certifique-se de que tem uma sub-rede que consiga suportar todos os endereços IP dos pods durante picos de tráfego.
  • Utilize o Horizontal Pod Autoscaler para aumentar o número de réplicas dos pods, de modo a compensar o aumento da procura regional.
  • Use o AKS Cluster Autoscaler para aumentar o número de nós de instância Kubernetes e compensar a maior procura regional.

Conjuntos de nós do Kubernetes (Regional)

Por vezes, pode ocorrer falha localizada nos recursos de cálculo, como a falta de energia num único rack de servidores Azure. Para evitar que os seus nós do AKS nesta solução ativo-ativo se tornem um ponto único de falha regional, utilize Azure Zonas de Disponibilidade. As zonas de disponibilidade garantem que os nós AKS em cada zona de disponibilidade estão fisicamente separados daqueles definidos noutra zona de disponibilidade.

Conjuntos de nós do Kubernetes (Global)

Num completo fracasso regional, o Azure Front Door encaminha o tráfego para as regiões restantes saudáveis. Mais uma vez, certifique-se de compensar o aumento do tráfego e dos pedidos para o cluster restante.

Estratégia de testes de failover

Embora atualmente não existam mecanismos dentro do AKS para reduzir toda uma região de implementação para fins de teste, pode usar os Workspaces do Azure Chaos Studio para simular uma falha na zona de disponibilidade para os pools de nós do seu cluster.

Passos seguintes

Se está a considerar uma solução diferente, consulte os seguintes artigos:

  • Última atualização a