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

Essa arquitetura de referência 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 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 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. É recomendável 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.

Uma implementação de referência dessa arquitetura está disponível no GitHub.

Componentes

Muitos componentes e serviços do Azure são usados na arquitetura de referência do AKS de várias regiões. Somente os componentes com exclusividade para essa arquitetura de vários clusters estão listados abaixo. Para o restante, faça referência à arquitetura da Linha de Base do AKS.

• Vários clusters/várias regiões 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.
• rede hub-spoke por região 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.
• Armazenamento de chaves regionais O Cofre de Chaves do Azure é provisionado em cada região para armazenar valores confidenciais e chaves específicas para a instância AKS e serviços de suporte encontrados nessa região.
• 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 sete, ambos necessários para essa arquitetura de referência.
• Log Analytics As instâncias 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.
• Registro de contêiner 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 de referência usa dois padrões de design de nuvem. Nó Geográfico (geodes), em que qualquer região pode atender a qualquer solicitação e Selos de Implantação em que várias cópias independentes de um aplicativo ou componente de aplicativo são implantadas de uma única origem (modelo de implantação).

Considerações de padrão de nó geográfico

Ao selecionar regiões para implantar cada cluster AKS, considere regiões próximas ao consumidor de carga 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. À medida que seu cluster for expandido 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. 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 AKS e zonas de disponibilidade, incluindo uma lista de regiões suportadas, consulte Zonas de disponibilidade do AKS.

Considerações sobre selo de implantação

Ao gerenciar um cluster AKS de várias regiões, várias instâncias do AKS serão implantadas em várias regiões. Cada uma dessas instâncias é considerada um carimbo. No caso de uma falha regional ou da necessidade de adicionar mais capacidade e/ou presença regional para o cluster, 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, como 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
• Conforme os selos são adicionados e removidos da coleção, considere as preocupações de capacidade e custo
• Considere como ganhar 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 dessa arquitetura de referência.

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 Azure Kubernetes Fleet Manager para um melhor gerenciamento em escala dos clusters participantes. A arquitetura de infraestrutura apresentada aqui não muda fundamentalmente com a inscrição no Fleet Manager, mas as operações do dia 2 e atividades semelhantes se beneficiam de um plano de controle que pode atingir vários clusters simultaneamente.

Considerações

Essas 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, confira 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 distribuídas geograficamente, é 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 a mais idêntica possível. Você vai querer considerar estratégias para expandir para fora e para dentro, adicionando ou removendo outras instâncias do Kubernetes. Você desejará que seu design e plano de implantação e configuração levem em conta falhas regionais ou 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 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. Além disso, a implantação e a configuração de muitos clusters usando o portal é um processo oportuno que exige o foco de um ou mais engenheiros. Você pode 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 muitas 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. Essa arquitetura de referência inclui um modelo do ARM para os serviços compartilhados de soluções e outro para os clusters do AKS + 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 desenvolver e manter a infraestrutura como ativos de código pode ser caro. Em alguns casos, como quando um número estático/fixo de instâncias AKS é implantado, a sobrecarga da infraestrutura como código pode superar os benefícios. Para esses casos, é possível usar uma abordagem mais imperativa, como com ferramentas de linha de comando ou até mesmo uma abordagem manual.

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 baseadas em integração contínua 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 controle do código-fonte de implantação/código
• Histórico de implantação e registro

À medida que novos carimbos são adicionados ou removidos do cluster global, o pipeline de implantação precisa ser atualizado para permanecer consistente. Na implementação de referência, cada região é implantada como uma etapa individual dentro de um fluxo de trabalho de Ação do GitHub (exemplo). Essa configuração é simples porque cada instância do 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 utilizar a lógica para criar clusters com base em uma lista de locais desejados ou em outros pontos de dados que indicam. 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 carimbo 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 não garante necessariamente que ele também seja desativado. Dependendo da solução de implantação e da configuração, talvez seja necessária uma etapa extra para garantir que as instâncias do AKS tenham sido desativadas adequadamente.

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, considere o uso de 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. Esse processo geralmente é chamado de GitOps e as soluções populares do GitOps para Kubernetes incluem Flux e Argo CD. Essa implementação usa a extensão Flux para AKS para habilitar a inicialização dos 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. O ponto importante aqui é que o uso de uma abordagem baseada em GitOps para configuração ajuda a garantir que cada instância do Kubernetes seja configurada de forma semelhante, sem esforço personalizado. Isso se torna 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. Utilizando políticas, a Política do Azure especificamente, fornece um método centralizado e escalonável para controle de cluster. O benefício das políticas AKS é detalhado na arquitetura de referência de linha de base AKS.

