Visão geral de alta disponibilidade e recuperação de desastres para o Serviço Kubernetes do Azure (AKS)

Ao criar e gerenciar aplicativos na nuvem, há sempre um risco de interrupção por interrupções e desastres. Para garantir a continuidade de negócios (BC), você precisa planejar alta disponibilidade (HA) e recuperação de desastres (DR).

HA refere-se ao projeto e implementação de um sistema ou serviço que é altamente confiável e experimenta tempo de inatividade mínimo. HA é uma combinação de ferramentas, tecnologias e processos que garantem que um sistema ou serviço esteja disponível para executar a função pretendida. O HA é um componente crítico do planejamento de DR. DR é o processo de recuperação de um desastre e restaurar as operações de negócios para um estado normal. DR é um subconjunto do BC, que é o processo de manter as funções de negócios ou retomá-las rapidamente no caso de uma grande interrupção.

Este artigo aborda algumas práticas recomendadas para aplicativos implantados no AKS, mas não pretende de forma alguma ser uma lista exaustiva de possíveis soluções.

Visão geral da tecnologia

Um cluster do Kubernetes está dividido em dois componentes:

• O plano de controle, que fornece os principais serviços do Kubernetes e orquestração de cargas de trabalho de aplicativos, e
• Os nós, que executam as cargas de trabalho do aplicativo.

Quando você cria um cluster AKS, a plataforma Azure cria e configura automaticamente um plano de controle. O AKS oferece dois níveis de preços para gerenciamento de cluster: o nível Gratuito e o nível Padrão. Para obter mais informações, consulte Níveis de preços gratuitos e padrão para gerenciamento de cluster AKS.

O plano de controle e seus recursos residem somente na região onde você criou o cluster. O AKS fornece um plano de controle de locatário único com um servidor API dedicado, agendador, etc. Você define o número e o tamanho dos nós, e a plataforma Azure configura a comunicação segura entre o plano de controle e os nós. A interação com o plano de controle ocorre por meio de APIs do Kubernetes, como kubectl ou o painel do Kubernetes.

Para executar seus aplicativos e serviços de suporte, você precisa de um nó Kubernetes. Um cluster AKS tem pelo menos um nó, uma máquina virtual (VM) do Azure que executa os componentes do nó Kubernetes e o tempo de execução do contêiner. O tamanho da VM do Azure para seus nós define CPUs, memória, tamanho e o tipo de armazenamento disponível (como SSD de alto desempenho ou HDD normal). Planeje a VM e o tamanho do armazenamento para saber se seus aplicativos podem exigir grandes quantidades de CPU e memória ou armazenamento de alto desempenho. No AKS, a imagem da VM para os nós do cluster é baseada no Ubuntu Linux , Azure Linux ou Windows Server 2022. Quando você cria um cluster AKS ou dimensiona o número de nós, a plataforma Azure cria e configura automaticamente o número solicitado de VMs.

Para obter mais informações sobre componentes de cluster e carga de trabalho no AKS, consulte Conceitos principais do Kubernetes para AKS.

Considerações importantes

Recursos regionais e globais

Os recursos regionais são provisionados como parte de um selo de implantação para uma única região do Azure. Esses recursos não compartilham nada com recursos de outras regiões e podem ser removidos de forma independente ou replicados para outras regiões. Para obter mais informações, consulte Recursos regionais.

Os recursos globais compartilham a vida útil do sistema e podem estar disponíveis globalmente no contexto de uma implantação em várias regiões. Para obter mais informações, consulte Recursos globais.

Objetivos de recuperação

Um plano completo de recuperação de desastres deve especificar os requisitos de negócios para cada processo que o aplicativo implementa:

• O RPO (Recovery Point Objetive, objetivo de ponto de recuperação) é a duração máxima da perda de dados aceitável. O RPO é medido em unidades de tempo, como minutos, horas ou dias.
• O RTO (Recovery Time Objetive, objetivo de tempo de recuperação) é a duração máxima aceitável do tempo de inatividade, com tempo de inatividade definido pela sua especificação. Por exemplo, se a duração aceitável do tempo de inatividade em um desastre for de oito horas, o RTO será de oito horas.

Zonas de disponibilidade

Você pode usar zonas de disponibilidade para distribuir seus dados por várias zonas na mesma região. Dentro de uma região, as zonas de disponibilidade são próximas o suficiente para ter conexões de baixa latência com outras zonas de disponibilidade, mas estão distantes o suficiente para reduzir a probabilidade de que mais de uma seja afetada por interrupções locais ou pelo clima. Para obter mais informações, consulte Recomendações para usar zonas e regiões de disponibilidade.

