Arquitetura de linha de base de um cluster do AKS (Serviço de Kubernetes do Azure)

Este artigo fornece uma arquitetura de referência básica recomendada para a implantação de um cluster do Serviço de Kubernetes do Azure (AKS). Ele usa nossos princípios de design e se baseia nas melhores práticas de arquitetura do AKS do Azure Well-Architected Framework. Este artigo ajuda a orientar vários grupos interdisciplinares distintos, como equipes de sistemas de rede, segurança e identidade, quando eles implantam essa infraestrutura de uso geral.

Essa arquitetura não se concentra em uma carga de trabalho. Ela se concentra no próprio cluster do AKS. Essas informações são as recomendações básicas mínimas para a maioria dos clusters do AKS. A arquitetura se integra aos serviços do Azure que oferecem observabilidade, fornecem uma topologia de rede que acompanha o crescimento entre várias regiões e protegem o tráfego no cluster.

Os requisitos de negócios influenciam a arquitetura de destino e podem variar entre diferentes contextos de aplicação. Considere a arquitetura como ponto de partida para as etapas de pré-produção e produção.

O Kubernetes é um ecossistema poderoso que se estende além das tecnologias do Azure e da Microsoft. Ao implantar um cluster do AKS, você assume a responsabilidade por várias decisões sobre como o cluster deve ser projetado e operado. A execução de um cluster do AKS envolve uma combinação de componentes de software livre de vários fornecedores, incluindo a Microsoft, além de componentes de código aberto do ecossistema Kubernetes. O cenário muda com frequência e pode ser necessário reconsiderar as decisões regularmente. Ao adotar o Kubernetes, você reconhece que a carga de trabalho precisa de recursos e que a equipe de carga de trabalho está preparada para investir continuamente.

Você pode usar uma implementação dessa arquitetura no GitHub: implementação de referência de linha de base do AKS. Use-a como ponto de partida alternativo e configure a arquitetura de referência de acordo com suas necessidades.

Configuração de rede

Topologia de rede
Planejar os endereços IP
implantar recursos de entrada

Computação do cluster

Computação para o cluster base
Referência de imagem de contêiner
Gerenciamento de política

Gerenciamento de identidades

Integrar o Microsoft Entra ID para o cluster
Integração do Microsoft Entra ID para a carga de trabalho

Fluxo de dados seguro

Proteger o fluxo de rede
Adicionar o gerenciamento de segredos

Continuidade de negócios

Escalabilidade
Disponibilidade de cluster e nó
Disponibilidade e suporte a várias regiões

Operações

Pipelines de CI/CD de cluster e carga de trabalho
Métricas e integridade de cluster
Gerenciamento de custos e relatórios

Topologia de rede

Essa arquitetura usa uma topologia de rede hub e spoke. Implante o hub e spokes em redes virtuais separadas que são conectadas por meio de emparelhamento de rede virtual. Essa topologia apresenta várias vantagens. Use esta topologia para:

• Habilitar o gerenciamento segregado. Você pode aplicar a governança e aderir ao princípio do menor privilégio. Também dá suporte ao conceito de uma Zona de destino do Azure com separação de tarefas.

• Minimizar a exposição direta de recursos do Azure à Internet pública.

• Fornecer topologias regionais de hub e spoke. Futuramente, você pode expandir as topologias de rede hub e spoke e fornecer isolamento de carga de trabalho.

• Usar um serviço de Firewall de Aplicativo Web para ajudar a inspecionar o fluxo de tráfego HTTP para todos os aplicativos Web.

• Fornecer suporte para cargas de trabalho que abrangem várias assinaturas.

• Tornar a arquitetura extensível. Para comportar novos recursos ou cargas de trabalho, você pode adicionar novos spokes em vez de reprojetar a topologia de rede.

• Dar suporte ao compartilhamento de recursos, como firewall e zonas DNS (Sistema de Nomes de Domínio), entre redes.

• Alinhar com a zona de destino em escala empresarial do Azure.

Baixe um Arquivo Visio dessa arquitetura.

Para obter mais informações, confira Topologia de rede hub-spoke no Azure.

Para obter mais informações sobre as alterações de design de rede incluídas nos contêineres do Windows na arquitetura de referência de linha de base do AKS, consulte Contêineres do Windows no AKS.

Rede virtual de hub

A rede virtual do hub é o ponto central de conectividade e observabilidade. Nessa arquitetura, o hub contém:

• Um Firewall do Azure com políticas globais de firewall definidas pelas equipes centrais de TI para impor a política de firewall em toda a organização.
• Azure Bastion para acesso remoto a máquinas virtuais (VMs).
• Uma sub-rede de gateway para conectividade VPN.
• Azure Monitor para observabilidade de rede.

Na rede, a arquitetura tem três sub-redes.

Sub-rede para hospedar o Firewall do Azure

O Firewall do Azure é um serviço de firewall gerenciado. A instância de Firewall do Azure protege o tráfego de rede de saída. Sem essa camada de segurança, o tráfego pode se comunicar com um serviço mal-intencionado de terceiros que pode exfiltrar dados confidenciais da carga de trabalho. Use o Gerenciador de Firewall do Azure para implantar e configurar de forma centralizada várias instâncias do Firewall do Azure e gerenciar as políticas do Firewall do Azure para esse tipo de arquitetura de rede virtual de hub.

Sub-rede para hospedar um gateway

Essa sub-rede é um espaço reservado para um gateway de VPN ou o Azure ExpressRoute. O gateway fornece conectividade entre os roteadores em sua rede local e a rede virtual.

Sub-rede para hospedar o Azure Bastion

Essa sub-rede é um espaço reservado para o Azure Bastion. É possível usar o Azure Bastion para acessar com segurança os recursos do Azure sem expô-los à Internet. Essa sub-rede é usada apenas para gerenciamento e operações.

Rede virtual spoke

A rede virtual spoke contém o cluster do AKS e outros recursos relacionados. O spoke tem as seguintes sub-redes.

Sub-rede para hospedar Gateway de Aplicativo do Azure

O Gateway de Aplicativo é um balanceador de carga do tráfego da Web que opera na Camada 7. A implementação de referência usa o SKU do Gateway de Aplicativo v2 que habilita o Firewall de Aplicativo Web do Azure. O Firewall de Aplicativo Web protege o tráfego de entrada contra ataques comuns de tráfego da Web, incluindo bots. A instância tem uma configuração de IP de front-end público que recebe solicitações de usuário. Por padrão, o Gateway de Aplicativo exige uma sub-rede dedicada.

Sub-rede para hospedar os recursos de entrada

Para rotear e distribuir o tráfego, Traefik é o controlador de entrada que atenderá aos recursos de entrada do Kubernetes. Os balanceadores de carga internos do Azure existem nessa sub-rede. Para obter mais informações, consulte Usar um Load Balancer interno com AKS.

Sub-rede para hospedar os nós de cluster

O AKS mantém dois pools de nós, que são grupos separados de nós. O pool de nós do sistema hospeda pods que executam os principais serviços de cluster. O pool de nós de usuário executa sua carga de trabalho e o controlador de entrada para permitir a comunicação de entrada com a carga de trabalho.

Sub-rede para hospedar pontos de extremidade de Link privado do Azure

Crie conexões de Link privado para o Registro de Contêiner do Azure e o Azure Key Vault para que os usuários possam acessar esses serviços usando um ponto de extremidade privado da rede virtual spoke. Pontos de extremidade privados não exigem uma sub-rede dedicada. Você também pode colocar pontos de extremidade privados na rede virtual hub. Na implementação da linha de base, os pontos de extremidade são implantados em uma sub-rede dedicada na rede virtual spoke. Essa abordagem reduz o tráfego que passa pela conexão de rede emparelhada. Ela mantém os recursos que pertencem ao cluster na mesma rede virtual. Você também pode aplicar regras de segurança granulares no nível da sub-rede usando grupos de segurança de rede.

Para obter mais informações, veja as Opções de implantação do link privado.

Planejar os endereços IP

Baixe um Arquivo Visio dessa arquitetura.

Essa arquitetura de referência usa várias abordagens de rede, cada uma exigindo um espaço de endereço IP:

• Sua rede virtual do Azure, que é usada para recursos como nós de cluster, pontos de extremidade privados e Gateway de Aplicativo.
• O cluster usa a Sobreposição de CNI do Azure, que aloca endereços IP para pods de um espaço de endereço separado para a rede virtual do Azure.

Espaço de endereço IP da rede virtual

O espaço de endereço da rede virtual do Azure precisa ser grande o suficiente para conter todas as suas sub-redes. Além de responder por todas as entidades que recebem tráfego. O Kubernetes aloca os endereços IP dessas entidades no espaço de endereço da sub-rede. Considere esses pontos ao planejar os endereços IP da rede virtual do Azure.

• Atualizações: o AKS atualiza os nós com regularidade para garantir que as máquinas virtuais subjacentes tenham os recursos de segurança e os patches do sistema mais recentes. Durante o processo de atualização, o AKS cria um nó que hospeda temporariamente os pods, ao passo que o nó de atualização é isolado e esvaziado. Esse nó temporário recebe um endereço IP da sub-rede do cluster. Verifique se você tem espaço de endereço suficiente para esses endereços IP de nó temporário.

  Nessa arquitetura, os pods recebem endereços IP de dentro do espaço de endereço do pod de Sobreposição CNI do Azure, inclusive durante atualizações sem interrupção. Essa abordagem reduz o número geral de endereços IP usados da rede virtual do Azure em comparação com outras abordagens de rede do Kubernetes.

• Escalabilidade: pense no número de nós de todo o sistema, bem como nos nós de sistema e usuário e seus limites máximos de escalabilidade. Imagine que você quer escalar horizontalmente em 400%. Serão necessários quatro vezes o número de endereços para todos esses nós expandidos.

  Como essa arquitetura usa a Sobreposição de CNI do Azure, a escalabilidade dos pods não afeta o espaço de endereço da rede virtual.

• Endereços de Link Privado: considere os endereços necessários para a comunicação com outros serviços do Azure pelo Link Privado. Essa arquitetura tem dois endereços atribuídos aos links para o Registro de Contêiner do Azure e o Key Vault.

• Endereços IP reservados: o Azure reserva alguns endereços para uso próprio. e não podem ser atribuídos.

Essa lista não é exaustiva. Se o design tiver outros recursos que afetam o número de endereços IP disponíveis, inclua esses endereços.

Essa arquitetura é projetada para uma única carga de trabalho. Em um cluster de produção do AKS, sempre separe o pool de nós do sistema do pool de nós do usuário. Ao executar várias cargas de trabalho no cluster, pode ser interessante isolar os pools de nós do usuário uns dos outros. Fazer isso resulta em mais sub-redes com um tamanho menor. Além disso, o recurso de entrada pode ser mais complexo e, como resultado, talvez você precise ter vários controladores de entrada que exigem endereços IP extras.

Espaço de endereços IP do pod

A Sobreposição de CNI do Azure atribui endereços IP a pods usando um espaço de endereço dedicado, que é separado do espaço de endereço que você usa em sua rede virtual. Use um espaço de endereço IP que não se sobreponha à rede virtual ou a nenhuma rede virtual emparelhada. No entanto, se você criar vários clusters do AKS, poderá usar com segurança o mesmo espaço de endereço do pod em cada cluster.

