Visão geral da solução de frio passivo para o Azure Kubernetes Service (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 criar uma implementação idêntica numa região secundária do Azure, a sua aplicação torna-se menos suscetível a um desastre numa única região, o que garante a continuidade do negócio, e qualquer replicação de dados entre as regiões permite-lhe recuperar o estado da sua última aplicação.

Este guia apresenta uma solução passivo-fria para AKS. Dentro desta solução, implementamos dois clusters AKS independentes e idênticos em duas regiões Azure emparelhadas, com apenas um cluster a servir ativamente o tráfego quando a aplicação é necessária.

Nota

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

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

Nesta abordagem, temos dois clusters AKS independentes a serem implementados em duas regiões do Azure. Quando a aplicação é necessária, ativamos o cluster passivo para receber tráfego. Se o cluster passivo cair, temos de ativar manualmente o cluster frio para assumir o fluxo do tráfego. Podemos definir esta condição através de uma entrada manual todas as vezes ou para especificar um determinado evento.

Cenários e configurações

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

  • Uma empresa de fabrico que precisa de executar uma simulação complexa e que exige muitos recursos num grande conjunto de dados. Neste caso, o cluster passivo está localizado numa região cloud que oferece serviços de computação e armazenamento de alto desempenho. O cluster passivo só é usado quando a simulação é desencadeada pelo utilizador ou por um agendamento. Se o cluster não funcionar quando for ativado, o cluster em espera pode ser usado como reserva e a carga de trabalho pode ser executada nesse cluster.
  • Uma agência governamental que precisa de manter uma cópia de segurança dos seus sistemas e dados críticos em caso de ciberataque ou desastre natural. Neste caso, o cluster passivo está localizado num local seguro e isolado que não é acessível ao público.

Componentes

A solução passiva-fria de recuperação de desastres utiliza 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 a aplicação é necessária, 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 de Log Analytics armazenam métricas de rede regional e registos de diagnóstico. Uma instância partilhada armazena métricas e registos de diagnóstico para todas as instâncias do AKS.

Par hub-and-spoke: É implementado um par hub-and-spoke 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 geo-replicação para o Azure Container Registry permite replicar imagens para as regiões selecionadas do Azure e proporciona acesso contínuo às imagens mesmo que uma região sofra uma falha.

Processo de failover

Se o cluster passivo não estiver a funcionar corretamente devido a um problema na sua região específica do Azure, podes ativar o cluster frio e redirecionar todo o tráfego para a região desse cluster. Podes usar este processo enquanto o cluster passivo está desativado até voltar a funcionar. O cluster inativo pode demorar alguns minutos a ficar online, pois esteve desligado e precisa de concluir o processo de configuração. Esta abordagem não é ideal para aplicações sensíveis ao tempo. Nesse caso, recomendamos considerar um failover ativo-ativo.

Pods de Aplicação (Regionais)

Um objeto de implementação Kubernetes cria múltiplas réplicas de um pod (ReplicaSet). Se uma delas não estiver disponível, o tráfego será encaminhado entre as réplicas restantes. O Kubernetes ReplicaSet tenta manter o número especificado de réplicas em funcionamento. Se uma instância falhar, uma nova instância deve ser recriada. As sondas Liveness podem verificar o estado do aplicativo ou processo em execução no pod. Se o pod não responder, a sonda de atividade remove 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 do cluster deixam de estar disponíveis para processar pedidos. Neste caso, a instância Azure Front Door encaminha todo o tráfego para as restantes regiões de saúde. Os clusters e pods do Kubernetes nessas regiões continuam a atender solicitações. Para compensar o aumento do tráfego e dos pedidos para o cluster remanescente, tenha em mente as seguintes orientações:

  • Certifique-se de que os recursos de rede e computação têm o tamanho adequado para absorver qualquer aumento súbito de tráfego devido ao failover regional. Por exemplo, ao usar o Azure Container Network Interface (CNI), certifique-se de que tem uma sub-rede que consiga suportar todos os endereços IP dos pods durante picos de tráfego.
  • Utilize o Horizontal Pod Autoscaler para aumentar o número de réplicas dos pods, de modo a compensar o aumento da procura regional.
  • Utilize o AKS Cluster Autoscaler para aumentar o número de nós de instância do Kubernetes, de modo a compensar o aumento da procura regional.

Conjuntos 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 os teus nós AKS de se tornarem uma falha regional de ponto único, usa Azure Zonas de Disponibilidade. As zonas de disponibilidade garantem que os nós AKS em cada zona de disponibilidade estão fisicamente separados daqueles definidos noutras zonas de disponibilidade.

Conjuntos de nós do Kubernetes (Global)

Num completo fracasso regional, o Azure Front Door encaminha o tráfego para as regiões restantes saudáveis. Novamente, certifique-se de compensar o aumento do tráfego e das solicitações para o cluster restante.

Estratégia de testes de ativação pós-falha

Embora atualmente não existam mecanismos dentro do AKS para reduzir toda uma região de implementação para fins de teste, pode usar os Workspaces do Azure Chaos Studio para simular uma falha na zona de disponibilidade para os pools de nós do seu cluster.

Passos seguintes

Se está a considerar uma solução diferente, consulte os seguintes artigos:

  • Última atualização a