Resiliência zonal

Os clusters AKS são resilientes a falhas zonais. Se uma zona falhar, o cluster continuará a ser executado nas zonas restantes. O plano de controle e os nós do cluster estão espalhados pelas zonas, e a plataforma Azure lida automaticamente com a distribuição dos nós. Para obter mais informações, consulte Resiliência zonal do AKS.

Balanceamento de carga

Balanceamento de carga global

Os serviços de balanceamento de carga global distribuem o tráfego entre back-ends regionais, nuvens ou serviços locais híbridos. Esses serviços encaminham o tráfego do usuário final para o back-end disponível mais próximo. Eles também reagem a mudanças na confiabilidade ou desempenho do serviço para maximizar a disponibilidade e o desempenho. Os seguintes serviços do Azure fornecem balanceamento de carga global:

• Azure Front Door
• Gestor de Tráfego do Azure
• Azure Load Balancer entre regiões
• Azure Kubernetes Fleet Manager

Balanceamento de carga regional

Os serviços regionais de balanceamento de carga distribuem o tráfego dentro de redes virtuais entre VMs ou pontos de extremidade de serviço com redundância zonal e de zona dentro de uma região. Os seguintes serviços do Azure fornecem balanceamento de carga regional:

• Balanceador de Carga do Azure
• Gateway de Aplicação do Azure
• Azure Application Gateway for Containers

Observabilidade

Você precisa coletar dados de aplicativos e infraestrutura para permitir operações eficazes e confiabilidade maximizada. O Azure fornece ferramentas para ajudá-lo a monitorar e gerenciar suas cargas de trabalho do AKS. Para obter mais informações, consulte Recursos de observabilidade.

Definição do âmbito de aplicação

O tempo de atividade do aplicativo torna-se importante à medida que você gerencia clusters AKS. Por padrão, o AKS fornece alta disponibilidade usando vários nós em um Conjunto de Dimensionamento de Máquina Virtual, mas esses nós não protegem seu sistema de uma falha de região. Para maximizar seu tempo de atividade, planeje com antecedência para manter a continuidade dos negócios e prepare-se para a recuperação de desastres usando as seguintes práticas recomendadas:

• Planeje clusters AKS em várias regiões.
• Encaminhe o tráfego entre vários clusters usando o Gerenciador de Tráfego do Azure.
• Use a replicação geográfica para seus registros de imagem de contêiner.
• Planeje o estado do aplicativo em vários clusters.
• Replique o armazenamento em várias regiões.

Implementações de modelo de implantação

Modelo de implementação	Prós	Contras
Ativo-ativo	• Sem perda de dados ou inconsistência durante o failover • Alta resiliência • Melhor aproveitamento dos recursos com maior desempenho	• Implementação e gestão complexas • Custo mais elevado • Requer um balanceador de carga e forma de roteamento de tráfego
Ativo-passivo	• Implementação e gestão mais simples • Menor custo • Não requer um balanceador de carga ou gerenciador de tráfego	• Potencial de perda ou inconsistência de dados durante o failover • Maior tempo de recuperação e tempo de inatividade • Subutilização de recursos
Passivo-frio	• Menor custo • Não requer sincronização, replicação, balanceador de carga ou gerenciador de tráfego • Adequado para cargas de trabalho não críticas e de baixa prioridade	• Alto risco de perda ou inconsistência de dados durante o failover • Maior tempo de recuperação e tempo de inatividade • Requer intervenção manual para ativar o cluster e acionar o backup

Modelo de implantação de alta disponibilidade ativo-ativo

No modelo de implantação de alta disponibilidade (HA) ativo-ativo, você tem dois clusters AKS independentes implantados em duas regiões diferentes do Azure (normalmente regiões emparelhadas, como Canadá Central e Leste do Canadá ou Leste dos EUA 2 e Central dos EUA) que atendem ativamente ao tráfego.

Com este exemplo de arquitetura:

• Você implanta dois clusters AKS em regiões separadas do Azure.
• Durante as operações normais, o tráfego de rede rotas entre ambas as regiões. Se uma região ficar indisponível, o tráfego será encaminhado automaticamente para uma região mais próxima do usuário que emitiu a solicitação.
• Há um par hub-spoke implantado para cada instância regional do AKS. As políticas do Azure Firewall Manager gerenciam as regras de firewall entre as regiões.
• O Azure Key Vault é provisionado em cada região para armazenar segredos e chaves.
• O Azure Front Door balanceia a carga e roteia o tráfego para uma instância regional do Gateway de Aplicativo do Azure, que fica na frente de cada cluster AKS.
• As instâncias regionais do Log Analytics armazenam métricas de rede regional e logs de diagnóstico.
• As imagens de contêiner para a carga de trabalho são armazenadas em um registro de contêiner gerenciado. Um único Registro de Contêiner do Azure é usado 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.