Cada nó recebe um espaço de endereço /24 para seus pods, portanto, é importante garantir que o espaço de endereço do pod seja suficientemente grande para permitir quantos blocos /24 forem necessários para o número de nós no cluster. Lembre-se de incluir todos os nós temporários criados durante atualizações ou operações de expansão. Por exemplo, se você usar um espaço de endereço /16 para seu intervalo CIDR, o cluster poderá crescer para um máximo de cerca de 250 nós.

Cada nó suporta até 250 pods, e esse limite inclui todos os pods criados temporariamente durante as atualizações.

Para obter mais informações, confira as diretrizes sobre o planejamento de endereços IP para a Sobreposição de CNI do Azure

Outras considerações sobre o espaço de endereço IP

Para ver a lista completa de considerações de rede sobre essa arquitetura, confira a Topologia de rede de linha de base do AKS. Para saber mais sobre o planejamento de endereços IP de um cluster do AKS, confira Planejar o endereçamento IP para o cluster.

Para obter mais informações sobre as considerações de planejamento de endereço IP incluídas nos contêineres do Windows na arquitetura de referência de linha de base do AKS, consulte Contêineres do Windows no AKS.

Complementos e versões prévias dos recursos

Kubernetes e AKS estão em constante evolução e têm ciclos de lançamento mais rápidos do que o software para ambientes locais. Essa arquitetura básica depende de algumas versões prévias de recursos do AKS e complementos do AKS. Veja a seguir a diferença entre as duas:

• A equipe do AKS descreve a versão prévia do recurso como enviados e aprimorados porque muitas das versões prévias do recursos permanecem nesse estado por apenas alguns meses antes de passar para a fase de GA (disponibilidade geral).

• Os complementos e extensões do AKS fornecem funcionalidades adicionais compatíveis. O AKS gerencia a instalação, a configuração e o ciclo de vida deles.

Essa arquitetura de linha de base não inclui todas as versões prévias de recurso ou complemento. Em vez disso, ele inclui apenas aqueles que agregam valor significativo a um cluster de uso geral. À medida que esses recursos saem da versão prévia, essa arquitetura básica passa por uma revisão adequada. Há algumas outras versões prévias do recurso ou complementos do AKS que talvez você queira avaliar em clusters de pré-produção. Esses recursos podem melhorar sua segurança, capacidade de gerenciamento ou outros requisitos. Com complementos de terceiros, você deve instalá-los e mantê-los, incluindo o rastreamento de versões disponíveis e a instalação de atualizações após o upgrade da versão do Kubernetes de um cluster.

Referência de imagem de contêiner

Além da carga de trabalho, o cluster pode conter diversas outras imagens, como o controlador de entrada. Algumas dessas imagens podem residir em registros públicos. Considere estes pontos ao efetuar pull das imagens para o cluster.

• Autentique o cluster para efetuar pull da imagem.

• Importe uma imagem pública para o registro de contêiner que se alinhe ao seu SLO (objetivo de nível de serviço), se você estiver usando uma imagem pública. Caso contrário, a imagem pode ficar sujeita a problemas inesperados de disponibilidade. Se a imagem não estiver disponível quando necessário, isso pode causar problemas operacionais. Veja aqui alguns benefícios de usar um registro de contêiner privado, como o Registro de Contêiner do Azure, em vez de um registro público:

  • É possível bloquear o acesso não autorizado às suas imagens.
  • Você não tem dependências públicas.
  • É possível acessar logs de pull de imagem para monitorar atividades e triar problemas de conectividade.
  • É possível aproveitar a verificação integrada de contêiner e a conformidade de imagem.

• Extraia imagens de registros autorizados. Você pode impor essa restrição por meio de Azure Policy. Nessa implementação de referência, o cluster só efetua pull de imagens da instância do Registro de Contêiner que é implantada.

Configurar a computação para o cluster base

No AKS, cada pool de nós mapeia um conjunto de dimensionamento de máquinas virtuais, Os nós são VMs em cada pool de nós. Considere usar um tamanho de VM menor para o pool de nós do sistema a fim de minimizar os custos. Esta implementação de referência implanta o pool de nós do sistema com três nós DS2_v2. Esse tamanho é suficiente para atender à carga esperada dos pods do sistema. O disco do sistema operacional tem 512 GB.

Veja algumas considerações sobre o pool de nós do usuário:

• Escolha tamanhos de nó maiores para empacotar o número máximo de pods definidos em um nó. Nós grandes minimizam o volume de serviços executados em todos os nós, como monitoramento e registro.

• Selecione o tipo de máquina virtual apropriado se você tiver requisitos de carga de trabalho específicos. Por exemplo, você pode precisar de um produto otimizado para memória para algumas cargas de trabalho ou um produto acelerado por GPU para outras. Para obter mais informações, confira Tamanhos das máquinas virtuais no Azure.

• Implante pelo menos dois nós. Dessa forma, a carga de trabalho tem um padrão de alta disponibilidade com duas réplicas. Com o AKS, é possível alterar o número de nós sem recriar o cluster.

• Planeje os tamanhos reais do nó para a carga de trabalho com base nos requisitos determinados pela equipe de design. Com base nos requisitos de negócios, essa arquitetura usa DS4_v2 para a carga de trabalho de produção. Para reduzir os custos, você pode reduzir o tamanho para DS3_v2, que é a recomendação mínima.

• Suponha que sua carga de trabalho consuma até 80% de cada nó ao planejar a capacidade do cluster. Os 20% restantes são reservados para serviços do AKS.

• Defina o máximo de pods por nó com base no planejamento da capacidade. Se você estiver tentando estabelecer uma linha de base de capacidade, comece com um valor de 30. Ajuste esse valor com base nos requisitos da carga de trabalho, no tamanho do nó e nas restrições de IP.

Selecionar um sistema operacional

A maioria dos clusters do AKS usa o Linux como o sistema operacional para seus pools de nós. Nesta implementação de referência, usamos o Linux do Azure, que é uma distribuição Linux leve e protegida que foi ajustada para o Azure. Você poderá optar por usar outra distribuição do Linux, como o Ubuntu, se preferir ou se tiver requisitos que o Linux do Azure não pode atender.

O AKS também dá suporte a pools de nós que executam o sistema operacional Windows Server. Há requisitos especiais para alguns aspectos de um cluster que executa o Windows. Para saber mais sobre a arquitetura do pool de nós do Windows, confira Executar contêineres do Windows no AKS.

Se você tiver uma carga de trabalho composta por uma mistura de tecnologias, poderá usar sistemas operacionais diferentes em pools de nós diferentes. No entanto, se você não precisar de sistemas operacionais diferentes para a carga de trabalho, recomendamos usar um único sistema operacional para todos os pools de nós da carga de trabalho.

Integrar o Microsoft Entra ID para o cluster

É fundamental proteger o acesso no cluster; Pense nessa perspectiva ao fazer escolhas sobre a segurança:

• Acesso interno. Considere o acesso do AKS a componentes do Azure, como infraestrutura de rede, Registro de Contêiner do Azure e Key Vault. Autorize somente os recursos aos quais o cluster tem acesso permitido.
• Acesso externo. Forneça acesso de identidades ao cluster do Kubernetes. Autorize apenas as entidades externas que têm acesso permitido ao servidor de API do Kubernetes e ao Azure Resource Manager.

Acesso do AKS ao Azure

Existem duas maneiras de gerenciar o AKS para acesso ao Azure por meio do Microsoft Entra ID: entidades de serviço ou identidades gerenciadas para os recursos do Azure.

Dos dois métodos para gerenciar o acesso do AKS ao Azure, recomendamos identidades gerenciadas. Com as entidades de serviço, você deve gerenciar e alternar segredos, manual ou programaticamente. Com identidades gerenciadas, o Microsoft Entra ID gerencia e executa a autenticação e a alternância adequada de segredos para você.

Recomendamos habilitar e usar as identidades gerenciadas para que o cluster possa interagir com recursos externos do Azure por meio do Microsoft Entra ID. Mesmo que você não use a integração do Microsoft Entra ID imediatamente, você poderá incorporá-la mais tarde.

Por padrão, há duas identidades primárias usadas pelo cluster: a identidade do cluster e a identidade do kubelet. Os componentes do plano de controle do AKS usam a identidade do cluster para gerenciar recursos de cluster, incluindo balanceadores de carga de entrada e IPs públicos gerenciados pelo AKS. A identidade do kubelet é autenticada com o Registro de Contêiner. Alguns complementos também dão suporte à autenticação usando uma identidade gerenciada.

Você deve usar identidades gerenciadas quando o cluster precisar efetuar pull de imagens de um registro de contêiner. Essa ação exige que o cluster obtenha as credenciais do registro. Se você não usar uma identidade gerenciada, poderá armazenar essas informações na forma de objeto de segredo do Kubernetes e usar imagePullSecrets para recuperar o segredo. Não recomendamos essa abordagem devido a complexidades de segurança. Não só você precisa de conhecimento prévio do segredo, mas também de armazenar esse segredo por meio do pipeline de DevOps. Outro motivo pelo qual não recomendamos essa abordagem é a sobrecarga operacional de gerenciar a rotação do segredo. Em vez disso, conceda acesso AcrPull à identidade gerenciada do kubelet do cluster ao registro. Essa abordagem resolve as preocupações.

Nessa arquitetura, o cluster acessa recursos do Azure protegidos pelo Microsoft Entra ID e realiza operações compatíveis com identidades gerenciadas. Atribua o RBAC (controle de acesso baseado em função) do Azure e permissões às identidades gerenciadas do cluster, dependendo das operações que o cluster faz. O cluster faz sua própria autenticação no Microsoft Entra ID. Depois, ele tem acesso permitido ou negado com base nas funções atribuídas a ele. Aqui estão alguns exemplos dessa implementação de referência em que as funções internas do Azure foram atribuídas ao cluster:

• Função de Colaborador de rede. Gerencia a capacidade do cluster de controlar a rede virtual spoke. Com essa atribuição de função, a identidade atribuída ao sistema de cluster do AKS pode funcionar com a sub-rede dedicada para o serviço do controlador de entrada interno.

• Função de Publicador de métricas de monitoramento. Gerencia a capacidade do cluster de enviar métricas para o Azure Monitor.

• Função AcrPull. Gerencia a capacidade do cluster de efetuar pull de imagens de instâncias de Registro de Contêiner do Azure especificadas.

Acesso ao cluster

A integração do Microsoft Entra também simplifica a segurança para o acesso vindo de fora. Por exemplo, pode ser que você queira usar o kubectl. Para começar, você pode executar o comando az aks get-credentials para obter as credenciais do cluster. O Microsoft Entra ID autentica sua identidade em relação às funções do Azure que têm permissão para obter credenciais do cluster. Para saber mais, confira Permissões de funções de cluster disponíveis.

O AKS dá suporte ao acesso ao Kubernetes usando o Microsoft Entra ID de duas maneiras. A primeira é usando o Microsoft Entra ID como um provedor de identidade integrado ao sistema RBAC do Kubernetes nativo. O outro método usa o RBAC nativo do Azure para controlar o acesso ao cluster. As seções a seguir detalham as duas abordagens.