O Azure Policy é habilitado nesta implementação de referência quando os clusters do AKS são criados e atribui a iniciativa restritiva no modo auditoria para obter visibilidade sobre a não conformidade. A implementação também define 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 à 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. A implementação de referência associada a essa arquitetura usa um modelo do ARM para atribuir políticas ao grupo de recursos no qual cada cluster do 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 e/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:

• Políticas que devem ser aplicadas globalmente a todas as instâncias do AKS podem ser aplicadas a um grupo de gerenciamento ou assinatura
• Colocar 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. À medida que mais carimbos 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 esse serviço 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.

Pods de aplicativo (regional)

Um objeto de implantação do Kubernetes é usado para criar várias réplicas de um pod (ReplicaSet). Se um 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 execução. Se uma instância for inativa, uma nova instância deverá ser recriada. Por fim, 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, o teste de vivacidade removerá o pod, o que força o ReplicaSet a criar uma nova instância.

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

Pods de aplicativo (global)

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, a instância do Azure Front Door roteia todo o tráfego para as regiões íntegras restantes. Os clusters e pods do Kubernetes nessas regiões continuarão a atender às solicitações.

Tome cuidado nessa situação para compensar o aumento do tráfego/solicitações para o cluster restante. Algumas coisas para levar em consideração:

• 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 o CNI do Azure, verifique se você tem uma sub-rede que pode dar suporte a todos os IPs do Pod com uma carga de tráfego em pico.
• Utilize o Dimensionador Automático do Pod Horizontal para aumentar a contagem de réplicas de pod para compensar o aumento da demanda regional.
• Utilize o Dimensionador Automático de Cluster do AKS para aumentar a contagem de nós da instância do Kubernetes para 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.

Pools de nós do Kubernetes (regional)

Ocasionalmente, uma falha localizada pode ocorrer para calcular recursos, por exemplo, se a energia 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. Usar zonas de disponibilidade garantirá que os nós AKS em uma determinada zona de disponibilidade sejam separados fisicamente dos definidos em outra zona de disponibilidade.

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

Pools de nós do Kubernetes (regional)

Em uma falha regional completa, o Azure Front Door roteará o tráfego para as regiões restantes e íntegras. Tome cuidado nessa situação para compensar o aumento do tráfego/solicitações para o cluster restante.

Para obter mais informações, confira Azure Front Door.

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 hub-spoke para cada instância regional do AKS, em que as redes virtuais hub-spoke são emparelhadas.
• 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 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, se ocorrer uma falha regional.

Gerenciamento de tráfego

Com a arquitetura de referência de linha de base AKS, o tráfego de carga de trabalho é roteado diretamente para uma instância do Gateway de Aplicativo do Azure e, em seguida, encaminhado para os recursos de entrada do balanceador de carga de back-end / AKS. Quando você trabalha com vários clusters, as solicitações do 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.

Baixe um arquivo do Visio deste diagrama.

