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

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

HA refere-se ao design e à implementação de um sistema ou serviço altamente confiável, visando a minimização do tempo de inatividade. É uma combinação de ferramentas, tecnologias e processos que asseguram que um sistema ou serviço esteja disponível para executar suas funções. A HA é um componente crítico no planejamento de DR. DR, por sua vez, é o processo de recuperação após um desastre, que visa restaurar as operações de negócios ao estado normal. A DR é um subconjunto da BC, que é o processo de manter ou restabelecer rapidamente as funções empresariais em caso de uma grande interrupção.

Este artigo apresenta algumas práticas recomendadas para aplicativos implantados no AKS, mas não é uma lista completa de todas as soluções possíveis.

Visão geral da tecnologia

Um cluster Kubernetes é dividido em dois componentes:

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

Ao criar um cluster do AKS, a plataforma Azure automaticamente estabelece e configura um plano de controle. O AKS oferece dois tipos de preços para gerenciamento de clustesr: a Camada gratuita e a Camada standard. Para obter mais informações, confira Tipos de preços Gratuito e Standard para o gerenciamento de cluster do AKS.

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

Para executar seus aplicativos e serviços de suporte, é necessário um Kubernetes nó. Um cluster AKS tem pelo menos um nó, uma máquina virtual (VM) do Azure que executa os componentes do nó e o runtime do contêiner do Kubernetes. O tamanho da VM do Azure para seus nós define as CPUs, memória, tamanho e tipo de armazenamento disponíveis (como SSD de alto desempenho ou HDD comum). Ao planejar o tamanho da VM e do armazenamento, considere se os seus aplicativos demandam muita CPU e memória ou um armazenamento de alto desempenho. No AKS, a imagem da VM dos nós de cluster é baseada no Ubuntu Linux, no Azure Linux ou no Windows Server 2022. Quando você cria um cluster AKS ou escala horizontalmente o número de nós, a plataforma do Azure cria e configura automaticamente o número solicitado de VMs.

Para obter mais informações sobre os componentes de clusters e cargas de trabalho no AKS, confira Conceitos básicos 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 em uma única região do Azure. Esses recursos são independentes dos recursos de outras regiões e podem ser removidos ou replicados para outras regiões, se necessário. Para saber mais, confira Recursos reginais.

Os recursos globais compartilham o tempo de vida do sistema e podem ficar disponíveis globalmente no contexto de uma implantação em várias regiões. Para saber mais, confira Recursos globais.

Objetivos de recuperação

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

• O RPO (objetivo de ponto de recuperação) é a duração máxima de perda de dados aceitável. O Objetivo de Ponto de Recuperação (RPO) é medido em unidades de tempo, como minutos, horas ou dias.
• Já o Objetivo de Tempo de Recuperação (RTO) é a duração máxima do tempo de inatividade aceitável, onde o tempo de inatividade é definido por você. Por exemplo, se o tempo de inatividade aceitável durante um desastre for de oito horas, então o RTO será de oito horas.

Zonas de disponibilidade

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

Resiliência zonal

Os clusters do AKS são resilientes a falhas zonais. Se uma zona falhar, o cluster continuará operacional nas zonas restantes. O painel de controle e os nós do cluster são espalhados pelas zonas, e a plataforma do Azure gerencia automaticamente a distribuição dos nós. Para saber mais, confira Resiliência zonal do AKS.

Balanceamento de carga

Balanceamento de carga global

Os serviços de balanceamento de carga global distribuem o tráfego por back-ends regionais, nuvens ou serviços híbridos locais. Esses serviços roteiam o tráfego do usuário final para o back-end disponível mais próximo. Eles também se adaptam a alterações na confiabilidade ou no desempenho dos serviços para otimizar a disponibilidade e o desempenho. Os seguintes serviços do Azure oferecem balanceamento de carga global:

• Azure Front Door
• Gerenciador de Tráfego do Azure
• Azure Load Balancer entre regiões
• Gerenciador de Frota de Kubernetes do Azure

Balanceamento de carga regional

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

• Azure Load Balancer
• Gateway de Aplicativo do Azure
• Gateway de Aplicativo do Azure para contêineres

Observabilidade

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

Definição do escopo

A disponibilidade dos aplicativos é crucial no gerenciamento de clusters do AKS. Por padrão, o AKS fornece alta disponibilidade usando vários nós em um conjunto de dimensionamento de máquinas virtuais, mas esses nós não protegem seu sistema de uma falha na região. Para maximizar o tempo de atividade, planeje com antecedência para manter a continuidade dos negócios e prepare-se para a recuperação de desastre usando as melhores práticas a seguir:

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

Implementações de modelo de implantação