Associar o RBAC do Kubernetes ao Microsoft Entra ID

O Kubernetes dá suporte ao RBAC por meio de:

• Um conjunto de permissões que você define usando um objeto Role ou ClusterRole para permissões em todo o cluster.

• Associações que atribuem usuários e grupos que têm permissão para executar as ações. Defina associações usando um objeto RoleBinding ou ClusterRoleBinding.

O Kubernetes tem algumas funções internas, como administrador de cluster, edição e exibição. Associar essas funções a usuários e grupos do Microsoft Entra para usar o diretório empresarial e gerenciar o acesso. Para saber mais, consulte Usar o RBAC do Kubernetes com a integração do Microsoft Entra.

Verifique se você incluiu os grupos do Microsoft Entra para acesso ao cluster e ao namespace nas revisões de acesso do Microsoft Entra.

Usar o Azure RBAC para autorização do Kubernetes

Em vez de usar o RBAC nativo do Kubernetes, ClusterRoleBindings e RoleBindings para autorização com autenticação integrada do Microsoft Entra, recomendamos que você use o RBAC do Azure e as atribuições de função do Azure. Essa abordagem impõe verificações de autorização ao cluster. Você pode até mesmo atribuir essas funções aos escopos de grupo de gerenciamento, assinatura ou grupo de recursos. Todos os clusters no escopo herdam um conjunto consistente de atribuições de função em relação a quem tem permissões para acessar os objetos no cluster do Kubernetes.

Para saber mais, consulte RBAC do Azure para autorização do Kubernetes.

Contas locais

O AKS é compatível com a autenticação de usuário nativa do Kubernetes. Não recomendamos que você use esse método para fornecer acesso de usuário a clusters. Esse método é baseado em certificado e executado de modo externo ao provedor de identidade principal, dificultando a centralização do controle de acesso e da governança do usuário. Sempre gerencie o acesso ao cluster usando o Microsoft Entra ID e configure seu cluster para desabilitar explicitamente o acesso à conta local.

Nessa implementação de referência, o acesso por meio de contas de cluster local é explicitamente desabilitado quando o sistema implanta o cluster.

Integração do Microsoft Entra ID para a carga de trabalho

Assim como é possível ter uma identidade gerenciada atribuída pelo sistema do Azure para o cluster inteiro, você pode atribuir identidades gerenciadas no nível do pod. Uma identidade de carga de trabalho permite que a carga de trabalho hospedada acesse recursos por meio do Microsoft Entra ID. Por exemplo, a carga de trabalho armazena arquivos no Armazenamento do Azure. Quando você precisar acessar esses arquivos, o pod fará a própria autenticação no recurso como uma identidade gerenciada do Azure.

Nesta implementação de referência, a Identidade da carga de trabalho do Microsoft Entra no AKS fornece as identidades gerenciadas para pods. Essa abordagem se integra aos recursos nativos do Kubernetes para federar com provedores de identidade externos. Para obter mais informações sobre a federação de ID de carga de trabalho do Microsoft Entra, consulte Federação de identidade de carga de trabalho.

Selecione um modelo de rede

O AKS dá suporte a vários modelos de rede, incluindo kubenet, CNI e Sobreposição de CNI do Azure. Os modelos CNI são os modelos mais avançados e de alto desempenho. Ao comunicar entre pods, o desempenho de CNI é semelhante ao desempenho das máquinas virtuais em uma rede virtual. O CNI oferece um controle de segurança aprimorado, já que habilita o uso da política de rede do Azure. Recomendamos um modelo de rede baseado em CNI.

No modelo sem sobreposição de CNI, cada pod recebe um endereço IP do espaço de endereço da sub-rede. Os recursos na mesma rede (ou recursos emparelhados) podem acessar os pods diretamente por meio do endereço IP. A NAT (Conversão de Endereços de Rede) não é necessária para rotear esse tráfego.

Nesta implementação de referência, usamos a Sobreposição de CNI do Azure, que aloca apenas endereços IP da sub-rede do pool de nós para os nós e usa uma camada de sobreposição altamente otimizada para IPs de pod. Como a Sobreposição de CNI do Azure usa menos endereços IP de rede virtual do que muitas outras abordagens, recomendamos para implantações com restrição de endereço IP.

Para obter informações sobre os modelos, consulte Escolher um modelo de rede da Interface de rede de contêiner a ser usado e Comparar modelos de rede do kubenet e da Interface de rede de contêiner do Azure.

implantar recursos de entrada

Os recursos de entrada do Kubernetes fazem o roteamento e a distribuição do tráfego de entrada para o cluster. Há duas partes dos recursos de entrada:

• O balanceador de carga interno, gerenciado pelo AKS. O balanceador de carga expõe o controlador de entrada por meio de um endereço IP estático privado. Ele serve como um único ponto de contato que recebe fluxos de entrada.

  Essa arquitetura usa o Azure Load Balancer. O Load Balancer é colocado fora do cluster em uma sub-rede dedicada para recursos de entrada. Ele recebe tráfego do Gateway de Aplicativo e essa comunicação é por TLS. Para saber mais sobre a criptografia TLS para tráfego de entrada, consulte Fluxo de tráfego de entrada.

• O controlador de entrada. Este exemplo usa Traefik. executado no pool de nós do usuário no cluster. Ele recebe o tráfego do balanceador de carga interno, termina o TLS e o encaminha para os pods de carga de trabalho por HTTP.

O controlador de entrada é um componente essencial do cluster. Considere os seguintes pontos ao configurar esse componente.

• Restrinja o controlador de entrada a um escopo específico de operações como parte de suas decisões de design. Por exemplo, você pode permitir que o controlador interaja apenas com os pods que executam uma carga de trabalho específica.

• Evite colocar réplicas no mesmo nó para distribuir a carga e ajudar a garantir a continuidade dos negócios se um nó falhar. Use podAntiAffinity para essa finalidade.

• Restrinja os pods a serem agendados apenas no pool de nós do usuário com nodeSelectors. Essa configuração isola os pods de carga de trabalho e sistema.

• Abra portas e protocolos que permitem que entidades específicas enviem tráfego para o controlador de entrada. Nessa arquitetura, o Traefik recebe apenas tráfego do Gateway de Aplicativo.

• Defina as configurações readinessProbe e livenessProbe que monitoram a integridade dos pods no intervalo especificado. O controlador de entrada deve enviar sinais que indiquem a integridade dos pods.

• Considere restringir o acesso do controlador de entrada a recursos específicos e a capacidade de execução de determinadas ações. Você pode implementar essa restrição por meio de permissões RBAC do Kubernetes. Por exemplo, nesta arquitetura, o Traefik recebeu permissões para inspecionar, obter e listar serviços e pontos de extremidade usando regras no objeto ClusterRole do Kubernetes.

Para obter mais informações sobre o design de entrada para os contêineres do Windows no AKS na arquitetura de referência de linha de base, consulte Contêineres do Windows no AKS.

Configurações do roteador

O controlador de entrada usa rotas para determinar o local para enviar o tráfego. As rotas especificam a porta de origem na qual o tráfego é recebido e informações sobre as portas e protocolos de destino.

Aqui está um exemplo dessa arquitetura:

O Traefik usa o provedor do Kubernetes para configurar rotas. As opções annotations, tls e entrypoints indicam que as rotas são atendidas por HTTPS. A opção middlewares especifica que somente o tráfego da sub-rede do Gateway de Aplicativo é permitido. As respostas usarão codificação gzip se o cliente aceitar. Como o Traefik faz a terminação TLS, a comunicação com os serviços de back-end é por HTTP.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

Proteger o fluxo de rede

Nessa arquitetura, o fluxo de rede inclui:

• Tráfego de entrada do cliente para a carga de trabalho executada no cluster.

• Tráfego de saída de um pod ou nó no cluster até um serviço externo.

• Tráfego de pod para pod entre pods. Esse tráfego inclui a comunicação entre o controlador de entrada e a carga de trabalho. Se a carga de trabalho for composta por vários aplicativos implantados no cluster, a comunicação entre esses aplicativos também entrará nessa categoria.

• Tráfego de gerenciamento que fica entre o cliente e o servidor de API do Kubernetes.

Baixe um Arquivo Visio dessa arquitetura.

Essa arquitetura tem várias camadas de segurança para proteger todos os tipos de tráfego.

Fluxo de tráfego de entrada

A arquitetura aceita apenas solicitações criptografadas por TLS do cliente. O TLS v1.2 é a versão mínima permitida com um conjunto restrito de criptografias. A correspondência estrita de SNI (Indicação de Nome de Servidor) está habilitada. O TLS de ponta a ponta é configurado por meio do Gateway de Aplicativo usando dois certificados TLS diferentes, conforme mostrado no diagrama a seguir.

Baixe um Arquivo Visio dessa arquitetura.

1. O cliente envia uma solicitação HTTPS para o nome de domínio: bicycle.contoso.com. Esse nome é associado com um registro DNS A ao endereço IP público do Gateway de Aplicativo. Esse tráfego é criptografado para ajudar a garantir que o tráfego entre o navegador do cliente e o gateway não possa ser inspecionado ou alterado.

2. O Gateway de Aplicativo tem um Firewall de Aplicativo Web integrado e negocia o handshake TLS para bicycle.contoso.com, permitindo apenas criptografias seguras. O Gateway de Aplicativo é um ponto de terminação TLS, o que é importante porque o Firewall de Aplicativo Web do Gateway de Aplicativo precisa inspecionar a resposta de texto não criptografado. O Key Vault armazena o certificado TLS. O cluster o acessa com uma identidade gerenciada atribuída pelo usuário que é integrada ao Gateway de Aplicativo. Para obter mais informações, confira Encerramento de TLS com certificados do Key Vault.

   O Gateway de Aplicativo processa regras de inspeção de firewall de aplicativo Web e executa regras de roteamento que encaminham o tráfego para o back-end configurado.

3. À medida que o tráfego passa do Gateway de Aplicativo para o back-end, ele é criptografado novamente com outro certificado TLS, curinga para *.aks-ingress.contoso.com, pois é encaminhado para o balanceador de carga interno. Essa nova criptografia ajuda a garantir que tráfego não seguro não flua para a sub-rede do cluster.

4. O controlador de entrada recebe o tráfego criptografado por meio do balanceador de carga. O controlador é outro ponto de terminação TLS para *.aks-ingress.contoso.com e encaminha o tráfego para os pods de carga de trabalho por HTTP. Os certificados são armazenados no Key Vault e montados no cluster com o driver CSI (Interface de Armazenamento de Contêiner). Para saber mais, confira Adicionar gerenciamento de segredos.

É possível implementar o tráfego TLS de ponta a ponta em todos os saltos até o pod de carga de trabalho. Não se esqueça de avaliar o desempenho, a latência e os efeitos operacionais ao tomar a decisão de proteger o tráfego entre pods. Para a maioria dos clusters de locatário único, com RBAC do plano de controle adequado e práticas maduras de ciclo de vida de desenvolvimento de software, é suficiente criptografar TLS até o controlador de entrada e proteger com o Firewall de Aplicativo Web. Essa abordagem minimiza a sobrecarga no gerenciamento de carga de trabalho e a sobrecarga devido ao baixo desempenho da rede. Seus requisitos de carga de trabalho e conformidade ditarão o local em que será realizada a terminação TLS.

