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

Quando você cria um aplicativo no AKS (Serviço de Kubernetes do Azure) e escolhe uma região do Azure durante a criação de recursos, ele é 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 ficará indisponível. Se você criar uma implantação idêntica em uma região secundária do Azure, o aplicativo ficará menos suscetível a um desastre em uma só região, garantindo a continuidade dos negócios. Além disso, a replicação de dados entre as regiões permite que você recupere o último estado de aplicativo.

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

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

Esta solução depende de dois clusters do AKS idênticos configurados para atender ativamente ao tráfego. Você posiciona um gerenciador de tráfego global, como o Azure Front Door, à frente dos dois clusters para distribuir o tráfego entre eles. É preciso configurar os clusters de maneira consistente 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 o cluster do AKS na mesma região. As zonas de disponibilidade permitem distribuir os nós de cluster em vários locais isolados em uma região do Azure. Dessa forma, se uma zona ficar inoperante devido a uma interrupção de energia, falha de hardware ou problema de rede, o cluster poderá continuar sendo executado e atendendo aos seus aplicativos. As zonas de disponibilidade também aprimoram o desempenho e a escalabilidade do cluster, reduzindo a latência e a contenção entre os nós. Para configurar zonas de disponibilidade para o cluster do AKS, você precisa especificar os números de zona ao criar ou atualizar os pools de nós. Para saber mais, veja O que são as zonas de disponibilidade do Azure?

Cenários e configurações

Essa solução é mais bem implementada durante a hospedagem de aplicativos sem estado e/ou com outras tecnologias também implantadas nas duas regiões, como a escala 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 implementar uma solução ativa-passiva para possíveis economias de custos, pois a opção ativa-passiva tem mais tempo de inatividade do que a ativa-ativa.

Componentes

A solução de alta disponibilidade ativa-ativa usa vários serviços do Azure. Esta seção aborda apenas os componentes exclusivos dessa arquitetura de vários clusters. Para obter mais informações sobre os componentes restantes, veja a arquitetura de linha de base do AKS.

Vários clusters e regiões: você implanta vários clusters do AKS, cada um em uma região separada do Azure. Durante 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á roteado 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 redes hub-spoke regional é implantado para cada instância regional do AKS. As políticas do Gerenciador de Firewall do Azure gerenciam as políticas de firewall em todas as regiões.

Repositório de chaves regionais: você provisiona o Azure Key Vault em cada região para armazenar valores confidenciais e chaves específicas da instância do AKS e dos serviços de suporte encontrados nessa região.

Azure Front Door: O Azure Front Door faz o balanceamento de carga e roteia o tráfego para uma instância regional do Gateway de Aplicativo do Azure, que fica na frente de cada cluster do AKS. O Azure Front Door permite o roteamento global de camada sete.

Log Analytics: as instâncias regionais do Log Analytics são usadas para armazenar as métricas de rede regionais e os logs de diagnóstico. Uma instância compartilhada armazena as métricas e os logs de diagnóstico para todas as instâncias do AKS.

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

Processo de failover

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

Pods de Aplicativo (Regional)

Um objeto de implantação do Kubernetes cria várias réplicas de um pod (ReplicaSet). Se uma delas estiver indisponível, o tráfego é redirecionado entre as réplicas restantes. O ReplicaSet do Kubernetes tenta manter o número especificado de réplicas em funcionamento. Se uma instância ficar inoperante, uma nova instância deverá ser recriada. Sondas de liveness podem verificar o estado da aplicação ou do processo em execução no pod. Se o pod não estiver respondendo, a sonda de liveness remove o pod, o que força o ReplicaSet a criar uma nova instância.

Para obter mais informações, confira ReplicaSet de Kubernetes.

Pods de aplicativo (global)

Quando uma região inteira fica indisponível, os pods do cluster não estão mais disponíveis para atender às solicitações. Nesse caso, a instância do Azure Front Door direciona todo o tráfego para as demais regiões saudáveis. 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, tenha em mente as seguintes diretrizes:

• Verifique se os recursos de rede e computacionais estão dimensionados corretamente para absorver qualquer aumento repentino no tráfego devido ao failover regional. Por exemplo, ao usar o Azure Container Network Interface (CNI), certifique-se de que haja uma sub-rede que possa dar suporte a todos os endereços IP dos pods durante um pico de tráfego.
• Use o Dimensionador Automático de Pod Horizontal para aumentar a contagem de réplicas de pod para compensar o aumento da demanda regional.
• Use o Dimensionador automático de cluster do AKS para aumentar o número de nós da instância do Kubernetes, a fim de compensar o aumento da demanda regional.

Pools de nós do Kubernetes (regionais)

Ocasionalmente, pode ocorrer uma falha localizada nos recursos de computação, como a indisponibilidade de energia em um único rack de servidores do Azure. Para evitar que os nós do AKS nesta solução ativa-ativa se tornem um ponto único de falha regional, use Azure Zonas de Disponibilidade. As zonas de disponibilidade garantem que os nós do AKS em cada zona de disponibilidade sejam fisicamente separados daqueles definidos em outra zona de disponibilidade.

Pools de nós do Kubernetes (globais)

Em uma falha total de uma região, o Azure Front Door roteia o tráfego para as regiões saudáveis restantes. Novamente, certifique-se de levar em conta o aumento do tráfego e das requisições no cluster restante.

Estratégia de testes de failover

Embora atualmente não existam mecanismos no AKS para tirar do ar uma região inteira de implantação para fins de teste, você pode usar Azure Chaos Studio Workspaces para simular uma falha em uma zona de disponibilidade nos pools de nós do cluster.

Próximas etapas

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

• Visão geral da solução de recuperação de desastre ativa-passiva para o AKS (Serviço de Kubernetes do Azure)
• Visão geral da solução passiva-fria para o AKS (Serviço de Kubernetes do Azure)