Linha de base AKS para clusters multirregionais

Azure Kubernetes Service (AKS)

Azure Front Door

Gateway de Aplicação do Azure

Registo de Contentores do Azure

Azure Firewall

Essa arquitetura detalha como executar várias instâncias de um cluster do Serviço Kubernetes do Azure (AKS) em várias regiões em uma configuração ativa/ativa e altamente disponível.

Esta arquitetura baseia-se na arquitetura de linha de base AKS, o ponto de partida recomendado pela Microsoft para a infraestrutura AKS. A linha de base do AKS detalha recursos de infraestrutura, como ID de carga de trabalho do Microsoft Entra, restrições de entrada e saída, limites de recursos e outras configurações seguras de infraestrutura do AKS. Esses detalhes de infraestrutura não são abordados neste documento. Recomendamos que você se familiarize com a linha de base do AKS antes de prosseguir com o conteúdo de várias regiões.

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Componentes

Muitos componentes e serviços do Azure são usados nessa arquitetura AKS de várias regiões. Apenas os componentes exclusivos desta arquitetura multi-cluster estão listados aqui. Para o restante, consulte a arquitetura de linha de base do AKS.

clusters AKS regionais: Vários clusters AKS são implantados, cada um em uma região separada do Azure. Durante as operações normais, o tráfego de rede é roteado entre todas as regiões. Se uma região ficar indisponível, o tráfego será roteado para uma região restante mais próxima do usuário que emitiu a solicitação.
Redes regionais hub-spoke: Uma rede virtual hub-spoke regional é implantada para cada instância regional do AKS. políticas de do Gerenciador de Firewall do Azure são usadas para gerenciar políticas de firewall em todas as regiões.
Cofre de chave regional: do Cofre da Chave do Azure é provisionado em cada região. Os cofres de chaves são usados para armazenar valores confidenciais e chaves específicas para o cluster AKS e serviços de suporte que estão nessa região.
Vários espaços de trabalho de log: espaços de trabalho de do Regional Log Analytics são usados para armazenar métricas de rede regional e logs de diagnóstico. Além disso, uma instância compartilhada do Log Analytics é usada para armazenar métricas e logs de diagnóstico para todas as instâncias do AKS.
Frota AKS: Um Gerenciador de Frota do Kubernetes do Azure é implantado para coordenar as atualizações de versão de cluster do Kubernetes e as atualizações de versão de imagem de nó em cada um dos clusters AKS regionais.
Cluster de hub de frota (gerenciado pela Microsoft):opcionalmente, um único cluster de hub do Azure Kubernetes Fleet Manager pode ser implantado para dar suporte a recursos específicos de frotas, como propagação de carga de trabalho. O cluster de hub é um recurso do Azure com escopo regional que ajuda a gerenciar a propagação da carga de trabalho e o balanceamento de carga entre vários clusters membros. É melhor implantar o cluster de hub como um cluster de hub privado, que deve ser acessível a partir de clusters membros para suportar sinais de pulsação e executar processos de reconciliação de configuração.
perfil Global Azure Front Door:Azure Front Door é usado para balancear a carga e rotear o tráfego para uma instância regional do Gateway de Aplicativo do Azure, que fica na frente de cada cluster AKS. O Azure Front Door permite o roteamento global de camada 7, ambos necessários para essa arquitetura.
Registro de contêiner global: as imagens de contêiner para a carga de trabalho são armazenadas em um registro de contêiner gerenciado. Nessa arquitetura, um único Registro de Contêiner do Azure é usado para todas as instâncias do Kubernetes no cluster. A replicação geográfica para do Registro de Contêiner do Azure permite replicar imagens para as regiões selecionadas do Azure e fornecer acesso contínuo às imagens, mesmo que uma região esteja passando por uma interrupção.

Alternativas

Esta solução utiliza o Azure Kubernetes Fleet Manager. As frotas permitem uma variedade de recursos para gerenciar vários clusters, com foco na simplificação das operações do dia 2, fornecendo um plano de controle que pode orquestrar atividades em vários clusters. Os benefícios do Fleet Manager aumentam à medida que o número de clusters na sua frota cresce.

Nesta solução, a frota orquestra atualizações de versão do Kubernetes em vários clusters, bem como atualizações de versão de imagem de nó. Esses recursos não exigem a implantação de um cluster de hub. Você pode optar por fazer com que cada cluster execute atualizações de versão e imagem de nó do Kubernetes de forma independente, o que não requer uma frota. No entanto, se você fizer isso, é provável que os clusters recebam atualizações de versão em momentos diferentes e pode se tornar difícil validar sua carga de trabalho e configuração com várias versões em seu ambiente de produção simultaneamente.

Opcionalmente, você também pode usar uma frota para coordenação de implantação de carga de trabalho, o que requer que você adicione um cluster de hub. As implantações de carga de trabalho são discutidas com mais detalhes mais adiante neste artigo.