Fluxo de tráfego de saída

Nessa arquitetura, recomendamos que todo o tráfego de saída do cluster se comunique por meio do Firewall do Azure. Ou você pode usar sua própria solução de virtualização de rede semelhante. Não recomendamos o uso de outras opções de saída, como Gateway da NAT do Azure ou um proxy HTTP, pois elas não fornecem inspeção de tráfego de rede. Para o controle de Confiança Zero e a capacidade de inspecionar o tráfego, todo o tráfego de saída do cluster passa pelo Firewall. Você pode implementar essa configuração com UDRs (rotas definidas pelo usuário). O próximo salto da rota é o endereço IP privado do Firewall do Azure. O Firewall do Azure decide se vai bloquear ou permitir o tráfego de saída. Essa decisão se baseia nas regras específicas definidas no Firewall do Azure ou nas regras internas de inteligência contra ameaças.

Uma alternativa ao Firewall do Azure é usar o recurso proxy HTTP do AKS. Todo o tráfego que sai do cluster vai para o endereço IP do proxy HTTP, que encaminha o tráfego ou o descarta.

Em qualquer um dos métodos, consulte as regras de tráfego de rede de saída necessárias para o AKS.

Uma exceção ao controle de Confiança Zero é quando o cluster precisa se comunicar com outros recursos do Azure. Por exemplo, o cluster pode precisar efetuar pull de uma imagem atualizada do registro de contêiner ou segredos do Key Vault. Nesses cenários, recomendamos que você use o Link privado. A vantagem é que sub-redes específicas chegam diretamente ao serviço e o tráfego entre o cluster e os serviços não passam pela Internet. Uma desvantagem é que o Link privado precisa de configuração adicional em vez de usar o serviço de destino em seu ponto de extremidade público. Além disso, nem todos os serviços ou produtos do Azure são compatíveis com o Link privado. Nesses casos, habilite um ponto de extremidade de serviço de rede virtual na sub-rede para acessar o serviço.

Se o Link privado ou os pontos de extremidade de serviço não forem uma opção, você poderá acessar outros serviços por meio de seus pontos de extremidade públicos e controlar o acesso por meio de regras do Firewall do Azure e do firewall incorporado ao serviço de destino. Como esse tráfego passará pelos endereços IP estáticos do firewall, você pode adicionar esses endereços à lista de IPs permitidos do serviço. Uma desvantagem é que Firewall do Azure precisa de mais regras para garantir que apenas o tráfego de uma sub-rede específica seja permitido. Considere esses endereços ao planejar vários endereços IP para tráfego de saída com o Firewall do Azure. Caso contrário, você pode atingir o esgotamento da porta. Para obter mais informações sobre como planejar vários endereços IP, consulte Criar um Firewall do Azure com vários endereços IP.

Para obter informações sobre as considerações de saída específicas do Windows nos contêineres do Windows na arquitetura de referência de linha de base do AKS, consulte Contêineres do Windows no AKS.

Tráfego de pod para pod

Por padrão, um pod pode aceitar o tráfego de qualquer outro pod no cluster. Use o Kubernetes NetworkPolicy para restringir o tráfego de rede entre pods. Aplique políticas de maneira criteriosa ou você poderá ter uma situação em que um fluxo de rede crítico será bloqueado. Somente permita caminhos de comunicação específicos, conforme o necessário, como o tráfego entre o controlador de entrada e a carga de trabalho. Para obter mais informações, consulte Políticas de rede.

Habilite a política de rede ao provisionar o cluster porque você não poderá adicioná-lo posteriormente. Você tem algumas opções para tecnologias que implementam NetworkPolicy. Recomendamos a política de rede do Azure, que requer a CNI (Interface de Rede de Contêiner) do Azure. Para obter mais informações, confira a nota a seguir. Outras opções incluem a política de rede Calico, uma opção de código aberto conhecida. Considere o Calico se precisar gerenciar políticas de rede em todo o cluster. O Calico não é coberto pelo Suporte do Azure padrão.

Para obter mais informações, consulte Diferenças entre os mecanismos de política de rede do Azure.

Tráfego de gerenciamento

Como parte da execução do cluster, o servidor de API do Kubernetes recebe tráfego de recursos que desejam fazer operações de gerenciamento no cluster, como solicitações para criar recursos para dimensionar o cluster. Exemplos desses recursos incluem o pool de agentes de compilação em um pipeline de DevOps, uma instância do Azure Bastion dentro da sub-rede do Azure Bastion e pools de nós em si. Em vez de aceitar esse tráfego de gerenciamento de todos os endereços IP, use o recurso Intervalos de IP autorizados do AKS para permitir apenas o tráfego de intervalos de IP autorizados para o servidor de API.

Para saber mais, consulte Definir intervalos de IP autorizados do servidor de API.

Para obter outra camada de controle, com um pouco a mais de complexidade, você pode provisionar um cluster do AKS privado. Ao usar um cluster privado, você pode ajudar a garantir que o tráfego de rede entre o servidor de API e os seus pools de nós permaneça somente na rede privada, sem que ele seja exposto à Internet. Para obter mais informações, consulte Clusters privados do AKS.

Adicionar o gerenciamento de segredos

Armazene segredos em um repositório de chaves gerenciadas, como Key Vault. A vantagem é que um repositório de chaves gerenciadas lida com a rotação de segredos. Ele fornece criptografia forte e um log de auditoria de acesso. Ele também mantém os segredos principais fora do pipeline de implantação. Nesta arquitetura, o firewall do Key Vault é habilitado e configurado, e o Link privado é usado ao se conectar a partir de recursos no Azure que precisam acessar segredos e certificados.

O Key Vault está bem integrado com outros serviços do Azure. Use o recurso interno desses serviços para acessar segredos. Para obter mais informações sobre como o Gateway de Aplicativo acessa certificados TLS para o fluxo de entrada, confira a seção Fluxo de tráfego de entrada.

O modelo de permissão RBAC do Azure para o Key Vault permite atribuir as identidades de carga de trabalho à função Usuário de segredos do Key Vault ou Leitor do Key Vault e acessar os segredos. Para obter mais informações, consulte Acessar o Key Vault usando RBAC.

Acessar segredos de cluster

Você precisa usar identidades de carga de trabalho para permitir que um pod acesse segredos de um repositório específico. Para facilitar o processo de recuperação, use um driver CSI do repositório de segredos. Quando o pod precisa de um segredo, o driver se conecta com o repositório especificado, recupera o segredo em um volume e monta esse volume no cluster. Assim, o pod pode obter o segredo do sistema de arquivos de volume.

O driver CSI tem muitos provedores compatíveis com vários repositórios gerenciados. Essa implementação usa o Key Vault com o driver CSI do repositório de segredos. O complemento recupera o certificado TLS do Key Vault e carrega o driver no pod que executa o controlador de entrada. Essa operação ocorre durante a criação do pod, e o volume armazena chaves públicas e privadas.

Armazenamento da carga de trabalho

A carga de trabalho nesta arquitetura é sem estado. Recomendamos persistir o estado fora do cluster caso precise armazená-lo. As diretrizes para o estado da carga de trabalho estão fora do escopo deste artigo.

Para obter mais informações, confira Opções de armazenamento para aplicativos no AKS.

Gerenciamento de política

Uma forma eficaz de gerenciar um cluster do AKS é impor governança por meio de políticas. O Kubernetes implementa políticas por meio do Gatekeeper OPA (Open Policy Agent). No AKS, as políticas são oferecidas por meio de Azure Policy. Cada política se aplica a todos os clusters em seu escopo. O Gatekeeper OPA lida com a imposição de políticas no cluster e registra todas as verificações de políticas. As alterações na política não são refletidas imediatamente em seu cluster. É normal ocorrerem atrasos.

Para gerenciar seus clusters do AKS, você pode usar o Azure Policy para:

• Impedir ou restringir a implantação de clusters do AKS em um grupo de recursos ou assinatura. Aplique padrões para sua organização. Por exemplo, você pode seguir uma convenção de nomenclatura ou especificar uma marcação.
• Proteja seu cluster do AKS por meio do Azure Policy para Kubernetes.

Ao definir políticas, aplique-as com base nos requisitos da carga de trabalho. Considere estes fatores:

• Você quer definir uma coleção de políticas, também chamadas de iniciativas, ou escolher políticas individuais? O Azure Policy tem duas iniciativas internas: básicas e restritas. Cada iniciativa é uma coleção de políticas internas aplicáveis a um cluster do AKS. Recomendamos que você selecione uma iniciativa e escolha outras políticas para o cluster e os recursos, como Registro de Contêiner, Gateway de Aplicativo ou Key Vault, que interagem com o cluster. Escolha políticas com base nos requisitos da sua organização.

• Você quer auditar ou negar a ação? No modo Auditoria, a ação é permitida, mas é sinalizada como Não compatível. Tenha processos para verificar estados fora de conformidade em uma cadência regular e tomar as medidas necessárias. No modo Negar, a ação é bloqueada porque viola a política. Tenha cuidado ao escolher esse modo porque ele pode ser muito restritivo para a carga de trabalho funcionar.

• Você tem áreas em sua carga de trabalho que não devem estar em conformidade com o design? O Azure Policy tem a capacidade de especificar namespaces do Kubernetes que são isentos da imposição de política. Recomendamos ainda aplicar políticas no modo Auditoria para que você esteja ciente dessas instâncias.

• Você tem requisitos que não são cobertos pelas políticas internas? Você pode criar uma definição personalizada do Azure Policy que aplique suas políticas personalizadas do Gatekeeper do OPA. Não aplique políticas personalizadas diretamente ao cluster. Para obter mais informações, consulte Criar e atribuir definições de política personalizadas.

• Você tem requisitos para toda a organização? Nesse caso, adicione essas políticas no nível do grupo de gerenciamento. Seu cluster também deve atribuir as próprias políticas específicas de carga de trabalho, mesmo que sua organização tenha políticas genéricas.

• Você atribui políticas do Azure a escopos específicos? Verifique se as políticas de produção também são validadas em relação ao ambiente de pré-produção. Caso contrário, ao implantar no ambiente de produção, você poderá encontrar restrições adicionais inesperadas que não foram previstas na pré-produção.

Essa implementação de referência habilita o Azure Policy quando o cluster do AKS é criado. A iniciativa restritiva é atribuída no modo Auditoria para obter visibilidade da 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 somente seja efetuado pull de imagens da instância do Registro de Contêiner implantada. Considere criar suas próprias iniciativas personalizadas. Combine as políticas aplicáveis à carga de trabalho em uma única atribuição.

Para observar como o Azure Policy funciona de dentro do cluster, acesse os logs de todos os pods no gatekeeper-systemnamespace, bem como os logs dos pods azure-policy e azure-policy-webhook no namespace kube-system.

Para obter mais informações sobre considerações específicas do Azure Policy do Windows, consulte o artigo Gerenciamento de políticas de contêineres do Windows no AKS.