1. O usuário envia uma solicitação para um nome de domínio (como https://contoso-web.azurefd.net), que é resolvido para a instância do Azure Front Door. Essa solicitação é criptografada com um certificado curinga (*.azurefd.net) emitido para todos os subdomínios do Azure Front Door. A instância do Azure Front Door valida a solicitação em relação às políticas de WAF, seleciona o back-end mais rápido (com base na integridade e latência) e usa o DNS público para resolver o endereço IP de back-end (instância do Gateway de Aplicativo do Azure).

2. O 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 e é criptografado pelo Azure Front Door. 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 Gateway de Aplicativo. 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 Front Door para o cabeçalho X-Azure-FDID de back-end 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 dessa arquitetura de referência esteja em ter 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. A implementação de referência de várias regiões do AKS usando um único modelo do ARM para implantar todos os recursos compartilhados e 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 de referência para fornecer serviços de imagem de contêiner (pull). 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

Posicionar um registro de contêiner em cada região em que um cluster do AKS é implantado permitirá operações de fechamento de rede, permitindo transferências rápidas e confiáveis de camada de imagem. Tenha vários pontos de extremidade de serviço de imagem para fornecer disponibilidade quando os serviços regionais não estiverem disponíveis. O uso da funcionalidade de replicação geográfica dos Registros de Contêiner do Azure permite que você gerencie uma instância do Registro de Contêiner replicada para várias regiões.

A implementação de referência de várias regiões do AKS criou uma única instância do Registro de Contêiner e réplicas dessa instância em cada região do cluster. 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 ACR de dentro do portal do Azure.

Acesso ao cluster

Cada instância do AKS requer acesso para extrair camadas de imagem do Registro de Contêiner do Azure. Há várias maneiras de estabelecer o acesso ao Registro de Contêiner do Azure. Essa arquitetura de referência usa uma Identidade Gerenciada do Azure para cada cluster, que recebe a função AcrPull na instância do Registro de Contêiner. Para obter mais informações e recomendações sobre como usar identidades gerenciadas para acesso ao Registro de contêiner, consulte a arquitetura de referência de linha de base do AKS.

Essa configuração é definida no modelo ARM de selo de cluster para que a nova instância do AKS tenha acesso cada vez que um novo selo for implantado. Como o Registro de Contêiner é um recurso compartilhado, verifique se o modelo de selo de implantação pode consumir e usar os detalhes necessários. Nesse caso, a ID do recurso do Registro de Contêiner.

Azure Monitor

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 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érie temporal. As métricas do Prometheus também podem ser coletadas pelo Container Insights e enviar os dados para o serviço gerenciado do Azure Monitor para Prometheus ou para os Logs do Azure Monitor.

Você também pode definir as configurações de diagnóstico do cluster 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.

AKS Para obter mais informações, consulte a arquitetura de referência de linha de base do AKS.

Ao considerar o monitoramento para uma implementação entre regiões como essa arquitetura de referência, é importante considerar o acoplamento entre cada carimbo. Nesse caso, considere cada selo como um componente de uma única unidade (cluster regional). A implementação de referência do AKS de várias regiões utiliza um único workspace 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 e conectar cada cluster a ele.

Agora que cada cluster regional está emitindo logs de diagnóstico para um único espaço de trabalho do Log Analytics, esses dados, juntamente com as métricas de recursos, podem ser usados para criar mais facilmente relatórios e painéis que representam a totalidade do cluster global.

Azure Front Door

O Azure Front Door é usado para balancear a carga e rotear o tráfego para cada cluster do AKS. O Azure Front Door permite o roteamento global da camada sete, ambos necessários para essa arquitetura de referência.

Configuração do cluster

Conforme as instâncias do AKS regional são adicionadas, o Gateway de Aplicativo implantado junto com o cluster do Kubernetes precisa ser registrado como um back-end do Front Door para roteamento adequado. 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 com ferramentas como a CLI do Azure. O pipeline de implantação de implementações de referência incluído utiliza uma etapa diferente da CLI do Azure para essa operação.

Certificados

O Front Door não oferece suporte a certificados autoassinados, mesmo em ambientes de desenvolvimento/teste. Para habilitar o tráfego HTTPS, você precisa criar seu certificado TLS/SSL assinado por uma AC (autoridade de certificação). A implementação de referência usa o Certbot para criar um certificado Let's Encrypt Authority X3. Ao planejar um cluster de produção, use o método preferido da sua organização para obter certificados TLS.

Para obter informações sobre outras CAs que o Front Door suporta, consulte Autoridades de certificação permitidas para habilitar HTTPS personalizado no Azure Front Door.

Acesso e identidade do cluster

Conforme discutido na arquitetura de referência de linha de base do AKS, é recomendável usar o Microsoft Entra ID como provedor de identidade de acesso dos clusters. Os grupos do Microsoft Entra podem ser usados para controlar o acesso aos recursos do cluster.

Ao gerenciar vários clusters, você precisará 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 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 controles de acesso granular para tipos de objeto e namespaces do Kubernetes e correlacione os resultados a uma estrutura de Grupo de Diretórios do Azure. 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.

Com a implementação de referência incluída, dois grupos do Microsoft Entra são criados para acesso de administrador. Esses grupos são especificados na hora de implantação do selo de cluster usando o arquivo de parâmetro de implantação. Os membros de cada grupo têm acesso total ao selo do cluster correspondente.

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

Dados, estado e cache

Ao usar um cluster distribuído globalmente de instâncias do AKS, considere a arquitetura do aplicativo, do processo ou de outras cargas de trabalho que podem ser executadas em todo o cluster. Como a carga de trabalho baseada em estado é distribuída pelo cluster, será necessário acessar um repositório 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 alcançado de várias maneiras. No entanto, ele pode ser complexo em um único cluster do Kubernetes. A complexidade aumentará ao adicionar várias instâncias do Kubernetes clusterizados. Devido a questões de acesso regional e complexidade, considere projetar seus aplicativos para usar um serviço de armazenamento de estado distribuído globalmente.

A implementação de referência de vários clusters não inclui uma demonstração ou configuração para preocupações de estado. Se você executar aplicativos em instâncias AKS clusterizadas, 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 os dados das réplicas locais do banco de dados. Para obter mais informações, confira Azure Cosmos DB.

Se sua carga de trabalho utilizar uma solução de cache, certifique-se de que ela seja arquitetada para que os serviços de cache permaneçam funcionais. Para fazer isso, verifique se a carga de trabalho em si é resiliente ao failover relacionado ao cache e se as soluções de cache estão 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 .

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

Próximas etapas

• Zonas de disponibilidade do AKS
• Azure Kubernetes Fleet Manager
• 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 com AKS Microsoft Entra
• Documentação do Azure Front Door
• Documentação do Azure Cosmos DB