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

Quando você cria um aplicativo no AKS e escolhe uma região do Azure durante a criação de recursos, ele é um aplicativo de região única. Quando a região fica indisponível durante um desastre, seu aplicativo também fica 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.

Este guia descreve uma solução de recuperação de desastre ativa-passiva para o AKS. Nessa solução, implantamos dois clusters do AKS independentes e idênticos em duas regiões emparelhadas do Azure com apenas um cluster atendendo ativamente ao tráfego.

Observação

A prática a seguir foi revisada internamente e examinada em conjunto com nossos parceiros da Microsoft.

Visão geral da solução ativa-passiva

Nessa abordagem de recuperação de desastre, temos dois clusters independentes do AKS sendo implantados em duas regiões do Azure. No entanto, apenas um dos clusters está atendendo ativamente o tráfego a todo momento. O cluster secundário (que não está atendendo ativamente o tráfego) contém a mesma configuração e dados de aplicativo que o cluster primário, mas não aceita nenhum tráfego, a menos que seja direcionado pelo gerenciador de tráfego do Azure Front Door.

Cenários e configurações

Essa solução é melhor implementada ao hospedar aplicativos dependentes de recursos, como bancos de dados, que atendem ativamente o tráfego em uma região. Em cenários em que é necessário hospedar aplicativos sem estado implantados nas duas regiões, como a escala horizontal, é recomendável considerar uma solução ativa-ativa, pois a ativa-passiva envolve latência adicional.

Componentes

A solução de recuperação de desastre ativa-passiva usa muitos serviços do Azure. Esta arquitetura de exemplo envolve os seguintes componentes:

Vários clusters e regiões: você implanta vários clusters do AKS, cada um em uma região separada do Azure. Durante as operações normais, o tráfego de rede é roteado para o cluster primário do AKS definido na configuração do Azure Front Door.

Priorização de cluster configurada: você define um nível de priorização entre 1 e 5 para cada cluster (sendo 1 a prioridade mais alta e 5 sendo a prioridade mais baixa). Você pode definir vários clusters para o mesmo nível de prioridade e especificar o peso de cada cluster. Se o cluster primário ficar indisponível, o tráfego será roteado automaticamente para a próxima região selecionada no Azure Front Door. Todo o tráfego deve passar pelo Azure Front Door para que esse sistema funcione.

Azure Front Door: o Azure Front Door balanceia a carga e roteia o tráfego para a instância do Gateway de Aplicativo do Azure na região primária (o cluster deve ser marcado com prioridade 1). No caso de uma falha na região, o serviço redireciona o tráfego para o próximo cluster na lista de prioridades.

Para obter mais informações, consulte Roteamento de tráfego com base em prioridade.

Par hub-spoke: um par hub-spoke é implantado para cada instância regional do AKS. As políticas do Gerenciador de Firewall do Azure gerenciam as regras de firewall em cada região.

Key Vault: você provisiona um Azure Key Vault em cada região para armazenar segredos e chaves.

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 (regionais)

Um objeto de implantação do Kubernetes cria várias réplicas de um pod (ReplicaSet). Se uma delas não está disponível, o tráfego é roteado 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. As investigações de atividade podem verificar o estado do aplicativo ou do processo em execução no pod. Se o pod não responder, a investigação de atividade removerá o pod, o que força o ReplicaSet a criar outra instância.

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

Pods de aplicativo (globais)

Quando uma região inteira fica indisponível, os pods no cluster não estão mais disponíveis para atender às solicitações. Nesse caso, a instância do Azure Front Door roteia todo o tráfego para as regiões íntegras restantes. Os clusters e os pods do Kubernetes nessas regiões continuam atendendo às 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 de computação têm o tamanho certo para absorver qualquer aumento repentino no tráfego devido ao failover de região. Por exemplo, ao usar a CNI (Adaptador de Rede de Contêiner) do Azure, verifique se você tem uma sub-rede que pode dar suporte a todos os IPs do pod com uma carga de tráfego em pico.
• Use o Dimensionador Automático de Pod Horizontal para aumentar a contagem de réplicas de pod, a fim de compensar o aumento da demanda regional.
• Use o Dimensionador Automático de Cluster do AKS para aumentar a contagem 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, uma falha localizada pode ocorrer para calcular recursos, por exemplo, a energia fica indisponível para um só rack de servidores do Azure. Para proteger os nós do AKS de se tornarem uma falha regional de ponto único, use as Zonas de Disponibilidade do Azure. As zonas de disponibilidade garantirão que os nós do AKS em cada zona de disponibilidade estejam fisicamente separados daqueles definidos em outras zonas de disponibilidades.

Pools de nós do Kubernetes (globais)

Em uma falha regional completa, o Azure Front Door roteia o tráfego para as regiões íntegras restantes. Novamente, lembre-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 haja mecanismos atualmente disponíveis no AKS para interromper uma região inteira da implantação para fins de teste, o Azure Chaos Studio oferece a capacidade de criar um teste de caos no seu cluster.

Próximas etapas

Se você estiver considerando o uso de outra solução, confira os seguintes artigos:

• Visão geral da solução de alta disponibilidade ativa-ativa 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)