Escalabilidade do nó e do pod

Com o aumento da demanda, o Kubernetes pode expandir adicionando mais pods a nós existentes, por meio do dimensionamento automático de pod horizontal. Quando o Kubernetes não puder mais agendar outros pods, o número de nós deverá ser aumentado por meio do dimensionamento automático do cluster do AKS. Uma solução de escala completa deve ter maneiras de dimensionar as réplicas de pod e a contagem de nós no cluster.

Há duas abordagens: dimensionamento automático ou dimensionamento manual.

Tanto o dimensionamento automático quanto a abordagem manual exigem que você monitore e defina alertas sobre o uso da CPU ou métricas personalizadas. Para dimensionamento de pod, o operador de aplicativo pode aumentar ou diminuir o número de réplicas de pod ajustando ReplicaSet por meio das APIs do Kubernetes. Para dimensionamento de cluster, um método é ser notificado quando o agendador do Kubernetes falhar. Outra maneira é inspecionar pods pendentes ao longo do tempo. É possível ajustar a contagem de nós por meio da CLI do Azure ou do portal do Azure.

Recomendamos a abordagem de dimensionamento automático porque alguns desses mecanismos manuais são criados no dimensionador automático.

Como método geral, comece por testes de desempenho com um número mínimo de pods e nós. Use esses valores para estabelecer a expectativa de linha de base. Em seguida, use uma combinação de métricas de desempenho e dimensionamento manual para localizar gargalos e entender a resposta do aplicativo ao dimensionamento. Por fim, use esses dados para definir os parâmetros de dimensionamento automático. Para obter mais informações sobre o cenário de ajuste de desempenho com o AKS, consulte Cenário de ajuste de desempenho: transações comerciais distribuídas.

Dimensionador automático de pod horizontal

O HPA (Dimensionador Automático de Pod Horizontal) é um recurso do Kubernetes que dimensiona o número de pods.

No recurso HPA, recomendamos definir a contagem mínima e máxima de réplicas. Os valores restringem os limites de dimensionamento automático.

O HPA pode ser dimensionado com base no uso da CPU, no uso de memória e nas métricas personalizadas. Somente o uso da CPU já vem pronto. A definição HorizontalPodAutoscaler especifica valores de destino para as métricas. Por exemplo, a especificação define o uso da CPU de destino. Enquanto os pods estão em execução, o controlador HPA usa a API de métricas do Kubernetes para verificar o uso da CPU de cada pod. Ele compara esse valor com o uso pretendido e calcula uma taxa. Em seguida, usa a taxa para determinar se os pods são superalocados ou subalocados. Ele depende do agendador do Kubernetes para atribuir novos pods a nós ou remover pods de nós.

Pode haver uma condição de corrida em que a HPA verifica antes de uma operação de dimensionamento ser concluída. O resultado pode ser um cálculo de taxa incorreta. Para obter mais informações, consulte Resfriamento de eventos de dimensionamento.

Se a carga de trabalho é controlada por eventos, uma opção de código aberto popular é o KEDA (dimensionamento automático controlado por eventos do Kubernetes). Considere o KEDA se a origem do evento, como fila de mensagens, controlar sua carga de trabalho em vez de ser associada à CPU ou à memória da carga de trabalho. O KEDA é compatível com diversas origens de evento ou dimensionadores. Use a lista de origens de eventos que o KEDA pode dimensionar em dimensionadores KEDA. A lista inclui o dimensionador doAzure Monitor, que é uma maneira conveniente de dimensionar cargas de trabalho KEDA com base nas métricas do Azure Monitor.

Dimensionador automático de cluster

O dimensionador automático de cluster é um componente de complemento do AKS que dimensiona o número de nós em um pool de nós. Adicione-o durante o provisionamento de cluster. Você precisa de um dimensionador automático de cluster separado para cada pool de nós de usuário.

O agendador do Kubernetes aciona o dimensionador automático de cluster. Quando o agendador do Kubernetes falha ao agendar um pod devido a restrições de recursos, o dimensionador automático provisiona automaticamente um novo nó no pool de nós. Por outro lado, o dimensionador automático de cluster verifica a capacidade não utilizada dos nós. Se o nó não estiver sendo executado na capacidade esperada, os pods serão movidos para outro nó e o nó não utilizado será removido.

Ao habilitar o dimensionador automático, defina a contagem máxima e mínima de nós. Os valores recomendados dependem da expectativa de desempenho da carga de trabalho, do quanto você deseja que o cluster cresça e das implicações de custo. O número mínimo é a capacidade reservada para esse pool de nós. Nessa implementação de referência, o valor mínimo é definido como dois devido à simplicidade da carga de trabalho.

Para o pool de nós do sistema, o valor mínimo recomendado é três.

Para obter informações sobre as considerações de dimensionamento específicas do Windows incluídas nesta arquitetura básica de referência, consulte o artigo Contêineres do Windows no AKS.

Decisões de continuidade dos negócios

Para manter a continuidade dos negócios, defina o SLO para a infraestrutura e seu aplicativo. Para saber mais, confira Recomendações para definir destinos de confiabilidade. Analise as condições do SLA (contrato de nível de serviço) para o AKS no artigo mais recente SLA para serviços online.

Nós de cluster

Para atender ao nível mínimo de disponibilidade para cargas de trabalho, são necessários vários nós em um pool de nós. Se um nó falhar, outro nó no mesmo pool de nós e cluster poderá continuar executando o aplicativo. Para confiabilidade, recomendamos três nós para o pool de nós do sistema. Para o pool de nós do usuário, comece com no mínimo dois nós. Se você precisar de maior disponibilidade, configure mais nós.

Isole seus aplicativos dos serviços do sistema colocando-os em um pool de nós separado, conhecido como pool de nós do usuário. Assim, os serviços do Kubernetes são executados em nós dedicados e não competem com a carga de trabalho. Recomendamos que você use marcações, rótulos e taints para identificar o pool de nós e agendar sua carga de trabalho. Certifique-se de que o pool de nós do sistema esteja afetado com um CriticalAddonsOnlytaint.

A manutenção regular do cluster, por exemplo, fazer atualizações oportunas, é crucial para a confiabilidade. Além disso, recomendamos que você monitore a integridade dos pods por meio de investigações.

Disponibilidade do pod

Especifique os requisitos de recursos de pod: recomendamos que você especifique os requisitos de recursos de pod em suas implantações. O agendador pode agendar o pod adequadamente. A confiabilidade será bastante reduzida se seus pods não puderem ser agendados.

Definir os orçamentos de interrupção do pod: essa configuração determina quantas réplicas em uma implantação podem ficar inativas durante um evento de atualização ou upgrade. Para saber mais, confira Orçamentos de interrupção do pod.

Configure várias réplicas na implantação para lidar com interrupções como falhas de hardware. Para eventos planejados, como atualizações e upgrades, um orçamento de interrupção pode ajudar a garantir que haja um número necessário de réplicas de pod para lidar com a carga esperada do aplicativo.

Definir cotas de recursos nos namespaces de carga de trabalho: a cota de recursos em um namespace ajuda a garantir que as solicitações e os limites do pod sejam definidos corretamente em uma implantação. Para obter mais informações, consulte Impor cotas de recursos.

Definir solicitações e limites de pods: essas solicitações e limites permitem que o Kubernetes aloque com eficiência a CPU e os recursos de memória para os pods, além de permitir que você tenha maior densidade de contêiner em um nó. Solicitações e limites também podem aumentar sua confiabilidade e reduzir seus custos devido ao melhor uso do hardware.

Para estimar os limites para uma carga de trabalho, teste e estabeleça uma linha de base. Comece com valores iguais para solicitações e limites. Em seguida, ajuste gradualmente os valores até que você estabeleça um limite que pode causar instabilidade no cluster.

Você pode especificar solicitações e limites em seus manifestos de implantação. Para saber mais, confira Definir solicitações e limites de pods.

Zonas de disponibilidade e suporte a várias regiões

Para se proteger contra alguns tipos de interrupções, use as zonas de disponibilidade se a região oferecer suporte a elas. Os componentes do plano de controle e os nós nos pools de nós são capazes de se espalhar entre zonas. Se uma zona inteira não estiver disponível, um nó em outra zona dentro da região ainda estará disponível. Cada pool de nós é mapeado para um conjunto de dimensionamento de máquinas virtuais separado, que gerencia instâncias de nó e escalabilidade. O serviço AKS gerencia as operações e a configuração do conjunto de dimensionamento. Veja aqui algumas considerações ao habilitar várias zonas:

• Infraestrutura inteira: escolha uma região que dê suporte a zonas de disponibilidade. Para obter mais informações, confira Limitações. Para ter um SLA de tempo de atividade, é necessário escolher a camada Standard ou Premium. O SLA de tempo de atividade é maior quando você usa zonas de disponibilidade.

• Cluster: você só pode definir zonas de disponibilidade ao criar o pool de nós. Elas não podem ser alteradas posteriormente. Os tamanhos de nó devem ser aceitos em todas as zonas para que a distribuição esperada seja possível. O conjunto de dimensionamento de máquinas virtuais subjacente fornece a mesma configuração de hardware entre zonas.

  A compatibilidade com várias zonas não se aplica apenas a pools de nós, mas também ao plano de controle. O plano de controle do AKS abrange as zonas solicitadas, como os pools de nós. Se você não usar a compatibilidade com zona em seu cluster, não será possível garantir que os componentes do plano de controle se espalharão entre as zonas de disponibilidade.

• Recursos dependentes: para o benefício zonal completo, todas as dependências de serviço também devem dar suporte às zonas. Se um serviço dependente não der suporte às zonas, é possível que uma falha de zona possa causar a falha desse serviço.

  Por exemplo, um disco gerenciado está disponível na zona na qual ele foi provisionado. Em caso de falha, o nó pode se mover para outra zona, mas o disco gerenciado não se moverá com o nó para essa zona.

Para simplificar, nessa arquitetura, o AKS é implantado em uma única região com pools de nós que abrangem as zonas de disponibilidade um, dois e três. Outros recursos da infraestrutura, como Firewall do Azure e Gateway de Aplicativo, também são implantados na mesma região também com compatibilidade com várias zonas. A replicação geográfica está habilitada para Registro de Contêiner.

Várias regiões

Quando você habilita zonas de disponibilidade, não há cobertura suficiente no caso improvável de falha em uma região inteira. Para obter maior disponibilidade, execute vários clusters do AKS em regiões diferentes.

• Dê preferência a regiões emparelhadas quando elas estiverem disponíveis. Um benefício do uso de regiões emparelhadas é a confiabilidade durante as atualizações de plataforma. O Azure garante que apenas uma região do par seja atualizada por vez. Algumas regiões não têm pares. Se sua região não estiver emparelhada, você ainda poderá implantar uma solução multirregional selecionando outras regiões a serem usadas. Considere usar um pipeline de CI/CD (integração contínua e entrega contínua), que você configura para orquestrar a recuperação de uma falha na região. Determinadas ferramentas de DevOps, como o Flux, podem facilitar as implantações de várias regiões.

