Visão geral da solução de frio 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 frio passivo para AKS. Dentro desta solução, implantamos dois clusters AKS independentes e idênticos em duas regiões emparelhadas do Azure com apenas um cluster servindo ativamente o tráfego quando o aplicativo é necessário.
Nota
A prática a seguir foi revisada internamente e aprovada em conjunto com nossos parceiros da Microsoft.
Visão geral da solução de frio passivo
Nessa abordagem, temos dois clusters AKS independentes 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 cair, devemos ativar manualmente o cluster frio para assumir o fluxo de tráfego. Podemos definir esta condição através de uma entrada manual sempre ou para especificar um determinado evento.
Cenários e configurações
Essa solução é melhor implementada como uma carga de trabalho "use conforme necessário", o que é útil para cenários que exigem que as cargas de trabalho sejam executadas em horários específicos do dia ou sob demanda. Exemplos de casos de uso para uma abordagem de frio passivo incluem:
- Uma empresa de fabricação que precisa executar uma simulação complexa e que consome muitos 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 é acionada pelo usuário ou por uma agenda. Se o cluster não funcionar após o acionamento, o cluster frio poderá ser usado como backup e a carga de trabalho poderá ser executada nele.
- Uma agência governamental que precisa manter um backup de seus sistemas e dados críticos em caso de 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 desastres de frio 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. Quando o aplicativo é necessário, o cluster passivo é ativado para receber tráfego de rede.
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.
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.
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 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 desligado e precisa concluir o processo de configuração. Essa abordagem não é ideal para aplicativos sensíveis ao tempo. Nesse caso, recomendamos considerar um 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 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: