Visão geral da solução passiva e fria 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 passiva e fria para o AKS. Nessa solução, implantamos dois clusters AKS independentes e idênticos em duas regiões emparelhadas do Azure com apenas um cluster atendendo ativamente o tráfego quando o aplicativo é necessário.

Visão geral da solução passiva e fria

Nessa abordagem, temos dois clusters independentes do AKS sendo implantados em duas regiões do Azure. Quando o aplicativo é necessário, ativamos o cluster passivo para receber tráfego. Se o cluster passivo falhar, devemos ativar manualmente o cluster frio para assumir o fluxo de tráfego. Podemos definir essa condição por meio de uma entrada manual todas as vezes ou para especificar um determinado evento.

Cenários e configurações

Essa solução é melhor implementada como uma carga de trabalho de "uso conforme necessário", que é útil para cenários que exigem que as cargas de trabalho sejam executadas em horários específicos do dia ou executadas sob demanda. Exemplos de casos de uso para uma abordagem passiva-fria incluem:

• Uma empresa de fabricação que precisa executar uma simulação complexa e com uso intensivo de recursos em um grande conjunto de dados. Nesse caso, o cluster passivo está localizado em uma região de nuvem que oferece serviços de computação e armazenamento de alto desempenho. O cluster passivo só é usado quando a simulação é disparada pelo usuário ou por um agendamento. Se o cluster não funcionar quando for acionado, o cluster frio poderá ser usado como backup, e a carga de trabalho poderá ser executada nesse cluster.
• Uma agência governamental que precisa manter um backup de seus sistemas e dados críticos em caso de um ataque cibernético ou desastre natural. Nesse caso, o cluster passivo está localizado em um local seguro e isolado que não é acessível ao público.

Componentes

A solução de recuperação de desastre passiva e fria 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. Quando o aplicativo é necessário, o cluster passivo é ativado para receber tráfego de rede.

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 métricas e logs de diagnóstico para todas as instâncias do AKS.

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.

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 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 o cluster passivo não estiver funcionando corretamente devido a um problema em sua região específica do Azure, você poderá ativar o cluster frio e redirecionar todo o tráfego para a região desse cluster. Você pode usar esse processo enquanto o cluster passivo é desativado até que ele comece a funcionar novamente. O cluster frio pode levar alguns minutos para ficar online, pois foi desativado e precisa concluir o processo de instalação. Essa abordagem não é ideal para aplicativos que diferenciam o tempo. Nesse caso, recomendamos considerar o failover ativo-ativo.

Pods de Aplicação (Regional)

Um objeto de implantação do Kubernetes cria várias réplicas de um pod (ReplicaSet). Se uma delas ficar indisponível, o tráfego será direcionado 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 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 fica indisponível, os pods no cluster deixam de estar 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 pods do Kubernetes nessas regiões continuam processando 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 estão dimensionados corretamente para absorver qualquer aumento repentino no tráfego causado pelo failover de região. Por exemplo, ao usar o Azure Container Network Interface (CNI), verifique se há uma sub-rede que possa suportar todos os IPs dos pods durante picos de tráfego.
• 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 AKS Cluster Autoscaler para aumentar o número de nós da instância do Kubernetes e 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 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 completa em uma região, o Azure Front Door roteia o tráfego para as regiões restantes em funcionamento. Novamente, certifique-se de compensar o aumento do tráfego e das solicitações para o cluster restante.

Estratégia de failover para testes

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 passiva ativa para o AKS (Serviço de Kubernetes do Azure)
• Visão geral da solução de alta disponibilidade ativa para o AKS (Serviço de Kubernetes do Azure)