• Forneça o local em que o serviço redundante terá sua instância secundária se um recurso do Azure der suporte à redundância geográfica. Por exemplo, ao habilitar a replicação geográfica para o Registro de Contêiner, ele replica automaticamente as imagens para as regiões selecionadas do Azure. Ele também fornece acesso contínuo a imagens, mesmo que a região primária sofra uma interrupção.

• Escolha um roteador de tráfego que possa distribuir o tráfego em diferentes zonas ou regiões, dependendo de suas necessidades. Essa arquitetura implanta o Load Balancer porque ele pode distribuir o tráfego que não é da Web pelas zonas. Se você precisar distribuir o tráfego em diferentes regiões, considere usar o Azure Front Door. Para ver outras opções, consulte Escolher um balanceador de carga.

Recuperação de desastre

Se ocorrer uma falha na região primária, o ideal é criar rapidamente uma nova instância em outra região. Veja algumas recomendações:

• Usar várias regiões. Se sua região primária tiver uma região emparelhada, use esse par. Caso contrário, selecione regiões com base em seus requisitos de residência e latência de dados.

• Use uma carga de trabalho sem estado que você possa replicar com eficiência. Caso você precise armazenar o estado no cluster, o que não é recomendável, não se esqueça de fazer backup dos dados com frequência em outra região.

• Integre a estratégia de recuperação, como a replicação para outra região, como parte do pipeline de DevOps para atender ao SLO.

• Provisione cada serviço do Azure usando recursos compatíveis com a recuperação de desastre. Por exemplo, nessa arquitetura, o Registro de Contêiner está habilitado para replicação geográfica. Se uma região falhar, você ainda poderá efetuar pull de imagens da região replicada.

• Implante sua infraestrutura como código, incluindo o cluster do AKS e quaisquer outros componentes necessários. Se precisar implantar em outra região, você poderá reutilizar os scripts ou modelos para criar uma instância idêntica.

Backup do cluster

Para muitas arquiteturas, você pode provisionar um novo cluster e seu retorno ao estado operacional podem ser realizados por meio da inicialização do cluster baseado em operações Git, seguida pela implantação do aplicativo. Mas, se houver um estado crítico de recursos, como mapas de configuração, trabalhos e segredos que não possam ser capturados em seu processo de inicialização, use sua estratégia de recuperação. Recomendamos que você execute cargas de trabalho sem estado no Kubernetes. Se sua arquitetura envolver estado baseado em disco, você também deverá considerar sua estratégia de recuperação para esse conteúdo.

Quando o backup de cluster deve fazer parte da sua estratégia de recuperação, é necessário instalar uma solução que corresponda aos seus requisitos de negócios dentro do cluster. Esse agente é responsável por enviar o estado do recurso do cluster para um destino de sua escolha e coordenar instantâneos de volume persistentes baseados em disco do Azure.

O Velero da VMware é um exemplo de solução de backup Kubernetes comum que você pode instalar e gerenciar diretamente. Ou você pode usar a extensão de backup do AKS para fornecer uma implementação do Velero gerenciada. A extensão de backup do AKS aceita o backup de recursos do Kubernetes e volumes persistentes, com agendamentos e escopo de backup externalizados, como configuração de cofre no Backup do Azure.

A implementação de referência não implementa o backup, o que envolve recursos extras do Azure para gerenciar, monitorar, comprar e proteger. Esses recursos podem incluir uma conta de Armazenamento do Azure, um cofre de Backup do Azure e configuração, além de um recurso de acesso confiável. Em vez disso, as operações Git combinadas com a intenção de executar uma carga de trabalho sem estado é a solução de recuperação.

Escolha e valide uma solução de backup que atenda ao seu objetivo de negócios, incluindo o objetivo de ponto de recuperação definido e o objetivo de tempo de recuperação. Defina seu processo de recuperação em um runbook da equipe e pratique-o em todas as cargas de trabalho importantes para os negócios.

SLA do servidor de API do Kubernetes

Você pode usar o AKS como um serviço gratuito, mas essa camada não oferece um SLA com suporte financeiro. Para obter um SLA, escolha a camada Standard. Recomendamos que todos os clusters de produção usem a camada Standard. Reserve a camada Gratuita para clusters de pré-produção e a camada Premium apenas para cargas de trabalho críticas. Quando você usa zonas de disponibilidade do Azure, o SLA do servidor de API do Kubernetes é maior. Seus pools de nós e outros recursos são cobertos pelos próprios SLAs. Para obter mais informações sobre SLAs específicos para cada serviço, consulte SLA para serviços online.

Vantagens e desvantagens

Há uma vantagem de custo relacionada à disponibilidade para a implantação da arquitetura em zonas e, especialmente, regiões. Alguns recursos de replicação, como a replicação geográfica no Registro de Contêiner, estão disponíveis em SKUs premium, o que é mais caro. Para implantações em várias regiões, o custo também aumenta porque os encargos de largura de banda são aplicados quando o tráfego se move entre regiões.

Além disso, espere latência de rede adicional na comunicação de nós entre zonas ou regiões. Avalie o efeito dessa decisão de arquitetura na carga de trabalho.

Testar com simulações e failovers forçados

Teste a confiabilidade da sua solução por meio de testes de failover forçado com interrupções simuladas. As simulações podem incluir a interrupção de um nó, a redução de todos os recursos do AKS em uma zona específica para simular uma falha zonal ou a invocação de uma falha de dependência externa. Você também pode usar o Azure Chaos Studio para simular vários tipos de interrupções no Azure e no cluster.

Para obter mais informações, consulte Chaos Studio.

Monitorar e coletar métricas

Recomendamos que os insights do contêiner do Azure Monitor monitore o desempenho de cargas de trabalho de contêiner, pois é possível exibir eventos em tempo real. Esse recurso também captura logs de contêiner dos pods em execução e os agrega para exibição. Além disso, coleta informações da API de métricas sobre o uso de memória e CPU para monitorar a integridade de recursos e cargas de trabalho em execução. Você também pode usar os insights de contêiner para monitorar o desempenho à medida que os pods são dimensionados. Isso inclui telemetria que é essencial para o monitoramento, a análise e a visualização dos dados coletados. Os insights do contêiner identificam tendências e permitem que você configure alertas para receber notificações proativas sobre problemas críticos.

A maioria das cargas de trabalho hospedadas em pods emitem métricas do Prometheus. Os insights de contêiner podem se integrar ao Prometheus. Você pode visualizar as métricas do aplicativo e da carga de trabalho coletadas de nós e do Kubernetes.

Algumas soluções que não são da Microsoft se integram ao Kubernetes, como Datadog, Grafana ou New Relic. Portanto, se sua organização já usa essas soluções, você pode aproveitá-las.

Com o AKS, o Azure gerencia alguns dos principais serviços do Kubernetes. O Azure implementa os logs dos componentes do plano de controle do AKS como logs de recursos. Recomendamos que você habilite as opções a seguir na maioria dos clusters. As opções podem ajudá-lo a solucionar problemas de cluster e têm uma densidade de log relativamente baixa.

• ClusterAutoscaler: ganhe observabilidade nas operações de dimensionamento com o registro. Para saber mais, confira Recuperar logs e status do dimensionador automático de cluster.
• KubeControllerManager: ganhe observabilidade na interação entre o Kubernetes e o plano de controle do Azure.
• kube-audit-admin: ganhe observabilidade em atividades que modificam seu cluster. Não há motivo para ter kube-audit e kube-audit-admin habilitados. kube-audit é um superconjunto de kube-audit-admin que também inclui operações não modificadas (leitura).
• guard: captura auditorias do Microsoft Entra ID e do RBAC do Azure.

Pode ser útil habilitar outras categorias de log, como KubeScheduler ou kube-audit, durante o desenvolvimento inicial do ciclo de vida do cluster ou da carga de trabalho. O dimensionamento automático do cluster, o posicionamento e o agendamento de pods adicionados, além dos dados semelhantes podem ajudá-lo a solucionar problemas de operações de cluster ou carga de trabalho. Mas se você mantiver os logs de solução de problemas ampliados em tempo integral após o fim das necessidades de solução de problemas, você poderá incorrer em custos desnecessários de ingestão e armazenamento de dados no Azure Monitor.

Embora o Azure Monitor inclua um conjunto de consultas de log existentes para começar, você também pode usá-las como base para criar suas próprias consultas. À medida que sua biblioteca aumenta, você pode salvar e reutilizar consultas de log usando um ou mais pacotes de consultas. Sua biblioteca personalizada de consultas fornece mais observabilidade na integridade e no desempenho dos clusters do AKS. Ela dá suporte à realização de seus SLOs.

Para obter mais informações sobre nossas práticas recomendadas de monitoramento para AKS, consulte Monitorar o AKS com o Azure Monitor.

Para obter mais informações sobre considerações de monitoramento específicas do Windows, consulte Contêineres do Windows no AKS.

Métricas de rede

As métricas básicas de rede no nível do cluster são disponibilizadas por meio da plataforma e das métricas nativas do Prometheus. Você pode ainda usar o complemento Observabilidade de rede para expor métricas de rede no nível do nó. A maioria dos clusters deve usar o complemento Observabilidade de rede para fornecer recursos adicionais de solução de problemas de rede e detectar uso inesperado de rede ou problemas no nível do nó.

Para cargas de trabalho altamente suscetíveis à perda de pacotes, latência ou pressão de DNS do Protocolo de Controle de Transmissão (TCP) ou do Protocolo de Datagrama do Usuário (UDP), as métricas de rede no nível do pod são importantes. No AKS, você pode encontrar esse nível de detalhe com o recurso Observabilidade de rede avançada. A maioria das cargas de trabalho não exige essa profundidade de observabilidade de rede. Você não deve instalar o complemento Observabilidade de rede avançada, a menos que seus pods exijam uma rede altamente otimizada, com sensibilidade até o nível do pacote.

Habilitar a autorrecuperação

Monitore a integridade dos pods definindo investigações de atividade e preparação. Se o Kubernetes detectar um pod sem resposta, ele reiniciará o pod. Uma investigação de atividade determina se o pod está íntegro. Se o Kubernetes detectar um pod sem resposta, ele reiniciará o pod. Uma investigação de preparação determina se o pod está pronto para receber solicitações e tráfego.

Atualizações de rotina para clusters do AKS

Parte das operações no segundo dia para clusters do Kubernetes é executar atualizações rotineiras da plataforma e do sistema operacional. Há três camadas de atualizações que precisam ser abordadas em cada cluster do AKS:

• A versão do Kubernetes (por exemplo, Kubernetes 1.30.3 a 1.30.7 ou Kubernetes 1.30.7 a 1.31.1), que pode vir com alterações e substituições da API do Kubernetes. As alterações de versão nessa camada afetam todo o cluster.
• A imagem do VHD (disco rígido virtual) em cada nó, que combina atualizações do sistema operacional e atualizações de componentes do AKS. Essas atualizações são testadas em relação à versão do Kubernetes do cluster. As alterações de versão nessa camada são aplicadas no nível do pool de nós e não afetam a versão do Kubernetes.
• O próprio processo de atualização nativo do sistema operacional, como Windows Update ou apt. O fornecedor do sistema operacional fornece essas atualizações diretamente, e elas não são testadas em relação à versão do Kubernetes do cluster. As alterações de versão nessa camada afetam um único nó e não afetam a versão do Kubernetes.

