Visão geral da solução de alta disponibilidade ativa-ativa recomendada para o Serviço Kubernetes do Azure (AKS)

Quando você cria um aplicativo no Serviço Kubernetes do Azure (AKS) e escolhe uma região do Azure durante a criação de recursos, é um aplicativo de região única. No caso de um desastre que faça com que a região fique indisponível, seu aplicativo também fica indisponível. Se você criar uma implantação idêntica em uma região secundária do Azure, seu aplicativo ficará menos suscetível a um desastre de região única, o que garante a continuidade dos negócios, e qualquer replicação de dados entre as regiões permitirá recuperar o estado do último aplicativo.

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

Nota

O seguinte caso de uso pode ser considerado prática padrão dentro do AKS. Ele foi revisado internamente e aprovado em conjunto com nossos parceiros da Microsoft.

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

Esta solução baseia-se em dois clusters AKS idênticos configurados para servir ativamente o tráfego. Você coloca um gerenciador de tráfego global, como o Azure Front Door, na frente dos dois clusters para distribuir o tráfego entre eles. Você deve configurar consistentemente os clusters para hospedar uma instância de todos os aplicativos necessários para que a solução funcione.

As zonas de disponibilidade são outra maneira de garantir alta disponibilidade e tolerância a falhas para seu cluster AKS dentro da mesma região. As zonas de disponibilidade permitem que você distribua seus nós de cluster em vários locais isolados dentro de uma região do Azure. Desta forma, se uma zona ficar inativa devido a uma falha de energia, falha de hardware ou problema de rede, o cluster pode continuar a ser executado e servir as suas aplicações. As zonas de disponibilidade também melhoram o desempenho e a escalabilidade do cluster, reduzindo a latência e a contenção entre nós. Para configurar zonas de disponibilidade para seu cluster AKS, você precisa especificar os números de zona ao criar ou atualizar seus pools de nós. Para obter mais informações, consulte O que são zonas de disponibilidade do Azure?

Nota

Muitas regiões suportam zonas de disponibilidade. Considere o uso de regiões com zonas de disponibilidade para fornecer mais resiliência e disponibilidade para suas cargas de trabalho. Para obter mais informações, consulte Recuperar de uma interrupção de serviço em toda a região.

Cenários e configurações

Essa solução é melhor implementada ao hospedar aplicativos sem estado e/ou com outras tecnologias também implantadas em ambas as regiões, como o dimensionamento horizontal. Em cenários em que o aplicativo hospedado depende de recursos, como bancos de dados, que estão ativamente em apenas uma região, recomendamos a implementação de uma solução ativo-passivo para economia de custos potencial, já que o ativo-passivo tem mais tempo de inatividade do que o ativo-ativo.

Componentes

A solução de alta disponibilidade ativo-ativo usa muitos serviços do Azure. Esta seção aborda apenas os componentes exclusivos dessa arquitetura multicluster. Para obter mais informações sobre os componentes restantes, consulte a arquitetura de linha de base do AKS.

Vários clusters e regiões: você implanta vários clusters AKS, cada um em uma região separada do Azure. Durante as operações normais, a configuração do Azure Front Door roteia o tráfego de rede entre todas as regiões. Se uma região ficar indisponível, o tráfego será encaminhado para uma região com o tempo de carregamento mais rápido para o usuário.

Rede hub-spoke por região: um par de rede hub-spoke regional é implantado para cada instância regional do AKS. As políticas do Azure Firewall Manager gerenciam as políticas de firewall em todas as regiões.

Armazenamento de chaves regionais: você provisiona o Azure Key Vault em cada região para armazenar valores confidenciais e chaves específicas para a instância do AKS e para dar suporte aos serviços encontrados nessa região.

Azure Front Door: o Azure Front Door equilibra a carga e encaminha o tráfego para uma instância regional do Azure Application Gateway , que fica na frente de cada cluster AKS. O Azure Front Door permite o roteamento global da camada sete .

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

Registro de contêiner: as imagens de contêiner para a carga de trabalho são armazenadas em um registro de contêiner gerenciado. Com essa solução, uma única instância do Registro de Contêiner do Azure é usada para todas as instâncias do Kubernetes no cluster. A replicação geográfica para o Registro de Contêiner do Azure permite replicar imagens para as regiões selecionadas do Azure e fornece acesso contínuo às imagens, mesmo que uma região sofra uma interrupção.

Processo de failover

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

Pods de Aplicação (Regional)

Um objeto de implantação do Kubernetes cria várias réplicas de um pod (ReplicaSet). Se uma não estiver disponível, o tráfego será roteado entre as réplicas restantes. O Kubernetes ReplicaSet tenta manter o número especificado de réplicas em funcionamento. Se uma instância ficar inativa, uma nova instância deverá ser recriada. As sondas Liveness podem verificar o estado do aplicativo ou processo em execução no pod. Se o pod não estiver respondendo, o teste de vivacidade removerá 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 não estão mais disponíveis para atender solicitações. Nesse caso, a instância do Azure Front Door roteia todo o tráfego para as regiões de integridade restantes. Os clusters e pods do Kubernetes nessas regiões continuam a atender solicitações. Para compensar o aumento do tráfego e das solicitações para o cluster restante, lembre-se das seguintes orientações:

• Certifique-se de que os recursos de rede e computação estão dimensionados corretamente para absorver qualquer aumento repentino no tráfego devido ao failover de região. Por exemplo, ao usar a CNI (Interface de Rede de Contêiner) do Azure, verifique se você tem uma sub-rede que possa dar suporte a todos os IPs de pod com uma carga de tráfego aumentada.
• Use o Horizontal Pod Autoscaler para aumentar a contagem de réplicas de pods para compensar o aumento da demanda regional.
• Use o AKS Cluster Autoscaler para aumentar as contagens de nó de instância do Kubernetes para compensar o aumento da demanda regional.

Pools de nós do Kubernetes (Regional)

Ocasionalmente, podem ocorrer falhas localizadas em recursos de computação, como a indisponibilidade de energia em um único rack de servidores do Azure. Para proteger seus nós AKS de se tornarem uma falha regional de ponto único, use as Zonas de Disponibilidade do Azure. As zonas de disponibilidade garantem que os nós AKS em cada zona de disponibilidade estejam fisicamente separados daqueles definidos em outras zonas de disponibilidade.

Pools de nós do Kubernetes (Global)

Em uma falha regional completa, o Azure Front Door roteia o tráfego para as regiões saudáveis restantes. Novamente, certifique-se de compensar o aumento do tráfego e das solicitações para o cluster restante.

Estratégia de teste de failover

Embora não existam mecanismos atualmente disponíveis no AKS para derrubar uma região inteira de implantação para fins de teste, o Azure Chaos Studio oferece a capacidade de criar um experimento de caos em seu cluster.

Próximos passos

Se você estiver considerando uma solução diferente, consulte os seguintes artigos:

• Visão geral da solução de recuperação de desastres passiva ativa para o Serviço Kubernetes do Azure (AKS)
• Visão geral da solução de frio passivo para o Serviço Kubernetes do Azure (AKS)