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

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 armazenam métricas de rede regionais e 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 ú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 do 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 experimente 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 um estiver indisponível, o tráfego será 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 for inativa, uma nova instância deverá ser recriada. As investigações de atividade podem verificar o estado do aplicativo ou o 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 uma nova instância.

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

Pods de aplicativo (global)

Quando uma região inteira ficar indisponível, os pods no cluster não estarão mais disponíveis para atender às solicitações. Nesse caso, a instância do Azure Front Door roteará todo o tráfego para as regiões de integridade restantes. Os clusters e pods do Kubernetes nessas regiões continuam a atender à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 computação estão do tamanho certo 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 pode dar suporte a todos os IPs de pod com uma carga de tráfego com pico.
• 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 as contagens de nós de instância do Kubernetes para compensar o aumento da demanda regional.

Pools de nós do Kubernetes (Regional)

Ocasionalmente, pode ocorrer falha localizada em recursos de computação, como a energia ficando indisponível em um único rack de servidores do Azure. Para proteger os nós do AKS de se tornarem uma falha regional de ponto único, use Zonas de Disponibilidade do Azure. As zonas de disponibilidade garantem que os nós do AKS em cada zona de disponibilidade sejam 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 íntegras 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 haja mecanismos disponíveis atualmente no AKS para derrubar uma região inteira da implantação para fins de teste, o Azure Chaos Studio oferece a capacidade de criar um experimento de caos em seu cluster.

Próximas etapas

Se você estiver considerando uma solução diferente, consulte 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)