Para criar um modelo de implantação ativo-ativo no AKS, execute as seguintes etapas:

1. Crie duas implantações idênticas em duas regiões diferentes do Azure.

2. Crie duas instâncias do seu aplicativo Web.

3. Crie um perfil do Azure Front Door com os seguintes recursos:

   • Um ponto final.
   • Dois grupos de origem, cada um com uma prioridade de um.
   • Uma rota.

4. Limite o tráfego de rede para os aplicativos Web somente da instância do Azure Front Door. 5. Configure todos os outros serviços de back-end do Azure, como bancos de dados, contas de armazenamento e provedores de autenticação.

5. Implante código em ambos os aplicativos Web com implantação contínua.

Para obter mais informações, consulte a Visão geral da solução de alta disponibilidade ativa-ativa recomendada para AKS.

Modelo de implantação de recuperação de desastres ativo-passivo

No modelo de implantação de recuperação de desastres (DR) ativo-passivo, você tem dois clusters AKS independentes implantados em duas regiões diferentes do Azure (normalmente regiões emparelhadas, como Canadá Central e Leste do Canadá ou Leste dos EUA 2 e Central dos EUA) que atendem ativamente ao tráfego. Apenas um dos clusters atende ativamente o tráfego a qualquer momento. O outro cluster contém a mesma configuração e os mesmos dados de aplicativo que o cluster ativo, mas não aceita tráfego, a menos que seja direcionado por um gerenciador de tráfego.

Com este exemplo de arquitetura:

• Você implanta dois clusters AKS em regiões separadas do Azure.
• Durante as operações normais, o tráfego de rede encaminha para o cluster AKS primário, que você define na configuração da Porta da Frente do Azure.
  • A prioridade deve ser definida entre 1 e 5 , sendo 1 o mais elevado e 5 o mais baixo.
  • Você pode definir vários clusters para o mesmo nível de prioridade e pode especificar o peso de cada um.
• Se o cluster primário ficar indisponível (ocorre um desastre), o tráfego roteia automaticamente para a próxima região selecionada na Porta da Frente do Azure.
  • Todo o tráfego deve passar pelo gerenciador de tráfego da Porta da Frente do Azure para que esse sistema funcione.
• O Azure Front Door encaminha o tráfego para o Gateway de Aplicativo do Azure na região primária (o cluster deve ser marcado com prioridade 1). Se essa região falhar, o serviço redirecionará o tráfego para o próximo cluster na lista de prioridades.
  • As regras vêm do Azure Front Door.
• Um par hub-spoke é implantado para cada instância regional do AKS. As políticas do Azure Firewall Manager gerenciam as regras de firewall entre as regiões.
• O Azure Key Vault é provisionado em cada região para armazenar segredos e chaves.
• As instâncias regionais do Log Analytics armazenam métricas de rede regional e logs de diagnóstico.
• As imagens de contêiner para a carga de trabalho são armazenadas em um registro de contêiner gerenciado. Um único Registro de Contêiner do Azure é usado 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.

Para criar um modelo de implantação ativo-passivo no AKS, execute as seguintes etapas:

1. Crie duas implantações idênticas em duas regiões diferentes do Azure.

2. Configure regras de dimensionamento automático para o aplicativo secundário para que ele seja dimensionado para a mesma contagem de instâncias que o primário quando a região primária se tornar inativa. Embora inativo, ele não precisa ser ampliado. Isso ajuda a reduzir custos.

3. Crie duas instâncias do seu aplicativo Web, com uma em cada cluster.

4. Crie um perfil do Azure Front Door com os seguintes recursos:

   • Um ponto final.
   • Um grupo de origem com prioridade de um para a região primária.
   • Um segundo grupo de origem com uma prioridade de dois para a região secundária.
   • Uma rota.

5. Limite o tráfego de rede para os aplicativos Web somente da instância do Azure Front Door.

6. Configure todos os outros serviços de back-end do Azure, como bancos de dados, contas de armazenamento e provedores de autenticação.

7. Implante código em ambos os aplicativos Web com implantação contínua.

Para obter mais informações, consulte a Visão geral da solução de recuperação de desastres ativo-passivo recomendada para AKS.

Modelo de implantação de failover passivo-frio