Padrões de design

Essa arquitetura usa dois padrões de design de nuvem:

Geodes (nós geográficos), onde qualquer região pode atender qualquer solicitação.
Carimbos de implantação, onde várias cópias independentes de um aplicativo ou componente de aplicativo são implantadas de uma única fonte, como um modelo de implantação.

Considerações sobre padrões geográficos

Ao selecionar regiões para implantar cada cluster AKS, considere regiões próximas ao consumidor da carga de trabalho ou aos seus clientes. Além disso, considere a utilização da replicação entre regiões. A replicação entre regiões replica de forma assíncrona os mesmos aplicativos e dados em outras regiões do Azure para proteção de recuperação de desastres. À medida que o cluster for dimensionado para além de duas regiões, continue a planejar a replicação entre regiões para cada par de clusters AKS.

Dentro de cada região, os nós nos pools de nós AKS estão espalhados por várias zonas de disponibilidade para ajudar a evitar problemas devido a falhas zonais. As zonas de disponibilidade são suportadas num conjunto limitado de regiões, o que influencia a colocação de clusters regionais. Para obter mais informações sobre o AKS e as zonas de disponibilidade, incluindo uma lista de regiões suportadas, consulte Zonas de disponibilidade do AKS.

Considerações sobre carimbo de implantação

Ao gerenciar uma solução AKS de várias regiões, você implanta vários clusters AKS em várias regiões. Cada um destes agrupamentos é considerado um selo. Se houver uma falha regional ou se você precisar adicionar mais capacidade ou presença regional para seus clusters, talvez seja necessário criar uma nova instância de carimbo. Ao selecionar um processo para criar e gerenciar carimbos de implantação, é importante considerar as seguintes coisas:

Selecione a tecnologia apropriada para definições de carimbo que permita a configuração generalizada. Por exemplo, você pode usar o Bicep para definir a infraestrutura como código.
Forneça valores específicos da instância usando um mecanismo de entrada de implantação, como variáveis ou arquivos de parâmetro.
Selecione ferramentas de implantação que permitam uma implantação flexível, repetível e idempotente.
Em uma configuração de carimbo ativo/ativo, considere como o tráfego é balanceado em cada carimbo. Essa arquitetura usa o Azure Front Door para balanceamento de carga global.
À medida que os selos são adicionados e removidos da coleção, considere as preocupações de capacidade e custo.
Considere como ganhar visibilidade e monitorar a coleção de selos como uma única unidade.

Cada um desses itens é detalhado com orientações específicas nas seções a seguir.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Implantação e inicialização de cluster

Ao implantar vários clusters Kubernetes em configurações altamente disponíveis e geograficamente distribuídas, é essencial considerar a soma de cada cluster Kubernetes como uma unidade acoplada. Talvez você queira desenvolver estratégias orientadas por código para implantação e configuração automatizadas para garantir que cada instância do Kubernetes seja o mais idêntica possível. Considere estratégias de expansão e entrada, inclusive adicionando ou removendo outros clusters do Kubernetes. Seu design, implantação e plano de configuração devem levar em conta interrupções da zona de disponibilidade, falhas regionais e outros cenários comuns.

Definição de cluster

Você tem muitas opções para implantar um cluster do Serviço Kubernetes do Azure. O portal do Azure, a CLI do Azure e o módulo do Azure PowerShell são opções decentes para implantar clusters AKS individuais ou não acoplados. Esses métodos, no entanto, podem apresentar desafios ao trabalhar com muitos clusters AKS fortemente acoplados. Por exemplo, usar o portal do Azure abre a oportunidade de configuração incorreta devido a etapas perdidas ou opções de configuração indisponíveis. A implantação e configuração de muitos clusters usando o portal é um processo demorado que requer o foco de um ou mais engenheiros. Se você usar a CLI do Azure ou o Azure PowerShell, poderá construir um processo repetível e automatizado usando as ferramentas de linha de comando. No entanto, a responsabilidade da idempotência, do controle de falhas de implantação e da recuperação de falhas é de você e dos scripts criados.

Ao trabalhar com várias instâncias do AKS, recomendamos considerar a infraestrutura como soluções de código, como Bicep, modelos do Azure Resource Manager ou Terraform. A infraestrutura como soluções de código fornece uma solução de implantação automatizada, escalável e idempotente. Por exemplo, você pode usar um arquivo Bicep para os serviços compartilhados da solução e outro para os clusters AKS e outros serviços regionais. Se você usar a infraestrutura como código, um carimbo de implantação poderá ser definido com configurações generalizadas, como rede, autorização e diagnóstico. Um arquivo de parâmetro de implantação pode ser fornecido com valores específicos da região. Com essa configuração, um único modelo pode ser usado para implantar um carimbo quase idêntico em qualquer região.