Modelo de implantação	Vantagens	Desvantagens
Ativo-ativo	• Sem perda de dados ou inconsistência durante o failover • Alta resiliência • Uso mais eficiente dos recursos com maior desempenho	• Implementação e gerenciamento complexos • Custo mais alto • Requer um balanceador de carga e uma forma de roteamento de tráfego
Ativo-passivo	• Implementação e gerenciamento simplificados • Menor custo • Dispensa o uso de balanceador de carga ou gerenciador de tráfego	• Risco de perda de dados ou inconsistência durante a transferência • Tempo de recuperação e inatividade mais longos • Subutilização dos recursos
Passivo-frio	• Custo mais baixo • Dispensa o uso de sincronização, replicação, balanceador de carga ou gerenciador de tráfego • Indicado para cargas de trabalho que não críticas e de baixa prioridade	• Risco elevado de perda de dados ou inconsistência durante o failover • Maior tempo de recuperação e inatividade • Requer intervenção manual para ativar o cluster e disparar o backup

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

No modelo de implantação ativo-ativo de alta disponibilidade (HA), você conta com dois clusters do AKS independentes, situados em duas regiões diferentes do Azure (geralmente regiões pareadas, como Canadá Central e Leste do Canadá ou Leste dos EUA 2 e EUA Central), ambos atendendo tráfego ativamente.

Com este exemplo de arquitetura:

• Você configura dois clusters do AKS em regiões distintas do Azure.
• Durante as operações normais, o tráfego de rede é roteado entre as duas as regiões. Se uma região ficar indisponível, o tráfego será automaticamente roteado para uma região mais próxima do usuário que emitiu a solicitação.
• Cada instância regional do AKS possui um par de conexões hub-spoke. As políticas do Gerenciador de Firewall do Azure 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 protege cada cluster do AKS.
• As instâncias regionais do Log Analytics são usadas para armazenar as métricas de rede regionais e os logs de diagnóstico.
• As imagens de contêiner da 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 do Registro de Contêiner do Azure permite a replicação das imagens nas regiões selecionadas do Azure e fornece acesso contínuo às imagens, mesmo que uma região enfrente uma interrupção.

Para estabelecer um modelo de implantação ativo-ativo no AKS, siga estes passos:

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

2. Criar duas instâncias do seu aplicativo web.

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

   • Um ponto de extremidade.
   • Dois grupos de origem, cada um com uma prioridade de one.
   • 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. Faça a implantação do código em ambos os aplicativos web de forma contínua.

Para mais informações, confira a Visão geral recomendada para solução de alta disponibilidade ativo-ativo no AKS.

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

No modelo de implantação ativo-passivo de recuperação de desastres (DR), você conta com dois clusters do AKS independentes, situados em duas regiões diferentes do Azure (geralmente regiões pareadas, como Canadá Central e Leste do Canadá ou Leste dos EUA 2 e EUA Central), ambos atendendo tráfego ativamente. Apenas um dos clusters atende ativamente o tráfego a todo momento. O outro cluster possui a mesma configuração e dados do aplicativo que o cluster ativo, mas só recebe tráfego quando direcionado por um gerenciador de tráfego.

Com este exemplo de arquitetura:

• Você configura dois clusters do AKS em regiões distintas do Azure.
• Em condições normais de operação, o tráfego de rede é direcionado para o cluster do AKS principal, conforme definido nas configurações do Azure Front Door.
  • A prioridade deve ser estabelecida entre 1–5, sendo 1 a mais alta e 5 a mais baixa.
  • 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 (em caso de desastre), o tráfego será roteado automaticamente para a próxima região selecionada no Azure Front Door.
  • Todo o tráfego precisa passar pelo gerenciador de tráfego do Azure Front Door para que o sistema funcione corretamente.