O modelo de implantação de failover passivo-frio é configurado da mesma forma que o modelo de implantação de recuperação de desastres ativo-passivo, exceto que os clusters permaneçam inativos até que um usuário os ative em caso de desastre. Consideramos essa abordagem fora do escopo porque envolve uma configuração semelhante à ativa-passiva, mas com a complexidade adicional da intervenção manual para ativar o cluster e disparar um backup.

Com este exemplo de arquitetura:

• Você cria dois clusters AKS, de preferência em regiões ou zonas diferentes para melhor resiliência.
• Quando precisar fazer failover, você ativa a implantação para assumir o fluxo de tráfego.
• Caso o cluster passivo primário fique inativo, você precisa ativar manualmente o cluster frio para assumir o fluxo de tráfego.
• Essa condição precisa ser definida por uma entrada manual toda vez ou por um determinado evento, conforme especificado por você.
• O Azure Key Vault é provisionado em cada região para armazenar segredos e chaves.
• As instâncias regionais do Log Analytics armazenam métricas de rede regional e logs de diagnóstico para cada cluster.

Para criar um modelo de implantação de failover passivo-frio no AKS, execute as seguintes etapas:

1. Crie duas implantações idênticas em zonas/regiões diferentes.
2. Configure regras de dimensionamento automático para o aplicativo secundário para que ele seja dimensionado para a mesma contagem de instâncias que o primário quando a região primária se tornar inativa. Embora inativo, ele não precisa ser ampliado, o que ajuda a reduzir custos.
3. Crie duas instâncias do seu aplicativo Web, com uma em cada cluster.
4. Configure todos os outros serviços de back-end do Azure, como bancos de dados, contas de armazenamento e provedores de autenticação.
5. Defina uma condição em que o cluster frio deve ser acionado. Você pode usar um balanceador de carga se precisar.

Para obter mais informações, consulte a Visão geral da solução de failover passivo-frio recomendada para AKS.

Quotas e limites do serviço

O AKS define limites padrão e cotas para recursos e recursos, incluindo restrições de uso para determinadas SKUs de VM.

Recurso	Limite
Máximo de clusters por assinatura globalmente	5.000
Máximo de clusters por subscrição por região 1	100
Máximo de nós por cluster com Conjuntos de Dimensionamento de Máquina Virtual e SKU do Balanceador de Carga Padrão	5.000 em todos os pools de nós Observação: se você não conseguir dimensionar até 5.000 nós por cluster, consulte Práticas recomendadas para clusters grandes.
Máximo de nós por pool de nós (pools de nós de Conjuntos de Escala de Máquina Virtual)	1000
Máximo de pools de nós por cluster	100
Máximo de pods por nó: com o plug-inde rede Kubenet 1	Máximo: 250 Padrão da CLI do Azure: 110 Padrão do modelo do Azure Resource Manager: 110 Padrão de implantação do portal do Azure: 30
Máximo de pods por nó: com a Interface de Rede de Contêiner do Azure (Azure CNI)2	Máximo: 250 Máximo recomendado para contêineres do Windows Server: 110 Padrão: 30
Complemento AKS Open Service Mesh (OSM)	Versão do cluster do Kubernetes: Versões suportadas pelo AKS Controladores OSM por cluster: 1 Pods por controlador OSM: 1600 Contas de serviço Kubernetes gerenciadas pelo OSM: 160
Máximo de serviços kubernetes com balanceamento de carga por cluster com SKU do Balanceador de Carga Padrão	300
Máximo de nós por cluster com Conjuntos de Disponibilidade de Máquina Virtual e SKU do Balanceador de Carga Básico	100

1 Mais são permitidos mediante solicitação.
2 Os contêineres do Windows Server devem usar o plug-in de rede CNI do Azure. Kubenet não é suportado para contêineres do Windows Server.

Camada de plano de controle do Kubernetes	Limite
Escalão standard	Dimensiona automaticamente o servidor de API do Kubernetes com base na carga. Limites maiores de componentes do plano de controle e instâncias de API/etcd.
Escalão gratuito	Recursos limitados com limite de solicitações a bordo de 50 mutantes e 100 chamadas somente leitura. Limite de nó recomendado de 10 nós por cluster. Ideal para experimentar, aprender e testar simples. Não aconselhado para cargas de trabalho críticas/de produção.

Para obter mais informações, consulte Cotas e limites de serviço do AKS.

Backup

O Backup do Azure dá suporte ao backup de recursos de cluster AKS e volumes persistentes anexados ao cluster usando uma extensão de backup. O cofre de backup se comunica com o cluster AKS através da extensão para executar operações de backup e restauração.

Para obter mais informações, consulte os seguintes artigos:

• Sobre o backup do AKS usando o Backup do Azure (visualização)
• Fazer backup do AKS usando o Backup do Azure (visualização)