O custo de desenvolvimento e manutenção da infraestrutura como ativos de código pode ser caro. Em alguns casos, a sobrecarga de definir infraestrutura como código pode superar os benefícios, como quando você tem um número muito pequeno (digamos, 2 ou 3) e imutável de instâncias AKS. Para esses casos, é aceitável usar uma abordagem mais imperativa, como com ferramentas de linha de comando ou até mesmo abordagens manuais com o portal do Azure.

Implantação de cluster

Depois que o carimbo de cluster é definido, você tem muitas opções para implantar instâncias de carimbo individuais ou múltiplas. Nossa recomendação é usar tecnologia moderna de integração contínua, como GitHub Actions ou Azure Pipelines. Os benefícios das soluções de implantação baseadas em integração contínua incluem:

Implantações baseadas em código que permitem que carimbos sejam adicionados e removidos usando código
Capacidades de teste integradas
Ambiente integrado e capacidades de preparação
Soluções integradas de gestão de segredos
Integração com controle de código-fonte, tanto para código de aplicativo quanto para scripts e modelos de implantação
Histórico e registro em log da implantação
Capacidades de controlo de acesso e auditoria, para controlar quem pode fazer alterações e em que condições

À medida que novos carimbos são adicionados ou removidos do cluster global, o pipeline de implantação precisa ser atualizado para permanecer consistente. Uma abordagem é implantar os recursos de cada região como uma etapa individual dentro de um fluxo de trabalho de Ações do GitHub. Essa configuração é simples porque cada instância de cluster é claramente definida dentro do pipeline de implantação. Essa configuração inclui alguma sobrecarga administrativa na adição e remoção de clusters da implantação.

Outra opção seria criar lógica de negócios para criar clusters com base em uma lista de locais desejados ou outros pontos de dados indicativos. Por exemplo, o pipeline de implantação pode conter uma lista de regiões desejadas; Uma etapa dentro do pipeline poderia então percorrer essa lista, implantando um cluster em cada região encontrada na lista. A desvantagem dessa configuração é a complexidade na generalização da implantação e que cada carimbo de cluster não é explicitamente detalhado no pipeline de implantação. O benefício positivo é que adicionar ou remover carimbos de cluster do pipeline torna-se uma simples atualização da lista de regiões desejadas.

Após a criação de um cluster, ele precisa ser inscrito na frota como um cluster membro. Esta etapa pode ser concluída implantando um recurso do tipo Microsoft.ContainerService/fleets/membersGerenciador de Recursos , que faz referência à ID de recurso do cluster membro. Depois que o cluster de membros é registrado na frota, ele pode ser adicionado para atualizar execuções e usar outros recursos de frota que você configurar.

Além disso, remover um carimbo de cluster do pipeline de implantação nem sempre descomissiona os recursos do carimbo. Dependendo da sua solução de implantação e configuração, você pode precisar de uma etapa extra para encerrar as instâncias do AKS e outros recursos do Azure. Considere usar pilhas de implantação para habilitar o gerenciamento do ciclo de vida completo dos recursos do Azure, incluindo a limpeza quando você não precisar mais deles.

Inicialização de cluster

Depois que cada instância ou carimbo do Kubernetes tiver sido implantado, os componentes do cluster, como controladores de entrada, soluções de identidade e componentes de carga de trabalho, precisam ser implantados e configurados. Talvez seja necessário criar namespaces Kubernetes e também considerar a aplicação de políticas de segurança, acesso e governança em todo o cluster. Essas operações são chamadas de inicialização do cluster para preparar cargas de trabalho que serão implantadas nele.

Semelhante à implantação, as configurações de inicialização podem se tornar difíceis de gerenciar manualmente em várias instâncias do Kubernetes. Se você usar um cluster de hub com o Gerenciador de Frota do Kubernetes do Azure, poderá implantar algumas das configurações de inicialização em toda a frota, como namespaces. No entanto, outros componentes de inicialização exigem uma abordagem de implantação diferente.

Você deve considerar uma das seguintes opções para aplicar a configuração e a política de bootstrap em escala.

GitOps

Em vez de configurar manualmente os componentes do Kubernetes em cada cluster, é recomendável usar métodos automatizados para aplicar configurações a um cluster do Kubernetes, pois essas configurações são verificadas em um repositório de origem. Este processo é muitas vezes referido como GitOps, e as soluções populares de GitOps para Kubernetes incluem Flux e Argo CD. Por exemplo, a extensão Flux para AKS permite inicializar os clusters automaticamente e imediatamente após a implantação dos clusters.

O GitOps é detalhado com mais profundidade na arquitetura de referência de linha de base do AKS. Usando uma abordagem de configuração baseada em GitOps, você garante que cada instância do Kubernetes seja configurada de forma semelhante, sem esforço personalizado. Um processo de configuração simplificado torna-se ainda mais importante à medida que o tamanho da sua frota aumenta.

Você pode usar uma abordagem GitOps para implantar a configuração de cluster base. Você pode inscrever o cluster na frota para participar de atividades de toda a frota, como implementações de atualizações automatizadas.

Você também pode, opcionalmente, usar o GitOps para implantar suas cargas de trabalho. Para saber mais, consulte a seção de implantação de carga de trabalho abaixo.

Política do Azure

À medida que várias instâncias do Kubernetes são adicionadas, o benefício da governança, conformidade e configuração orientadas por políticas aumenta. A utilização de políticas, especificamente a Política do Azure, fornece um método centralizado e escalável para controle de cluster. O benefício das políticas do AKS é detalhado na arquitetura de referência de linha de base do AKS.

A Política do Azure deve ser habilitada quando os clusters AKS são criados. As iniciativas devem ser atribuídas em modo de auditoria para ganhar visibilidade sobre o incumprimento. Você também pode definir mais políticas que não fazem parte de nenhuma iniciativa interna. Essas políticas são definidas no modo Negar. Por exemplo, há uma política em vigor para garantir que apenas imagens de contêiner aprovadas sejam executadas no cluster. Considere criar suas próprias iniciativas personalizadas. Combine as políticas aplicáveis à sua carga de trabalho em uma única atribuição.

O âmbito da política refere-se ao objetivo de cada política e iniciativa política. Você pode usar o Bicep para atribuir políticas ao grupo de recursos no qual cada cluster AKS é implantado. À medida que a pegada do cluster global cresce, isso resulta em muitas políticas duplicadas. Você também pode definir o escopo de políticas para uma assinatura do Azure ou um grupo de gerenciamento do Azure. Esse método permite que você aplique um único conjunto de políticas a todos os clusters AKS dentro do escopo de uma assinatura ou a todas as assinaturas encontradas em um grupo de gerenciamento.

Ao projetar a política para vários clusters AKS, considere os seguintes itens:

Aplique políticas que devem ser aplicadas globalmente a todas as instâncias do AKS a um grupo de gerenciamento ou assinatura.
Coloque cada cluster regional em seu próprio grupo de recursos, o que permite que políticas específicas da região sejam aplicadas ao grupo de recursos.

Consulte Organização de recursos do Cloud Adoption Framework para obter materiais que ajudam a estabelecer uma estratégia de gerenciamento de políticas.

Inscrição de frota

Depois que um cluster é implantado e configurado, você o inscreve na frota como um cluster membro. Cada cluster membro pode ser atribuído a um grupo de atualização, que pode ser usado como parte de uma estratégia de atualização para determinar onde em uma execução de atualização o cluster é atualizado. Para saber mais sobre registro de cluster, grupos e estratégias de atualização, consulte Definir estratégias de atualização reutilizáveis usando o Azure Kubernetes Fleet Manager.

Implantação da carga de trabalho

Cada cluster AKS na sua arquitetura executa aplicações que suportam a sua carga de trabalho. É importante planejar como você implantará e atualizará seus componentes de carga de trabalho de maneira segura e controlada e como manterá a consistência das versões do aplicativo entre cada cluster. Portanto, além da configuração da instância do AKS, considere as cargas de trabalho implantadas em cada instância ou carimbo regional. Suas soluções de implantação ou pipelines exigem configuração para acomodar cada carimbo regional. À medida que mais carimbos são adicionados ao cluster global, o processo de implantação precisa ser estendido ou precisa ser flexível o suficiente para acomodar as novas instâncias regionais.

Há várias abordagens de implantação que você pode considerar, incluindo:

Gasodutos: Para cenários com um pequeno número de clusters e relativamente poucas implantações simples, geralmente é melhor usar pipelines de entrega contínua (CD) dedicados leves.

Um único pipeline normalmente implanta uma carga de trabalho em um ou mais clusters. Essa abordagem minimiza a sobrecarga operacional e permanece gerenciável em ambientes de baixa escala. Ao mudar de um modelo de cluster único para um modelo de poucos clusters, você pode evoluir os pipelines de implantação que já tem em vigor.
Propagação da carga de trabalho do Azure Kubernetes Fleet Manager: A propagação da carga de trabalho da frota simplifica a tarefa de orquestrar definições de carga de trabalho em vários clusters de membros a partir de um plano de controle centralizado. As frotas suportam uma abordagem confiável e escalável para implantações de carga de trabalho, permitindo um grande número de cargas de trabalho e clusters de membros.

A propagação da carga de trabalho requer o uso de um cluster de hub, que é um cluster AKS gerenciado pela Microsoft que ajuda a rastrear o estado esperado de seus clusters membros. Este cluster de hub é um recurso regional. Se uma interrupção regional afetar o cluster de hub, a propagação da carga de trabalho poderá sofrer interrupção temporária.
GitOps: À medida que sua infraestrutura amadurece, adotar uma estratégia baseada em GitOps torna-se cada vez mais benéfico. O GitOps permite mecanismos de implantação declarativos, auditáveis e baseados em pull, oferecendo escalabilidade, governança e colaboração em equipe. A transição para esse modelo é especialmente recomendada ao gerenciar uma frota grande e dinâmica de clusters em várias regiões.

Para saber mais, consulte GitOps for Azure Kubernetes Service.

Para decidir qual abordagem faz sentido para sua solução, considere estas perguntas:

Espera que o número de clusters permaneça fixo ou aumente ao longo do tempo? Se você planeja expandir o número de clusters ou ajustar o número de clusters dinamicamente, pode rapidamente se tornar complicado manter a configuração de cada cluster em seus pipelines de implantação.
Quantas unidades implantáveis você precisa gerenciar? Se você tiver um pequeno número de aplicativos monolíticos, terá apenas um pequeno número de implantações individuais para coordenar. No entanto, se você tiver uma arquitetura baseada em microsserviços distribuídos, um grande número de cargas de trabalho ou ambos. então isso pode crescer rapidamente em centenas de unidades implantáveis. Criar um pipeline para cada implantação pode se tornar inviável.
De que tipo de estratégias de implantação você precisa? As estratégias comuns incluem atualizações contínuas, implantações azul-verde e implantações canárias. Algumas abordagens de implantação devem permitir "tempo de preparação" entre as distribuições, com monitoramento próximo para verificar se há regressões introduzidas pela implantação. Avalie cada abordagem de implantação para determinar se ela suporta seus requisitos específicos.
Em que restrições de segurança de rede seus clusters funcionam? O Azure Kubernetes Fleet Manager opera sob uma topologia de cluster hub-and-spoke, onde os clusters membros mantêm conexões de saída com um cluster de hub central para reconciliação de carga de trabalho e monitoramento de pulsação. Uma estratégia baseada em GitOps requer que os clusters participantes estabeleçam acesso de saída a um repositório Git. Quando você usa pipelines, o agente de pipeline normalmente requer conectividade com cada cluster para executar operações de implantação.

Independentemente de como você orquestrará suas implantações, procure generalizar cada implantação, como com um gráfico Helm, para garantir que uma única configuração de implantação possa ser usada em vários clusters (selos). Além disso, considere como o log de diagnóstico de aplicativos e o rastreamento distribuído podem ser configurados para observabilidade em todo o aplicativo em cada um dos clusters.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para Confiabilidade.

Uma motivação significativa para escolher uma arquitetura Kubernetes multirregião é a disponibilidade do serviço. Ou seja, se um serviço ou componente de serviço ficar indisponível em uma região, o tráfego deve ser roteado para uma região onde outra instância desse serviço ainda esteja disponível. Uma arquitetura de várias regiões inclui muitos pontos de falha diferentes. Nesta seção, cada um desses possíveis pontos de falha é discutido.

Falhas no pod do aplicativo

Um objeto Kubernetes Deployment é usado para criar um ReplicaSet, que gerencia várias réplicas de um pod. Se um pod não estiver disponível, o tráfego será roteado entre os 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 criada automaticamente. As sondas Liveness podem ser usadas para verificar o estado do aplicativo ou processo em execução no pod. Se o serviço 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.

Falhas de hardware do datacenter

Ocasionalmente pode ocorrer falha localizada. Por exemplo, a energia pode ficar indisponível para um único rack de servidores do Azure. Para proteger seus nós AKS de se tornarem um único ponto de falha, use as zonas de disponibilidade do Azure. Usando zonas de disponibilidade, você garante que os nós AKS em uma zona de disponibilidade estejam fisicamente separados dos nós definidos em outra zona de disponibilidade.

Para obter mais informações, consulte Zonas de disponibilidade do AKS e do Azure.

Falhas da região do Azure

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, o Azure Front Door roteia todo o tráfego para as regiões saudáveis restantes. Os clusters e pods do Kubernetes nas regiões saudáveis continuam a atender às solicitações.

Tome cuidado nessa situação para compensar o aumento de solicitações e tráfego para o cluster restante. Considere os pontos seguintes:

Certifique-se de que os recursos de rede e computação estejam no tamanho certo para absorver qualquer aumento repentino no tráfego devido ao failover de região. Por exemplo, ao usar o Azure CNI, verifique se você tem uma sub-rede grande o suficiente para suportar todos os endereços IP do Pod enquanto o tráfego está aumentando.
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.

Para obter mais informações, consulte Horizontal Pod Autoscaler e AKS cluster autoscaler.

Topologia de rede

Semelhante à arquitetura de referência de linha de base AKS, essa arquitetura usa uma topologia de rede hub-spoke. Além das considerações especificadas na arquitetura de referência de linha de base do AKS, considere as seguintes práticas recomendadas:

