Visão geral da solução de recuperação de desastres ativo-passivo 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. 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, 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.

Este guia descreve uma solução de recuperação de desastres ativo-passivo para o AKS. Nesta solução, implementamos dois clusters AKS independentes e idênticos em duas regiões emparelhadas do Azure com apenas um cluster a servir ativamente o tráfego.

Nota

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

Visão geral da solução ativo-passivo

Nesta abordagem de recuperação de desastres, temos dois clusters AKS independentes sendo implantados em duas regiões do Azure. No entanto, apenas um dos clusters está servindo ativamente o tráfego de cada vez. O cluster secundário (que não serve ativamente o tráfego) contém a mesma configuração e os mesmos 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 da Porta da Frente do Azure.

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 você precisa hospedar aplicativos sem monitoração de estado implantados em ambas as regiões, como o dimensionamento horizontal, recomendamos considerar uma solução ativo-ativo, pois ativo-passivo envolve latência adicional.

Componentes

A solução de recuperação de desastres ativo-passivo usa muitos serviços do Azure. Este exemplo de arquitetura envolve os seguintes componentes:

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, o tráfego de rede é roteado para o cluster AKS primário definido na configuração da Porta da Frente do Azure.

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 a prioridade mais baixa). Você pode definir vários clusters para o mesmo nível de prioridade e especificar o peso para cada cluster. Se o cluster primário ficar indisponível, o tráfego será encaminhado automaticamente para a próxima região selecionada na Porta da Frente do Azure. Todo o tráfego deve passar pela Porta da Frente do Azure para que este 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 de 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 baseado em prioridades.

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

Cofre da Chave: você provisiona um Cofre da Chave do Azure em cada região para armazenar segredos e chaves.

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 alta disponibilidade ativa 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)