• O Azure Front Door roteia o tráfego para o Gateway de Aplicativo do Azure na região principal (o cluster deve estar 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, seguindo as regras estabelecidas pelo Azure Front Door.
  • As regras vêm do Azure Front Door.
• Um par hub-spoke é implantado em cada instância regional do AKS. As políticas do Gerenciador de Firewall do Azure 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 são usadas para armazenar as métricas de rede regionais e os logs de diagnóstico.
• As imagens de contêiner da 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 do Registro de Contêiner do Azure permite a replicação das imagens nas regiões selecionadas do Azure e fornece acesso contínuo às imagens, mesmo que uma região enfrente uma interrupção.

Para estabelecer um modelo de implantação ativo-pasivo no AKS, siga estes passos:

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

2. Configure regras de dimensionamento automático para o aplicativo secundário, de modo que ela escale para o mesmo número de instâncias do aplicativo primário quando a região primária estiver inativa. Enquanto estiver inativa, não é necessário escalar, o que contribui para a redução de custos. Isso ajuda a reduzir os custos.

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

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

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

5. Restrinja o tráfego de rede dos aplicativos web somente por meio 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 o código em ambos os aplicativos web com implantação contínua.

Para mais informações, confira a Visão geral recomendada para solução de recuperação de desastre ativa-passiva no AKS.

Modelo de implantação passivo-frio

O modelo de implantação de failover passivo-frio é configurado da mesma maneira que o modelo de recuperação de desastres ativo-passivo, exceto que os clusters permanecem inativos até que um usuário os ative em caso de desastre. Consideramos essa abordagem fora do escopo porque envolve uma configuração semelhante ao modelo ativo-passivo, porém é mais complexa por causa da intervenção manual para ativar o cluster e acionar um backup.

Com este exemplo de arquitetura:

• Você cria dois clusters do AKS, preferencialmente em regiões ou zonas diferentes para melhor resiliência.
• Quando precisar fazer failover, ative a implantação para assumir o fluxo de tráfego.
• Caso o cluster passivo primário fique inoperante, você precisará ativar manualmente o cluster frio para assumir o fluxo de tráfego.
• Essa condição precisa ser definida por uma entrada manual todas as vezes ou por um evento específico, 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 são usadas para armazenar as métricas de rede regionais e os logs de diagnóstico de cada cluster.

Para estabelecer um modelo de implantação de failover passivo-frio no AKS, siga estes passos:

1. Crie duas implantações idênticas em zonas/regiões diferentes.
2. Configure regras de dimensionamento automático para o aplicativo secundário, de modo que ela escale para o mesmo número de instâncias do aplicativo primário quando a região primária estiver inativa. Enquanto inativa, ela não precisa ser escalada, 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 para acionar o cluster frio. Se necessário, utilize um balanceador de carga.

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

Cotas e limites de serviço

O AKS estabelece limites e cotas padrão para recursos e funcionalidades, incluindo restrições de uso para determinados SKUs de VMs.

Recurso	Limite
Máximo de clusters por assinatura globalmente	5\.000
Máximo de clusters por assinatura por região 1	100
Máximo de nós por cluster com Conjuntos de Dimensionamento de Máquinas Virtuais e SKU do Standard Load Balancer	5.000 (em todos os pools de nós) Observação: se você não conseguir escalar verticalmente até 5.000 nós por cluster, consulte Melhores Práticas para Clusters Grandes.
Máximo de nós por pool de nós (pools de nós de Conjuntos de Dimensionamento de Máquinas Virtuais)	1000
Número máximo de pools de nós por cluster	100
Máximo de pods por nó: com o plug-in de rede Kubenet 1	Número máximo: 250 Padrão da CLI do Azure: 110 Padrão do modelo do Azure Resource Manager: 110 Padrão da implantação do portal do Azure: 30
Máximo de pods por nó: com a Interface de Rede de Contêiner do Azure (CNI do Azure)2	Número máximo: 250 Máximo recomendado para contêineres do Windows Server: 110 Padrão: 30
Complemento OSM (Open Service Mesh) para AKS	Versão do cluster do Kubernetes: versões com suporte do AKS Controladores do OSM por cluster: 1 Pods por controlador do OSM: 1600 Contas de serviço do Kubernetes gerenciadas pelo OSM: 160
Máximo de serviços kubernetes com balanceamento de carga por cluster com Standard Load Balancer SKU	300
Máximo de nós por cluster com conjuntos de disponibilidade de máquinas virtuais e SKU de Load Balancer Básico	100

¹ Mais são permitidos mediante solicitação.
² Contêineres do Windows Server devem usar o plug-in de rede da CNI do Azure. Não há suporte para Kubenet para contêineres do Windows Server.

Camada do painel de controle do Kubernetes	Limite
Camada padrão	Dimensiona automaticamente o servidor de API do Kubernetes com base na carga. Limites maiores de componentes do painel de controle e instâncias de servidor de API/etcd.
Camada gratuita	Recursos limitados com o limite de solicitações em andamento de 50 chamadas com mutação e 100 chamadas somente leitura. Limite de nó recomendado de 10 nós por cluster. Melhor para experimentos, aprendizado e testes simples. Não recomendado para cargas de trabalho críticas/de produção.

Para saber mais, confira Limites e cotas do AKS.

Backup

O Backup do Azure oferece suporte ao backup de recursos de clusters do AKS e volumes persistentes conectados ao cluster usando uma extensão de backup. O cofre de Backup se comunica com o cluster do 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 (em versão prévia)
• Fazer backup do AKS usando o Backup do Azure (em versão prévia)