Implemente um conjunto hub-spoke de redes virtuais para cada instância regional do AKS. Dentro de cada região, cada par falou com a rede virtual do hub.
Encaminhe todo o tráfego de saída por meio de uma instância do Firewall do Azure encontrada em cada rede de hub regional. Utilize as políticas do Gerenciador de Firewall do Azure para gerenciar políticas de firewall em todas as regiões.
Siga o dimensionamento de IP encontrado na arquitetura de referência de linha de base do AKS e permita mais endereços IP para operações de escala de nó e pod caso ocorra uma falha regional em outra região e o tráfego para as regiões restantes aumente substancialmente.

Gestão do tráfego

Com a arquitetura de referência de linha de base do AKS, o tráfego da carga de trabalho é roteado diretamente para uma instância do Gateway de Aplicativo do Azure e, em seguida, encaminhado para o balanceador de carga de back-end e os recursos de entrada do AKS. Quando você trabalha com vários clusters, as solicitações de cliente são roteadas por meio de uma instância do Azure Front Door, que roteia para a instância do Gateway de Aplicativo do Azure.

Diagrama de arquitetura mostrando o tráfego da carga de trabalho na implantação de várias regiões.

Baixe um arquivo do Visio deste diagrama.

O usuário envia uma solicitação para um nome de domínio (como https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), que é resolvido para o perfil da Porta da Frente do Azure. Essa solicitação é criptografada com um certificado curinga (*.azurefd.net) emitido para todos os subdomínios do Azure Front Door. O Azure Front Door valida a solicitação em relação às políticas de firewall do aplicativo Web, seleciona a origem mais rápida (com base na integridade e na latência) e usa o DNS público para resolver o endereço IP de origem (instância do Gateway de Aplicativo do Azure).
O Azure Front Door encaminha a solicitação para a instância apropriada do Gateway de Aplicativo selecionada, que serve como ponto de entrada para o carimbo regional. O tráfego flui através da internet. O Azure Front Door garante que o tráfego para a origem seja criptografado.

Considere um método para garantir que a instância do Application Gateway só aceite tráfego da instância Front Door. Uma abordagem é usar um grupo de segurança de rede na sub-rede que contém o Application Gateway. As regras podem filtrar o tráfego de entrada (ou saída) com base em propriedades como Origem, Porta, Destino. A propriedade Source permite definir uma marca de serviço interna que indica endereços IP para um recurso do Azure. Essa abstração torna mais fácil configurar e manter a regra e manter o controle de endereços IP. Além disso, considere utilizar o X-Azure-FDID cabeçalho, que o Azure Front Door adiciona à solicitação antes de enviá-la para a origem, para garantir que a instância do Application Gateway só aceite tráfego da instância Front Door. Para obter mais informações sobre cabeçalhos de porta frontal, consulte Suporte de protocolo para cabeçalhos HTTP no Azure Front Door.

Considerações sobre recursos compartilhados

Embora o foco desse cenário seja ter várias instâncias do Kubernetes espalhadas por várias regiões do Azure, faz sentido compartilhar alguns recursos em todas as regiões. Uma abordagem é usar um único arquivo Bicep para implantar todos os recursos compartilhados e, em seguida, outra para implantar cada carimbo regional. Esta seção detalha cada um desses recursos compartilhados e considerações para usar cada um em várias instâncias do AKS.

Registro de Contêineres

O Registro de Contêiner do Azure é usado nessa arquitetura para fornecer serviços de imagem de contêiner. O cluster extrai imagens de contêiner do Registro. Considere os seguintes itens ao trabalhar com o Registro de Contêiner do Azure em uma implantação de cluster de várias regiões.

Disponibilidade geográfica

Posicione um registro de contêiner em cada região na qual um cluster AKS é implantado. Essa abordagem permite operações de rede de baixa latência, permitindo transferências de camada de imagem rápidas e confiáveis. Isso também significa que você tem vários pontos de extremidade de serviço de imagem para fornecer disponibilidade quando os serviços regionais não estão disponíveis. Usar a funcionalidade de replicação geográfica do Registro de Contêiner do Azure permite gerenciar um registro de contêiner que é replicado automaticamente para várias regiões.

Considere a criação de um único registro, com réplicas em cada região do Azure que contém clusters. Para obter mais informações sobre a replicação do Registro de Contêiner do Azure, consulte Replicação geográfica no Registro de Contêiner do Azure.

Imagem mostrando várias réplicas do Registro de Contêiner do Azure de dentro do portal do Azure.

Imagem mostrando várias réplicas do Registro de Contêiner do Azure de dentro do portal do Azure.

Acesso ao cluster

Cada cluster AKS requer acesso ao registro de contêiner para que ele possa extrair camadas de imagem de contêiner. Há várias maneiras de estabelecer o acesso ao Registro de Contêiner do Azure. Nessa arquitetura, uma identidade gerenciada é criada para cada cluster, que recebe a AcrPull função no registro do contêiner. Para obter mais informações e recomendações sobre como usar identidades gerenciadas para acesso ao Registro de Contêiner do Azure, consulte a arquitetura de referência de linha de base do AKS.

Essa configuração é definida no arquivo Bicep de carimbo de cluster, de modo que cada vez que um novo carimbo é implantado, a nova instância do AKS recebe acesso. Como o registro de contêiner é um recurso compartilhado, certifique-se de que suas implantações incluam a ID do recurso do registro de contêiner como um parâmetro.

Azure Monitor

Ao projetar uma solução de monitoramento para uma arquitetura de várias regiões, é importante considerar o acoplamento entre cada carimbo. Você pode implantar um único espaço de trabalho do Log Analytics, compartilhado por cada cluster do Kubernetes. Como acontece com os outros recursos compartilhados, defina seu carimbo regional para consumir informações sobre o único espaço de trabalho do Log Analytics compartilhado globalmente e conecte cada cluster regional a esse espaço de trabalho compartilhado. Quando cada cluster regional emite logs de diagnóstico para esse único espaço de trabalho do Log Analytics, você pode usar os dados, juntamente com métricas de recursos, para criar mais facilmente relatórios e painéis que ajudam a entender como toda a sua solução multirregião está sendo executada.

Azure Front Door (porta de entrada do Azure)

O Azure Front Door é usado para balancear a carga e rotear o tráfego para cada cluster AKS. O Azure Front Door também permite o roteamento global da camada 7. Esses recursos são necessários para esse cenário.

Configuração do cluster

À medida que cada instância regional do AKS é adicionada, o Gateway de Aplicativo implantado ao lado do cluster Kubernetes precisa ser registrado como uma origem no Azure Front Door, o que o torna disponível para roteamento. Esta operação requer uma atualização para sua infraestrutura como ativos de código. Como alternativa, essa operação pode ser dissociada da configuração de implantação e gerenciada usando ferramentas como a CLI do Azure.

Certificados

O Azure Front Door não oferece suporte a origens usando certificados autoassinados, mesmo em ambientes de desenvolvimento ou teste. Para habilitar o tráfego HTTPS, você precisa criar seu certificado TLS/SSL assinado por uma autoridade de certificação (CA). Para obter informações sobre outras CAs suportadas pelo Front Door, consulte Autoridades de certificação permitidas para habilitar HTTPS personalizado no Azure Front Door.

Para testes ou clusters que não sejam de produção, você pode considerar o uso do Certbot para criar um certificado Let's Encrypt Authority X3 para cada um dos gateways de aplicativo.

Ao planejar um cluster de produção, use o método preferido da sua organização para adquirir certificados TLS.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design parade segurança .

Controle de acesso ao cluster

Conforme discutido na arquitetura de referência de linha de base do AKS, recomendamos que você use o Microsoft Entra ID como o provedor de identidade para seus clusters. Os grupos do Microsoft Entra podem ser usados para controlar o acesso aos recursos do cluster.

Ao gerenciar vários clusters, você precisa decidir sobre um esquema de acesso. As opções incluem:

Crie um grupo de acesso global em todo o cluster onde os membros possam acessar todos os objetos em cada instância do Kubernetes no cluster. Esta opção fornece necessidades mínimas de administração; no entanto, concede privilégios significativos a qualquer membro do grupo.
Crie um grupo de acesso individual para cada instância do Kubernetes usada para conceder acesso a objetos em uma instância de cluster individual. Com esta opção, as despesas gerais administrativas aumentam; no entanto, ele também fornece acesso a cluster mais granular.
Defina controles de acesso granulares para tipos de objeto e namespaces do Kubernetes e correlacione os resultados a uma estrutura de grupo do Microsoft Entra. Com esta opção, as despesas gerais administrativas aumentam significativamente; no entanto, ele fornece acesso granular não apenas a cada cluster, mas também aos namespaces e APIs do Kubernetes encontrados em cada cluster.

Para acesso administrativo, considere a criação de um grupo do Microsoft Entra para cada região. Conceda a cada grupo acesso total ao carimbo de cluster correspondente nessa região. Os membros de cada grupo têm então acesso administrativo aos clusters correspondentes.

Para obter mais informações sobre como gerenciar o acesso ao cluster do AKS com o ID do Microsoft Entra, consulte Integração do AKS Microsoft Entra.

Segurança dos recursos da sua frota

Quando você usa uma frota para centralizar aspetos do gerenciamento de clusters, é importante proteger os recursos da frota para evitar o uso indevido. Os recursos de frota usam o controle de acesso baseado em função do Azure e você pode conceder permissões de frota a um conjunto restrito de administradores. Siga o princípio do menor privilégio e conceda o menor acesso possível ao recurso da frota (o plano de controle da frota).

Se a sua frota usa um cluster de hub, considere as seguintes recomendações adicionais:

Avalie as atribuições de função criadas no cluster de hub (as atribuições de função do plano de dados ). Essas atribuições de função concedem acesso aos recursos do Kubernetes criados pela frota. Atribuições de função de escopo para um namespace Kubernetes individual sempre que possível.
Use um cluster de hub privado para restringir a conectividade com a Internet. No entanto, certifique-se de que sua arquitetura de rede permita que os clusters membros alcancem o cluster de hub.

