Linha de base do AKS para clusters de várias regiões

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

Essa arquitetura se baseia na arquitetura da linha de base do AKS, o ponto de partida recomendado pela Microsoft para a infraestrutura do AKS. A linha de base do AKS detalha recursos de infraestrutura como o Microsoft Entra Workload ID, 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

Baixe um Arquivo Visio dessa arquitetura.

Componentes

Muitos componentes e serviços do Azure são usados nesta arquitetura do AKS de várias regiões. Somente os componentes com exclusividade para essa arquitetura de vários clusters estão listados aqui. Para o restante, faça referência à arquitetura da 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 mais próxima do usuário que emitiu a solicitação.
• Redes hub-spoke regionais: Um par de rede hub-spoke regional é implantado para cada instância regional do AKS. As políticas do Gerenciador de Firewall do Azure são usadas para gerenciar políticas de firewall em todas as regiões.
• Cofre de chaves regional: o Azure Key Vault é provisionado em cada região. Os cofres de chaves são usados para armazenar valores confidenciais e chaves específicas para o cluster do AKS e dar suporte aos serviços que estão nessa região.
• Vários espaços de trabalho de log: Os espaços de trabalho regionais do Log Analytics são usadas para armazenar métricas de rede regionais 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.
• Perfil global do Azure Front Door: O 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 do AKS. O Azure Front Door permite o roteamento global da camada 7, ambos necessários para essa arquitetura.
• Registro de contêiner global: As imagens de contêiner da carga de trabalho são armazenadas em um registro de contêiner gerenciado. Nesta 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 Registro de Contêiner do Azure permite replicar imagens nas regiões selecionadas do Azure e fornecer acesso contínuo às imagens, mesmo que uma região esteja enfrentando uma interrupção.

Padrões de design

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

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

Considerações sobre o padrão de geodo

Ao selecionar regiões para implantação nas quais cada cluster do AKS será implantado, considere as regiões próximas aos clientes das cargas de trabalho ou seus clientes. Além disso, considere utilizar a replicação entre regiões. A replicação entre regiões replica de modo assíncrono os mesmos aplicativos e dados em outras regiões do Azure para proteção de recuperação de desastre. Conforme o cluster é escalado além de duas regiões, continue planejando a replicação entre regiões para cada par de clusters do AKS.

Em cada região, os nós nos pools de nós do AKS são distribuídos em várias zonas de disponibilidade para ajudar a evitar problemas devido a falhas zonais. Há suporte para zonas de disponibilidade em um conjunto limitado de regiões, o que influencia o posicionamento regional do cluster. Para obter mais informações sobre o AKS e as zonas de disponibilidade, incluindo uma lista de regiões com suporte, confira Zonas de disponibilidade do AKS.

Considerações sobre selo de implantação

Ao gerenciar uma solução do AKS de várias regiões, você implanta vários clusters do AKS em várias regiões. Cada um desses clusters é considerado um carimbo. 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 selos de implantação, será importante considerar o seguinte:

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

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

Gerenciamento de frota

Essa solução representa uma topologia de vários clusters e várias regiões, sem a inclusão de um orquestrador avançado para tratar todos os clusters como parte de uma frota unificada. Quando a contagem de clusters aumentar, considere inscrever os membros no Gerenciador de Frota de Kubernetes do Azure para obter um melhor gerenciamento em escala dos clusters participantes. A arquitetura de infraestrutura apresentada aqui não muda de forma fundamental com a inscrição no Gerenciador de Frota, mas as operações do dia 2 e as atividades semelhantes se beneficiam de um plano de controle que pode atingir vários clusters de forma simultânea.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar 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 do Kubernetes em configurações altamente disponíveis e geograficamente distribuídas, será fundamental considerar a soma de cada cluster do Kubernetes como uma unidade acoplada. Talvez você queira desenvolver estratégias controladas por código para a implantação e a configuração automatizadas a fim de garantir que cada instância do Kubernetes seja a mais idêntica possível. Considere estratégias de expansão e redução, inclusive adicionando ou removendo outros clusters do Kubernetes. Seu design, plano de implantação e configuração devem levar em conta interrupções da zona de disponibilidade, falhas regionais e outros cenários comuns.

Definição do cluster

Você tem muitas opções para implantar um cluster do Serviço de Kubernetes do Azure. O portal do Azure, a CLI do Azure e o módulo do Azure PowerShell são opções adequadas para implantar os clusters de AKS individuais ou não acoplados. No entanto, esses métodos poderão apresentar desafios ao trabalhar-se com muitos clusters de AKS bem 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. Além disso, a implantação e a configuração de muitos clusters usando o portal é um processo demorado que exige 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 da implantação e da recuperação de falhas sua e dos scripts que você criar.

Ao trabalhar com várias instâncias do AKS, recomendamos considerar a infraestrutura como soluções de código, como modelos do Azure Resource Manager, modelos Bicep ou configurações do Terraform. As soluções de infraestrutura como código fornecem uma solução de implantação automatizada, escalonável e idempotente. Por exemplo, é possível usar um arquivo Bicep para os serviços compartilhados da solução e outro para os clusters do AKS e outros serviços regionais. Se você usar a infraestrutura como código, um carimbo de implantação pode ser definido com as 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 desenvolver e manter a infraestrutura como ativos de código pode ser caro. Em alguns casos, a sobrecarga de definir a infraestrutura como código pode superar os benefícios, como quando você tem um número muito pequeno (digamos, 2 ou 3) e inalterável de instâncias do 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 a definição de selo de cluster tiver sido definida, você terá muitas opções para implantar instâncias de carimbo individuais ou múltiplas. Nossa recomendação é usar a tecnologia de integração contínua moderna, como GitHub Actions ou a Azure Pipelines. Os benefícios das soluções de implantação contínuas baseadas em integração incluem:

• Implantações baseadas em código que permitem que selos sejam adicionados e removidos usando código
• Recursos de teste integrados
• Funcionalidades de ambiente e preparo integradas
• Soluções de gerenciamento de segredos integradas
• Integração com o controle do código-fonte, tanto para o código do aplicativo quanto para scripts e modelos de implantação
• Histórico de implantação e registro
• Recursos de controle de acesso e auditoria, para controlar quem pode fazer alterações e em que condições

Conforme novos selos 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 em um fluxo de trabalho do GitHub Actions. Essa configuração é simples porque cada instância do cluster é claramente definida dentro do pipeline de implantação. No entanto, essa configuração inclui alguma sobrecarga administrativa na adição e na 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 indicadores. Por exemplo, o pipeline de implantação pode conter uma lista de regiões desejadas. Uma etapa dentro do pipeline poderia fazer loop por meio dessa 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 selo de cluster não é explicitamente detalhado no pipeline de implantação. O benefício positivo é que adicionar ou remover selos de cluster do pipeline se torna uma atualização simples para a lista de regiões desejadas.

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

Inicialização do cluster

Depois que cada instância ou carimbo do Kubernetes tiver sido implantado, componentes de cluster precisam ser implantados e configurados, como controladores de entrada, soluções de identidade e componentes de carga de trabalho. Você também precisará considerar a aplicação de políticas de segurança, acesso e governança em todo o cluster.

Semelhante à implantação, essas configurações podem se tornar desafiadoras para gerenciar em várias instâncias do Kubernetes manualmente. Em vez disso, considere as seguintes opções de configuração e política em escala.

GitOps

Em vez de configurar manualmente os componentes do Kubernetes, é recomendado usar métodos automatizados para aplicar configurações a um cluster do Kubernetes, já que essas configurações são verificadas em um repositório de origem. Esse processo geralmente é chamado de GitOps e as soluções populares do GitOps para Kubernetes incluem Flux e Argo CD. Por exemplo, a extensão Flux para AKS permite a inicialização dos clusters de forma automática e imediata após a implantação dos clusters.

O GitOps é detalhado com mais detalhamento em Arquitetura de referência de linha de base do AKS. Ao usar uma abordagem baseada em GitOps para configuração você garante que cada instância do Kubernetes seja configurada da mesma forma sem esforço sob medida. Um processo de configuração simplificado torna-se ainda mais importante à medida que o tamanho da sua frota cresce.

Azure Policy

Conforme várias instâncias do Kubernetes são adicionadas, o benefício da governança, conformidade e configuração controladas por políticas aumenta. Utilizar políticas, especificamente o Azure Policy, fornece um método centralizado e escalável para controle de cluster. O benefício das políticas do AKS é detalhado em Arquitetura de referência de linha de base do AKS.

O Azure Policy deve estar habilitado quando os clusters do AKS forem criados. As iniciativas devem ser atribuídas no modo de auditoria para obter visibilidade da não conformidade. Você também pode definir mais políticas que não façam 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 à carga de trabalho em uma única atribuição.

O escopo da política refere-se ao destino 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 do AKS é implantado. Conforme o volume do cluster global aumenta, muitas políticas são duplicadas. Você também pode definir o escopo das políticas para uma assinatura do Azure ou um grupo de gerenciamento do Azure. Esse método permite aplicar um único conjunto de políticas a todos os clusters de AKS dentro do escopo de uma assinatura ou todas as assinaturas encontradas em um grupo de gerenciamento.

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

• Aplique políticas que devem ser aplicadas globalmente a todas as instâncias do AKS em um grupo de gerenciamento ou assinatura.
• Coloque cada cluster regional em seu grupo de recursos 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 ajudarão você a estabelecer uma estratégia de gerenciamento de políticas.

Implantação da carga de trabalho

Além da configuração da instância do AKS, considere a carga de trabalho implantada em cada instância regional ou selo. Soluções de implantação ou pipelines exigirão configuração para acomodar cada selo regional. Conforme mais selos são adicionados ao cluster global, o processo de implantação precisa ser estendido ou flexível o suficiente para acomodar as novas instâncias regionais.

Considere os itens a seguir ao planejar a implantação da carga de trabalho.

• Generalize a implantação, como com um gráfico de Helm, para garantir que uma única configuração de implantação possa ser usada em vários selos de cluster.
• Use um único pipeline de implantação contínua configurado para implantar a carga de trabalho em todos os selos de cluster.
• Forneça detalhes da instância específica do selo como parâmetros de implantação.
• Considere como o log de diagnóstico do aplicativo e o rastreamento distribuído são configurados para a observabilidade em todo o aplicativo.

Disponibilidade e failover

Uma motivação significativa para escolher uma arquitetura do Kubernetes de várias regiões é a disponibilidade do serviço. Ou seja, se um componente de serviço ou um serviço ficar indisponível em uma região, o tráfego deverá ser roteado para uma região em que uma outra instância 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 de implantação do Kubernetes é 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 ReplicaSet do Kubernetes tenta manter o número especificado de réplicas em funcionamento. Se uma instância for inativa, uma nova instância deverá ser recriada automaticamente. As investigações de atividade podem ser usadas para verificar o estado do aplicativo ou o processo em execução no pod. Se o serviço não responder adequadamente, a investigação de atividade removerá o pod, o que forçará o ReplicaSet a criar uma nova instância.

Para obter mais informações, confira ReplicaSet de Kubernetes.

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 os nós do AKS de se tornarem uma falha regional de ponto único, utilize zonas de Disponibilidade do Azure. Ao usar zonas de disponibilidade, você garante que os nós do AKS em uma zona de disponibilidade sejam fisicamente separados daqueles nós definidos em outra zona de disponibilidade.

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

Falhas na 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 às solicitações. Nesse caso, o Azure Front Door roteia todo o tráfego para as regiões íntegras restantes. Os clusters e pods do Kubernetes nas regiões íntegras ​​continuam atendendo às solicitações.

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

• Verifique se os recursos de rede e computação têm o tamanho certo para absorver qualquer aumento repentino no tráfego devido ao failover de região. Por exemplo, ao usar a CNI do Azure, verifique se você tem uma sub-rede grande o suficiente para dar suporte a todos os endereços IP do pod enquanto o tráfego está aumentando.
• Use o Dimensionador Automático de Pod Horizontal para aumentar a contagem de réplicas de pod, a fim de compensar o aumento da demanda regional.
• Use o Dimensionador Automático de Cluster do AKS para aumentar a contagem de nós da instância do Kubernetes, a fim de compensar o aumento da demanda regional.

Para obter mais informações, confira Dimensionador Automático do Pod Horizontal e Dimensionador automático de cluster do AKS.

Topologia de rede

Semelhante à arquitetura de referência de linha de base do AKS, essa arquitetura usa uma topologia de rede hub-spoke. Além das considerações especificadas em 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. Em cada região, emparelhe cada spoke com a rede virtual do hub.
• Roteie todo o tráfego de saída por meio de uma instância de Firewall do Azure encontrada em cada rede de hub regional. As políticas do Gerenciador de Firewall do Azure são usadas 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 você experimente uma falha regional em outra região e o tráfego para as regiões restantes aumente substancialmente.

Gerenciamento de tráfego

Com a arquitetura de referência da linha de base do AKS, o tráfego de carga de trabalho é roteado diretamente para uma instância de Gateway de Aplicativo do Azure e encaminhado para os recursos de entrada do balanceador de carga de back-end/AKS. Ao trabalhar-se 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 Gateway de Aplicativo do Azure.

Baixe um Arquivo do Visio desse diagrama.

1. O usuário envia uma solicitação para um nome de domínio (como, por exemplo, https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), que é resolvido para perfil do Azure Front Door. 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 de aplicativo Web, seleciona a origem mais rápida (com base na integridade e latência) e usa DNS público para resolver o endereço IP de origem (instância do Azure Application Gateway).

2. O Azure Front Door encaminha a solicitação para a instância de Gateway de Aplicativo apropriada selecionada, que serve como o ponto de entrada do selo regional. O tráfego flui pela 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 Gateway de Aplicativo aceite apenas o tráfego da instância do 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 Origem permite definir uma marca de serviço interna que indica endereços IP para um recurso do Azure. Essa abstração facilita a configuração e a manutenção da regra e o controle de endereços IP. Além disso, considere utilizar o cabeçalhoX-Azure-FDID, que o Azure Front Door adiciona à solicitação antes de enviá-la para a origem, para garantir que a instância do Gateway de Aplicativo aceite apenas o tráfego da instância do Front Door. Para obter mais informações sobre cabeçalhos do Front Door, confira Suporte de protocolo para cabeçalhos HTTP no Azure Front Door.

Considerações sobre recursos compartilhados

Embora o foco desse cenário seja o uso de várias instâncias do Kubernetes espalhadas por várias regiões do Azure, faz sentido ter alguns recursos compartilhados em todas as instâncias. Uma abordagem possível é usar um único arquivo Bicep para implantar todos os recursos compartilhados e então outro para implantar cada selo 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êiner

O Registro de Contêiner do Azure é usado nesta arquitetura para fornecer serviços de imagem de contêiner. O cluster extrai imagens de contêiner do registro. Considere os itens a seguir ao trabalhar com 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 do AKS é implantado. Essa abordagem permite operações de rede de baixa latência, possibilitando transferências de camadas 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 estiverem disponíveis. Usar a funcionalidade de replicação geográfica do Registro de Contêiner do Azure permite que você gerencie um registro de contêiner que é replicado automaticamente para várias regiões.

Considere criar um único registro, com réplicas em cada região do Azure que contém clusters. Para obter mais informações sobre replicação do Registro de Contêiner do Azure, confira 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.

Acesso ao cluster

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

ssa configuração é definida no arquivo Bicep do carimbo do cluster, para que cada vez que um novo carimbo for implantado, a nova instância do AKS receba 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

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