Cada uma dessas camadas é controlada de maneira independente. Você decide o tratamento de cada camada para os clusters da sua carga de trabalho. Escolha a frequência com que cada cluster do AKS, seus pools de nós ou seus nós são atualizados (a cadência). Além disso, escolha em quais dias ou horários as atualizações devem ser aplicadas (o período de manutenção). Escolha se as atualizações são instaladas manual ou automaticamente ou se não são. Assim como a carga de trabalho em execução no cluster precisa de uma prática de implantação segura, o mesmo acontece com as atualizações em seus clusters.

Para obter uma perspectiva abrangente sobre aplicação de patch e atualização, consulte Diretrizes de patch e atualização do AKS no guia de operações no segundo dia do AKS. Use as informações a seguir para obter recomendações de linha de base relacionadas a essa arquitetura.

Infraestrutura imutável

As cargas de trabalho que operam clusters do AKS como infraestrutura imutável não atualizam seus clusters automática ou manualmente. Defina a atualização da imagem do nó como none e a atualização automática do cluster como none. Nessa configuração, você é o único responsável por todas as atualizações em todas as camadas. Quando uma atualização desejada estiver disponível, você deverá testá-la em um ambiente de pré-produção e avaliar sua compatibilidade em um novo cluster. Depois disso, implante um carimbo de réplica de produção que inclua a versão atualizada do AKS e os VHDs do pool de nós. Quando o novo cluster de produção ficar pronto, o cluster antigo será drenado e, eventualmente, desativado.

A infraestrutura imutável com implantações regulares de nova infraestrutura é a única situação em que um cluster de produção não deve ter uma estratégia de atualização in-loco aplicada a ele. Todos os outros clusters devem ter uma estratégia de atualização in-loco.

Atualizações in-loco

As cargas de trabalho que não operam clusters do AKS como infraestrutura imutável devem atualizar regularmente seus clusters em execução, abordando todas as três camadas. Alinhe seu processo de atualização aos requisitos da carga de trabalho. Use as recomendações a seguir como ponto de partida para projetar seu processo de atualização de rotina.

• Agende o recurso manutenção planejada do AKS para que você possa controlar atualizações no seu cluster. Esse recurso permite que você execute as atualizações, uma operação inerentemente arriscada, em um momento controlado para reduzir o efeito de uma falha inesperada.
• Configure orçamentos de interrupção de pode para que seu aplicativo permaneça estável durante atualizações contínuas. Mas não configure os orçamentos para serem tão agressivos que impeçam a ocorrência de atualizações de nó, pois a maioria das atualizações requer um processo de isolamento e drenagem em cada nó.
• Confirme a cota de recursos e a disponibilidade de recursos do Azure. As atualizações in-loco implantam novas instâncias de nós, conhecidas como nós de pico, antes que os nós antigos sejam removidos. Isso significa que a cota do Azure e o espaço de endereço IP devem estar disponíveis para os novos nós. Um valor de pico de 33% é um bom ponto de partida para a maioria das cargas de trabalho.
• Teste a compatibilidade com ferramentas, como malhas de serviço ou agentes de segurança adicionados ao cluster. Teste também seus componentes de carga de trabalho, como controladores de entrada, malhas de serviço e pods de carga de trabalho. Faça testes em um ambiente de pré-produção.

Atualizações in-loco para nós

Use o NodeImagecanal de atualização automática para as atualizações de imagem do sistema operacional do nó. Esse canal configura o cluster para atualizar o VHD em cada nó com atualizações no nível do nó. A Microsoft testa as atualizações em relação à sua versão do AKS. Para nós do Windows, as atualizações acontecem aproximadamente uma vez por mês. Para os nós Linux, essas atualizações acontecem cerca de uma vez por semana.

• As atualizações nunca alteram a versão do AKS ou do Kubernetes e, portanto, a compatibilidade da API do Kubernetes não é uma preocupação.
• Quando você usa o NodeImage como canal de atualização, ele respeita o período de manutenção planejada, que você deve definir para pelo menos uma vez por semana. Defina-o independentemente do sistema operacional de imagem de nó que você usa para ajudar a garantir a aplicação oportuna.
• Essas atualizações incluem segurança, compatibilidade e atualizações funcionais no nível do sistema operacional, definições de configuração do sistema operacional e atualizações de componentes do AKS.
• As versões de imagem e seus números de versão de componente incluídos são rastreados usando o rastreador de versão do AKS.

Se os requisitos de segurança do cluster exigirem uma cadência de aplicação de patch mais agressiva e o cluster puder tolerar as possíveis interrupções, use o canal de atualização de SecurityPatch. A Microsoft também testa essas atualizações. As atualizações só serão publicadas se houver atualizações de segurança que a Microsoft considere importantes o bastante para serem lançadas antes da próxima atualização de imagem de nó agendada. Ao usar o canal SecurityPatch, você também receberá as atualizações que o canal NodeImage recebeu. A opção de canal SecurityPatch ainda respeita os períodos de manutenção, portanto, certifique-se de que seu período de manutenção tenha lacunas mais frequentes (como diariamente ou em dias alternados) para dar suporte a essas atualizações de segurança inesperadas.

A maioria dos clusters que fazem atualizações in-loco deve evitar as opções de canal de atualização de nó None e Unmanaged.

Atualizações in-loco para o cluster

O Kubernetes é uma plataforma em rápida evolução e as atualizações regulares trazem correções de segurança importantes, bem como novos recursos. É importante que você faça as atualizações do Kubernetes. Você deve ficar dentro das duas versões mais recentes ou N-2. É essencial atualizar para a versão mais recente do Kubernetes uma vez que novas versões são lançadas com frequência.

A maioria dos clusters deve ser capaz de executar atualizações de versão do AKS in-loco com cuidado e rigor suficientes. O risco de executar uma atualização de versão do AKS in-loco pode ser atenuado principalmente por meio de testes de pré-produção suficientes, validação de cota e configuração de orçamento de interrupção de pod. Mas qualquer atualização in-loco pode resultar em um comportamento inesperado. Se as atualizações in-loco forem consideradas muito arriscadas para sua carga de trabalho, recomendamos que você use uma abordagem de implantação azul-verde de clusters do AKS em vez de seguir as recomendações restantes.

Recomendamos que você evite o recurso atualização automática do cluster ao implantar um cluster do Kubernetes pela primeira vez. Use uma abordagem manual, que fornece tempo para testar uma nova versão do cluster do AKS em seus ambientes de pré-produção antes que as atualizações cheguem ao seu ambiente de produção. Essa abordagem também atinge o maior nível de previsibilidade e controle. Mas você deve ser diligente no monitoramento de novas atualizações para a plataforma Kubernetes e na adoção rápida de novas versões à medida que são lançadas. É melhor adotar uma mentalidade de "manter-se atualizado" em vez de uma abordagem de suporte em longo prazo.

Você pode receber notificações quando uma nova versão do AKS estiver disponível para o cluster usando o tópico do sistema do AKS para a Grade de Eventos do Azure. A implementação de referência implanta este tópico do sistema da Grade de Eventos para que você possa assinar o evento Microsoft.ContainerService.NewKubernetesVersionAvailable da solução de notificação do fluxo de eventos. Analise também as notas de versão do AKS para questões específicas de compatibilidade, alterações de comportamento ou substituições de recursos.

Eventualmente, você pode chegar ao ponto de confiança com as versões do Kubernetes, versões do AKS, seu cluster, seus componentes no nível do cluster e a carga de trabalho, para explorar o recurso de atualização automática. Para os sistemas de produção, seria raro ir além de patch. Além disso, ao atualizar automaticamente a versão do AKS, verifique também a configuração de versão do AKS da infraestrutura como código (IaC) do cluster do AKS para que eles não fiquem fora de sincronia. Configure o período de manutenção planejada para dar suporte a essa operação de atualização automática.

Monitoramento de segurança

Monitore sua infraestrutura de contêiner para ameaças ativas e possíveis riscos à segurança. Aqui estão alguns recursos:

• Microsoft Defender para contêineres para identificar e corrigir as recomendações do Defender para Nuvem nas imagens de contêiner.
• O Defender para contêineres verifica regularmente suas imagens de contêiner em busca de vulnerabilidades.
• O Defender para contêineres também gera alertas de segurança em tempo real para atividades suspeitas.
• Os conceitos de Segurança do AKS para aplicativos e clusters detalham informações sobre como a segurança de contêiner protege todo o pipeline de ponta a ponta, desde a compilação até as cargas de trabalho do aplicativo em execução no AKS.

Operações de cluster e carga de trabalho

Para considerações sobre DevOps (operações de cluster e carga de trabalho), consulte o pilar Princípios de design de Excelência operacional.

Inicialização do cluster

Depois de fazer o provisionamento, você tem um cluster em funcionamento, mas ainda pode ter algumas etapas necessárias antes de implantar as cargas de trabalho. O processo de preparação do cluster é chamado de inicialização. A inicialização pode consistir na implantação de imagens de pré-requisito em nós de cluster, na criação de namespaces e na execução de outras tarefas que atendam aos requisitos do caso de uso da sua organização.

Para diminuir a lacuna entre um cluster provisionado e um configurado corretamente, os operadores de cluster devem pensar em como é seu processo de inicialização exclusivo. Eles precisam preparar os ativos relevantes com antecedência. Por exemplo, se for importante ter o Kured em execução em cada nó antes de implantar as cargas de trabalho do aplicativo, o operador de cluster deverá verificar se já existe uma instância do Registro de Contêiner que contém a imagem do Kured de destino antes de provisionar o cluster.

Você pode configurar o processo de inicialização usando um dos seguintes métodos:

• Extensão do cluster GitOps Flux v2
• Pipelines
• Autoconfiguração com Flux ou Argo CD, por exemplo

Uma das principais vantagens de usar a extensão de cluster do GitOps Flux v2 para AKS é que não há efetivamente nenhuma lacuna entre um cluster provisionado e um cluster inicializado. Ele configura o ambiente com uma base de gerenciamento sólida no futuro, e também dá suporte à inclusão dessa inicialização como modelos de recursos para alinhar com sua estratégia de IaC.

Por fim, ao usar a extensão, o kubectl não é necessário para nenhuma parte do processo de inicialização. Você pode reservar o acesso baseado em kubectl para situações de reparo de emergência. Entre modelos para definições de recursos do Azure e a inicialização de manifestos por meio da extensão GitOps, você pode executar todas as atividades de configuração normais sem a necessidade de usar o kubectl.

Isolar responsabilidades de carga de trabalho

Divida a carga de trabalho por equipes e tipos de recursos para gerenciar individualmente cada parte.

Comece com uma carga de trabalho básica que contém os componentes fundamentais e compile nela. Uma tarefa inicial seria configurar a rede. Provisione redes virtuais para o hub e spokes e também para as sub-redes dentro dessas redes. Por exemplo, um spoke tem sub-redes separadas para pools de nós de sistema e usuário e recursos de entrada. Implante uma sub-rede para o Firewall do Azure no hub.

Outra tarefa é integrar a carga de trabalho básica ao Microsoft Entra ID.