Dados, estado e cache

Ao usar um conjunto distribuído globalmente de clusters AKS, considere a arquitetura do aplicativo, processo ou outras cargas de trabalho que possam ser executadas no cluster. Se as cargas de trabalho baseadas em estado estiverem espalhadas pelos clusters, elas precisarão acessar um armazenamento de estado? Se um processo for recriado em outro lugar do cluster devido a uma falha, a carga de trabalho ou o processo continuará a ter acesso a um armazenamento de estado dependente ou a uma solução de cache? O estado pode ser armazenado de várias maneiras, mas é complexo de gerenciar mesmo em um único cluster do Kubernetes. A complexidade aumenta ao adicionar vários clusters do Kubernetes. Devido a preocupações de acesso regional e complexidade, considere projetar seus aplicativos para usar um serviço de armazenamento de estado distribuído globalmente.

O design desta arquitetura não inclui configuração para preocupações de estado. Se você executar um único aplicativo lógico em vários clusters AKS, considere arquitetar sua carga de trabalho para usar um serviço de dados distribuído globalmente, como o Azure Cosmos DB. O Azure Cosmos DB é um sistema de banco de dados distribuído globalmente que permite ler e gravar dados das réplicas locais do seu banco de dados, e o serviço Cosmos DB gerencia a replicação geográfica para você. Para obter mais informações, consulte Azure Cosmos DB.

Se sua carga de trabalho utiliza uma solução de cache, certifique-se de arquitetar seus serviços de cache para que eles permaneçam funcionais mesmo durante eventos de failover. Certifique-se de que a carga de trabalho em si seja resiliente ao failover relacionado ao cache e que as soluções de cache estejam presentes em todas as instâncias regionais do AKS.

Excelência operacional

A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.

Quando você opera um ambiente de vários clusters com um recurso de frota, o monitoramento se torna mais desafiador. Da mesma forma, considere como você coordenará as atualizações para os componentes do cluster AKS.

Monitorar clusters e cargas de trabalho

A revisão manual de painéis e logs pode se tornar difícil à medida que o número de clusters aumenta, portanto, considere como você agregará sistematicamente logs e métricas.

O recurso Azure Monitor Container insights é a ferramenta recomendada para monitorar e entender o desempenho e a integridade de suas cargas de trabalho de cluster e contêiner. O Container insights utiliza um espaço de trabalho do Log Analytics para armazenar dados de log e o Azure Monitor Metrics para armazenar dados numéricos de séries cronológicas. As métricas do Prometheus também podem ser coletadas pelo Container Insights e os dados podem ser enviados para o serviço gerenciado do Azure Monitor para Prometheus ou Azure Monitor Logs. Para obter mais informações, consulte a arquitetura de referência de linha de base do AKS.

Você também pode configurar suas configurações de diagnóstico de cluster AKS para coletar e analisar logs de recursos dos componentes do plano de controle AKS e encaminhá-los para um espaço de trabalho do Log Analytics.

Para saber mais sobre como configurar espaços de trabalho do Azure Monitor em um ambiente de vários clusters, consulte Azure Monitor.

Monitorizar as operações da frota

Quando o Fleet Manager orquestra uma execução de atualização, você pode monitorar o progresso da execução à medida que ela progride nos clusters. Os dados são armazenados no Azure Resource Graph e podem ser exportados para o Azure Monitor para alerta e armazenamento.

Se você optar por usar o Fleet Manager para propagação de carga de trabalho, poderá monitorar a distribuição usando o portal do Azure ou kubectl.

Você também pode coletar logs de recursos do recurso da frota e encaminhá-los para um espaço de trabalho do Log Analytics.

Aplique atualizações em toda a frota

Nesta arquitetura de referência, o Fleet Manager aplica atualizações de versão do Kubernetes e atualizações de imagem de nó em toda a sua frota. Você pode especificar estratégias de atualização que configuram como as atualizações são implementadas em seus clusters. Além disso, o Gestor de Frota respeita as janelas de manutenção em cada cluster, pelo que é uma boa prática definir as janelas de manutenção adequadas a cada cluster. As janelas de manutenção em cada cluster podem ser diferentes quando você usa clusters em várias geografias e, portanto, em fusos horários diferentes.

Para obter mais informações, consulte Atualizar Kubernetes e imagens de nó em vários clusters de membros.

Otimização de Custos

A Otimização de Custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de projeto para Otimização de custos.

Use a calculadora de preços do Azure para estimar os custos dos serviços usados na arquitetura. Outras práticas recomendadas são descritas na seção Otimização de custos no Microsoft Azure Well-Architected Framework e opções específicas de configuração de otimização de custos no artigo Otimizar custos .

Considere habilitar a análise de custos do AKS para alocação granular de custos de infraestrutura de cluster por construções específicas do Kubernetes.