Você também pode definir as configurações de diagnóstico de cluster do AKS para coletar e analisar logs de recursos dos componentes do plano de controle do AKS e encaminhar para um espaço de trabalho do Log Analytics.

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 workspace do Log Analytics, compartilhado por cada cluster do Kubernetes. Assim como 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 workspace do Log Analytics, você pode usar os dados, juntamente com as métricas de recursos, para criar relatórios e painéis com mais facilidade que ajudam a entender como toda a solução multirregional está sendo executada.

Porta da frente do Azure

O Azure Front Door é usado para balancear a carga e rotear o tráfego para cada cluster do AKS. O Azure Front Door também habilita o roteamento global de 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 junto com o cluster do Kubernetes precisa ser registrado como uma origem no Azure Front Door, o que o torna disponível para roteamento. Essa operação requer uma atualização para sua infraestrutura como ativos de código. Como alternativa, essa operação pode ser desacoplada da configuração de implantação e gerenciada usando ferramentas como a CLI do Azure.

Certificados

O Azure Front Door não dá 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 AC (autoridade de certificação). Para obter informações sobre outras ACs compatíveis com o Front Door, confira Autoridades de certificado permitidas para habilitar HTTPS personalizado no Azure Front Door.

Para testes ou para clusters de não produção, considere 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 obter certificados TLS.

Acesso e identidade do cluster

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

Ao gerenciar-se vários clusters, é preciso decidir sobre um esquema de acesso. As opções incluem:

• Crie um grupo de acesso global em todo o cluster em que os membros possam acessar todos os objetos em todas as instâncias do Kubernetes no cluster. Essa opção fornece necessidades de administração mínimas. No entanto, concede privilégios significativos a qualquer membro do grupo.
• Crie um grupo de acesso individual para cada instância do Kubernetes que seja usada para conceder acesso a objetos em uma instância de cluster individual. Com essa opção, a sobrecarga administrativa aumenta. No entanto, ele também fornece acesso de cluster mais granular.
• Defina os controles de acesso granulares para tipos de objeto e namespaces do Kubernetes e correlacione os resultados a uma estrutura de grupo Microsoft Entra. Com essa opção, a sobrecarga administrativa aumenta significativamente. No entanto, ele fornece acesso granular não apenas a cada cluster, mas aos namespaces e APIs do Kubernetes encontrados em cada cluster.

Para acesso administrativo, considere criar um grupo do Microsoft Entra para cada região. Conceda a cada grupo acesso total ao selo de cluster correspondente nessa região. Feito isso, os membros de cada grupo terão acesso administrativo aos clusters correspondentes.

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

Dados, estado e cache

Ao usar um conjunto globalmente distribuído de clusters AKS, considere a arquitetura do aplicativo, processo ou outras cargas de trabalho que podem ser executadas no cluster. Se as cargas de trabalho baseadas em estado forem distribuídas 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 repositório de estado dependente ou à 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 aumentará ao adicionar vários clusters do Kubernetes. Devido a preocupações de acesso regional e complexidade, considere criar os aplicativos para usar um serviço de repositório de estado distribuído globalmente.

O design dessa arquitetura não inclui configuração para questões de estado. Se você executar um único aplicativo lógico em vários clusters do 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 banco de dados, e o serviço do Cosmos DB gerencia a replicação geográfica para você. Para obter mais informações, confira Azure Cosmos DB.

Se sua carga de trabalho utilizar 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.

Otimização de custo

Use a calculadora de preços do Azure para estimar os custos para os 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 de configuração específicas de otimização de custos no artigo Otimizar custos .

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

Próximas etapas

• Zonas de disponibilidades do AKS.
• Gerenciador de Frota de Kubernetes do Azure
• Replicação geográfica no Registro de Contêiner do Azure
• Regiões Emparelhadas do Azure

Recursos relacionados

• Revisão do Azure Well-Architected Framework para o Serviço de Kubernetes do Azure (AKS)
• Arquitetura de linha de base de um cluster do AKS (Serviço de Kubernetes do Azure)
• Pipeline de CI/CD para cargas de trabalho baseadas em contêiner
• Integração no Microsoft Entra com o AKS
• Documentação do Azure Front Door
• Documentação do Azure Cosmos DB