Usar IaC

Escolha um método declarativo idempotente em vez de uma abordagem imperativa, sempre que possível. Em vez de escrever uma sequência de comandos que especificam opções de configuração, use a sintaxe declarativa que descreve os recursos e suas propriedades. Você pode usar Bicep, modelos do Azure Resource Manager (modelos do ARM) ou Terraform.

Certifique-se de provisionar os recursos de acordo com as políticas de governança. Por exemplo, ao selecionar os tamanhos da máquina virtual, fique dentro das restrições de custo e das opções de zona de disponibilidade para corresponder aos requisitos do aplicativo. Você também pode usar o Azure Policy para impor as políticas da sua organização para essas decisões.

Se for necessário escrever uma sequência de comandos, use a CLI do Azure. Esses comandos abrangem um intervalo de serviços do Azure e você pode automatizá-los por meio de scripts. CLI do Azure de suporte para Windows e Linux. Outra opção multiplataforma é o Azure PowerShell. Sua escolha depende do seu conjunto de habilidades preferido.

Armazene e controle a versão de scripts e arquivos de modelo no sistema de controle do código-fonte.

CI/CD da carga de trabalho

Os pipelines para fluxo de trabalho e implantação devem ter a capacidade de criar e implantar aplicativos continuamente. Atualizações devem ser implantadas com segurança e rapidez e revertidas caso haja problemas.

Sua estratégia de implantação precisa incluir um pipeline de entrega contínua confiável e automatizado. Implante automaticamente as alterações nas imagens do contêiner de carga de trabalho no cluster.

Nessa arquitetura, o GitHub Actions gerencia o fluxo de trabalho e a implantação. Outras opções populares incluem Azure DevOps e Jenkins.

CI/CD de cluster

Baixe um Arquivo Visio dessa arquitetura.

Em vez de usar uma abordagem imperativa como o kubectl, use ferramentas que sincronizam automaticamente as alterações de cluster e repositório. Para gerenciar o fluxo de trabalho, como o lançamento de uma nova versão e a validação dessa versão antes da implantação em produção, considere um fluxo GitOps.

Uma parte essencial do fluxo de CI/CD é a inicialização de um cluster recém-provisionado. Uma abordagem do GitOps é útil uma vez que ele permite que os operadores definam declarativamente o processo de inicialização como parte da estratégia de IaC e vejam a configuração refletida no cluster automaticamente.

Quando você usa o GitOps, um agente é implantado no cluster para garantir que o estado do cluster seja coordenado com a configuração armazenada em seu repositório Git privado. Um desses agentes é o flux, que usa um ou mais operadores no cluster para disparar implantações dentro do Kubernetes. O flux realiza estas tarefas:

• Monitora todos os repositórios configurados.
• Detecta novas alterações de configuração.
• Dispara implantações.
• Atualiza a configuração de execução desejada com base nessas alterações.

Também é possível definir políticas que regem como as alterações são implantadas.

Aqui está um exemplo que mostra como automatizar a configuração do cluster com o GitOps e Flux:

Baixe um Arquivo Visio dessa arquitetura.

1. Um desenvolvedor confirma alterações no código-fonte, como arquivos YAML de configuração, que são armazenados em um repositório Git. Em seguida, as alterações são enviadas por push para um servidor Git.

2. O Flux é executado no pod ao lado da carga de trabalho. O Flux tem acesso somente leitura ao repositório Git para garantir que só aplique alterações conforme solicitado pelos desenvolvedores.

3. O Flux reconhece as alterações na configuração e aplica essas alterações usando comandos kubectl.

4. Os desenvolvedores não têm acesso direto à API do Kubernetes por meio do kubectl.

Você pode ter políticas de ramificação em seu servidor Git para que vários desenvolvedores possam aprovar alterações por meio de uma solicitação de pull antes que a alteração seja aplicada à produção.

Enquanto o GitOps e o Flux podem ser configurados manualmente, recomendamos a extensão de cluster do GitOps com Flux v2 para AKS.

Estratégias de implantação de carga de trabalho e cluster

Implante qualquer alteração, como componentes de arquitetura, carga de trabalho e configuração de cluster, em pelo menos um cluster AKS de pré-produção. Isso simulará a alteração e poderá identificar problemas antes que eles sejam implantados na produção.

Execute testes e validações em cada estágio antes de passar para o próximo. Isso ajuda a garantir que você possa enviar atualizações para o ambiente de produção de maneira altamente controlada e minimizar a interrupção de problemas de implantação imprevistos. A implantação deve seguir um padrão semelhante ao da produção, usando o mesmo pipeline do GitHub Actions ou operadores Flux.

Técnicas avançadas de implantação, como implantação azul-verde, testes A/B e versões canário, exigirão processos adicionais e possivelmente outras ferramentas. O Flagger é uma solução popular de código aberto para solucionar cenários de implantação avançada.

Gerenciamento de custos

Para começar, consulte a lista de verificação de projeto de otimização de custos e a lista de recomendações descritas em Well Architected Framework for AKS. Use a calculadora de preços do Azure para estimar os custos para os serviços usados na arquitetura. Para obter outras práticas recomendadas, consulte Otimização de custos.

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

Para obter informações sobre considerações de gerenciamento de custos específicas do Windows, consulte Contêineres do Windows no AKS.

Provisionar o

• Entenda de onde vêm seus custos. Há custos mínimos associados à implantação, ao gerenciamento e às operações do AKS do próprio cluster do Kubernetes. O que afeta o custo são as instâncias de máquina virtual, o armazenamento, os dados de log e os recursos de rede que o cluster consome. Considere escolher VMs mais baratas para pools de nós do sistema. A série DS2_v2 é um tipo de máquina virtual típico para o pool de nós do sistema.

• Não use a mesma configuração para ambientes de desenvolvimento/teste e produção. As cargas de trabalho de produção têm requisitos extras para alta disponibilidade e serão geralmente mais caras. Essa configuração não é necessária no ambiente de desenvolvimento/teste.

• Adicione um SLA de tempo de atividade para cargas de trabalho de produção. Mas há economia em clusters projetados para cargas de trabalho de desenvolvimento/teste ou experimentais em que a disponibilidade não é necessária para ser garantida. Por exemplo, o SLO é suficiente. Além disso, se a carga de trabalho for compatível, considere o uso de pools de nós spot dedicados que executam VMs spot.

  Para cargas de trabalho de não produção que incluem o Banco de Dados SQL do Azure ou o Serviço de Aplicativo do Azure como parte da arquitetura de carga de trabalho do AKS, avalie se você tem qualificação para usar as assinaturas de Desenvolvimento/Teste do Azure para receber descontos no serviço.

• Provisione um cluster com número mínimo de nós e habilite o dimensionador automático de cluster para monitorar e tomar decisões de dimensionamento em vez de começar com um superdimensionado para atender às necessidades de dimensionamento.

• Defina solicitações e limites de pod para permitir que o Kubernetes aloque recursos de nó com densidade mais alta para que o hardware seja usado na capacidade.

• Considere que, quando você habilita o diagnóstico no cluster, isso pode aumentar o custo.

• Comprometa-se com Instâncias de máquina virtual reservadas do Azure de um ou três anos para reduzir os custos do nó se sua carga de trabalho for esperada por um longo período. Para saber mais, consulte Economize com Instâncias de máquinas virtuais reservadas do Azure.

• Use marcas ao criar pools de nós. As marcações ajudam quando você cria relatórios personalizados para rastrear os custos incorridos. Você pode usar marcações para acompanhar o total de despesas e mapear qualquer custo para um recurso ou equipe específica. Além disso, se o cluster for compartilhado entre as equipes, crie relatórios de estorno por consumidor para identificar os custos limitados dos serviços de nuvem compartilhados. Para saber mais, confira Especificar um taint, um rótulo ou uma marca para um pool de nós.

• Espere custos adicionais de largura de banda se sua carga de trabalho for em várias regiões e você replicar dados entre elas. Para saber mais, confira Preços de largura de banda.

• Crie orçamentos para permanecer dentro das restrições de custo identificadas pela organização. Crie orçamentos por meio do Gerenciamento de custos da Microsoft. Também é possível criar alertas para receber notificações quando determinados limites são excedidos. Para saber mais, confira Criar um orçamento usando um modelo.

Monitor

É possível monitorar todo o cluster, bem como o custo de computação, armazenamento, largura de banda, logs e firewall. O Azure oferece opções para monitorar e analisar custos:

• Assistente do Azure

• Gerenciamento de Custos da Microsoft

O ideal é monitorar seus custos em tempo real ou pelo menos em uma cadência regular. Em seguida, você poderá agir antes do final do mês, quando os custos já estiverem calculados. Monitore também as tendências mensais ao longo do tempo para não sair do orçamento.

Para tomar decisões orientadas por dados, identifique qual recurso, em um nível granular, incorre na maior parte do custo. Além disso, tenha uma boa compreensão dos medidores usados para calcular o uso de cada recurso. Por exemplo, analisando as métricas, você pode determinar se a plataforma está superdimensionada. É possível ver os medidores de uso nas métricas do Azure Monitor.

Otimizar

Siga as recomendações indicadas pelo Assistente do Azure. Há outras maneiras de otimizar:

• Habilite o dimensionador automático de cluster para detectar e remover nós subutilizados no pool de nós.

  Importante

  Alterar agressivamente as configurações do dimensionador automático de cluster, como configurações de nó mínimo e máximo para um pool de nós, para afetar os custos pode ter resultados contraproducentes. Por exemplo, se scale-down-unneeded-time for definido como 10 minutos e as configurações de nó mínimo e máximo forem modificadas a cada cinco minutos com base nas características da carga de trabalho, o número de nós nunca diminuirá. Isso ocorre porque o cálculo do tempo desnecessário para cada nó será redefinido devido à atualização das configurações do dimensionador automático de cluster.

• Escolha um SKU inferior para os pools de nós, se a carga de trabalho for compatível.

• Se o aplicativo não exigir escala de intermitência, analise as métricas de desempenho ao longo do tempo para dimensionar o cluster para o tamanho correto.

• Se a carga de trabalho for compatível, dimensione os pools de nós do usuário para 0 quando não houver expectativa para execução. Além disso, se não houver cargas de trabalho agendadas para execução no cluster, use o recurso Iniciar/Parar do AKS para desligar toda a computação, o que inclui o pool de nós do sistema e o plano de controle do AKS.

Para ver informações sobre custos, confira Preço do AKS.

Próximas etapas

• Arquitetura de microsserviços avançada do AKS
• Linha de base do AKS para clusters de várias regiões
• Cluster regulamentado do AKS para PCI-DSS 3.2.1
• Contêineres do Windows na arquitetura de referência de linha de base do AKS

Recursos relacionados

• Roteiro do AKS no GitHub
• Introdução ao Kubernetes
• Desenvolver e implantar aplicativos no Kubernetes
• Revisão do Azure Well-Architected Framework para AKS
• Acelerador de zona de destino do AKS
• Guia de operações de manutenção do AKS
• Arquitetura de microsserviços no AKS
• Usar o Firewall do Azure para ajudar a proteger um cluster AKS
• Operações do Git para AKS
• Streaming de dados com o AKS