Arquitetura de linha de base para um cluster do Azure Kubernetes Service (AKS)

Este artigo fornece uma arquitetura de infraestrutura de linha de base recomendada para implantar um cluster do Serviço Kubernetes do Azure (AKS). Utiliza os nossos princípios de design e baseia-se nas melhores práticas de arquitetura AKS do Azure Well-Architected Framework. Este artigo ajuda a orientar vários grupos interdisciplinares distintos, como equipes de rede, segurança e identidade, quando implantam essa infraestrutura de uso geral.

Essa arquitetura não está focada em uma carga de trabalho. Concentra-se no próprio cluster AKS. Esta informação é a linha de base mínima recomendada para a maioria dos clusters AKS. Integra-se com os serviços do Azure que fornecem observabilidade, fornecem uma topologia de rede que suporta o crescimento multirregional e protegem o tráfego no cluster.

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

O Kubernetes é um ecossistema poderoso que vai além das tecnologias Azure e Microsoft. Ao implantar um cluster AKS, você assume a responsabilidade por várias decisões sobre como seu cluster deve ser projetado e operado. A execução de um cluster AKS envolve uma combinação de componentes de código fechado de uma variedade de fornecedores, incluindo a Microsoft; e componentes de código aberto do ecossistema Kubernetes. A paisagem muda com frequência, e você pode precisar rever as decisões regularmente. Ao adotar o Kubernetes, você está reconhecendo que sua carga de trabalho precisa de seus 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-o como um ponto de partida alternativo e configure a arquitetura de referência com base em suas necessidades.

Configuração da rede

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

Computação em cluster

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

Gestão de identidades

Integrar o Microsoft Entra ID para o cluster
Integrar o Microsoft Entra ID para a carga de trabalho

Fluxo de dados seguro

Proteger o fluxo de rede
Adicionar gerenciamento secreto

Continuidade do negócio

Escalabilidade
Disponibilidade de cluster e nó
Disponibilidade e suporte multirregional

Operações

Pipelines de CI/CD de cluster e carga de trabalho
Integridade e métricas do cluster
Gestão de custos e relatórios

Topologia de rede

Essa arquitetura usa uma topologia de rede hub and spoke. Implante o hub e os raios em redes virtuais separadas que estão conectadas por meio de emparelhamento de rede virtual. Esta topologia tem várias vantagens. Use esta topologia para:

• Habilite o gerenciamento segregado. Você pode aplicar a governança e aderir ao princípio do menor privilégio. Ele também suporta o conceito de uma zona de pouso do Azure com uma separação de tarefas.

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

• Forneça topologias regionais de hub e spoke. Você pode expandir topologias de rede hub e spoke no futuro e fornecer isolamento de carga de trabalho.

• Use 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.

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

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

• Alinhe-se com a zona de aterrissagem em escala empresarial do Azure.

Transfira um ficheiro do Visio desta arquitetura.

Para obter mais informações, consulte 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 do hub

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

• Firewall do Azure com políticas de firewall globais, definidas pelas suas equipas centrais de TI para aplicar 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.

Dentro da 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 do 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 que não seja da Microsoft que pode exfiltrar dados confidenciais da carga de trabalho. Use o Gerenciador de Firewall do Azure para implantar e configurar centralmente várias instâncias do Firewall do Azure e gerenciar políticas de Firewall do Azure para esse tipo de arquitetura de rede virtual de hub.

Sub-rede para hospedar um gateway

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

Sub-rede para hospedar o Azure Bastion

Esta sub-rede é um espaço reservado para o Azure Bastion. Você pode usar o Azure Bastion para acessar com segurança os recursos do Azure sem expor os recursos à Internet. Esta sub-rede destina-se apenas a gestão e operações.

Rede virtual Spoke

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

Sub-rede para hospedar o Gateway de Aplicativo do Azure

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

Sub-rede para hospedar os recursos de entrada

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

Sub-rede para hospedar os nós do 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 serviços de cluster principais. O pool de nós do usuário executa sua carga de trabalho e o controlador de entrada para habilitar a comunicação de entrada com a carga de trabalho.

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

Crie conexões de Link Privado para o Registro de Contêiner do Azure e o Cofre de Chaves do Azure para que os usuários possam acessar esses serviços por meio de um ponto de extremidade privado dentro da rede virtual spoke. Os pontos de extremidade privados não exigem uma sub-rede dedicada. Você também pode colocar pontos de extremidade privados na rede virtual do hub. Na implementação de linha de base, os pontos de extremidade são implantados em uma sub-rede dedicada dentro da rede virtual falada. Essa abordagem reduz o tráfego que passa pela conexão de rede emparelhada. Ele 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, consulte Opções de implantação de Link Privado.

Planear os endereços IP

Transfira um ficheiro do Visio desta arquitetura.

Esta arquitetura de referência usa várias abordagens de rede, cada uma requer 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 CNI do Azure, que aloca endereços IP a pods de um espaço de endereçamento separado para sua rede virtual do Azure.

Espaço de endereço IP da rede virtual

O espaço de endereço da sua rede virtual do Azure deve ser grande o suficiente para armazenar todas as suas sub-redes. Conta para todas as entidades que recebem tráfego. O Kubernetes aloca endereços IP para essas entidades a partir do espaço de endereços da sub-rede. Considere esses pontos ao planejar os endereços IP da sua rede virtual do Azure.

• Atualizações: o AKS atualiza os nós regularmente para garantir que as VMs subjacentes estejam atualizadas sobre recursos de segurança e outros patches do sistema. Durante um processo de atualização, o AKS cria um nó que hospeda temporariamente os pods, enquanto o nó de atualização é isolado e drenado. Esse nó temporário recebe um endereço IP da sub-rede do cluster. Certifique-se de ter espaço de endereço suficiente para esses endereços IP de nó temporários.

  Nessa arquitetura, os pods são alocados endereços IP de dentro do espaço de endereço do pod de sobreposição CNI do Azure, inclusive durante atualizações contínuas. Essa abordagem reduz o número geral de endereços IP usados da sua rede virtual do Azure em comparação com outras abordagens de rede do Kubernetes.

• Escalabilidade: Leve em consideração a contagem de nós de todos os nós do sistema e do usuário e seu limite máximo de escalabilidade. Suponha que você queira expandir em 400%. Você precisa de quatro vezes o número de endereços para todos esses nós expandidos.

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

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

• Endereços IP reservados: o Azure reserva determinados endereços para seus usos. Eles não podem ser atribuídos.

A lista anterior não é exaustiva. Se o seu desenho ou modelo tiver outros recursos que afetem o número de endereços IP disponíveis, acomode esses endereços.

Essa arquitetura foi projetada para uma única carga de trabalho. Em um cluster AKS de produção, 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, convém isolar os pools de nós do usuário uns dos outros. Quando você faz isso, isso resulta em mais sub-redes que são menores em tamanho. Além disso, o recurso de entrada pode ser mais complexo e, como resultado, você pode precisar de vários controladores de entrada que exigem endereços IP extras.

Espaço de endereço IP do pod

A Sobreposição CNI do Azure atribui endereços IP a pods usando um espaço de endereçamento 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 à sua rede virtual ou a quaisquer redes virtuais emparelhadas. No entanto, se você criar vários clusters AKS, poderá usar com segurança o mesmo espaço de endereço pod em cada cluster.

A cada nó é atribuído um espaço de endereçamento /24 para seus pods, por isso é importante garantir que o espaço de endereçamento do pod seja suficientemente grande para permitir tantos blocos /24 quanto você precisar para o número de nós em seu 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, seu cluster poderá crescer até 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, consulte as orientações sobre o planejamento de endereços IP para a sobreposição CNI do Azure

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

Para obter o conjunto completo de considerações de rede para esta arquitetura, consulte Topologia de rede de linha de base AKS. Para obter informações relacionadas ao planejamento do endereçamento IP para um cluster AKS, consulte Planejar o endereçamento IP para seu 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 recursos de visualização

Kubernetes e AKS evoluem continuamente, com ciclos de lançamento mais rápidos do que o software para ambientes locais. Essa arquitetura de linha de base depende de recursos de visualização e complementos AKS selecionados. Aqui está a diferença entre os dois:

• A equipe do AKS descreve os recursos de visualização como enviados e melhorados porque muitos dos recursos de visualização permanecem nesse estado por apenas alguns meses antes de passar para a fase de disponibilidade geral (GA).

• Os complementos e extensões do AKS fornecem funcionalidades adicionais suportadas. O AKS gerencia sua instalação, configuração e ciclo de vida.

Essa arquitetura de linha de base não inclui todos os recursos de visualização ou complementos. Em vez disso, inclui apenas aqueles que agregam valor significativo a um cluster de uso geral. À medida que esses recursos saem da visualização, essa arquitetura de linha de base é revisada de acordo. Existem alguns outros recursos de visualização ou complementos AKS que você pode querer avaliar em clusters de pré-produção. Esses recursos podem melhorar sua segurança, capacidade de gerenciamento ou outros requisitos. Com complementos que não sejam da Microsoft, você deve instalá-los e mantê-los, incluindo o rastreamento de versões disponíveis e a instalação de atualizações após a atualização 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 várias outras imagens, como o controlador de entrada. Algumas dessas imagens podem residir em registos públicos. Considere esses pontos ao puxar as imagens para o cluster.

• Autentique o cluster para extrair a imagem.

• Importe uma imagem pública para o registro de contêiner que esteja alinhada com seu objetivo de nível de serviço (SLO), se você estiver usando uma imagem pública. Caso contrário, a imagem pode estar sujeita a problemas de disponibilidade inesperados. Se a imagem não estiver disponível quando você precisar, isso pode causar problemas operacionais. Aqui estão 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:

  • Pode bloquear o acesso não autorizado às suas imagens.
  • Você não tem dependências voltadas para o público.
  • Você pode acessar logs de extração de imagem para monitorar atividades e problemas de conectividade de triagem.
  • Você pode aproveitar a digitalização de contêineres integrada e a conformidade de imagens.

• Extraia imagens de registos autorizados. Você pode impor essa restrição por meio da Política do Azure. Nessa implementação de referência, o cluster só extrai imagens da instância do Registro de Contêiner que implanta.

Configurar a computação para o cluster base

No AKS, cada pool de nós é mapeado para um conjunto de escala de máquina virtual. Os nós são VMs em cada pool de nós. Considere o uso de um tamanho de VM menor para o pool de nós do sistema para 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 é de 512 GB.

Para o pool de nós de usuário, aqui estão algumas considerações:

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

• Selecione o tipo de VM apropriado se tiver requisitos específicos de carga de trabalho. 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, consulte Tamanhos para 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, você pode alterar a contagem de nós sem recriar o cluster.

• Planeje os tamanhos reais dos nós para sua carga de trabalho com base nos requisitos determinados pela sua 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 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 para seu cluster. Os restantes 20% estão reservados aos serviços AKS.

• Defina o máximo de pods por nó com base no seu planejamento de 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 operativo

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

O AKS também suporta pools de nós que executam o sistema operacional Windows Server. Há requisitos especiais para alguns aspetos de um cluster que executa o Windows. Para saber mais sobre a arquitetura do pool de nós do Windows, consulte Executando 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 sua carga de trabalho, recomendamos que use um único sistema operacional para todos os pools de nós da carga de trabalho.

Integrar o Microsoft Entra ID para o cluster

Proteger o acesso de e para o cluster é fundamental. Pense nisso da perspetiva do cluster ao fazer escolhas de segurança:

• Acesso de dentro para fora. Considere o acesso do AKS a componentes do Azure, como infraestrutura de rede, Registro de Contêiner e Cofre de Chaves. Autorize apenas os recursos que o cluster deve ter permissão para acessar.
• Acesso exterior-in. Forneça acesso de identidades ao cluster do Kubernetes. Autorize apenas as entidades externas que têm permissão de acesso ao servidor de API do Kubernetes e ao Gerenciador de Recursos do Azure.

Acesso do AKS ao Azure

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

Dos dois métodos para gerenciar o acesso do AKS ao Azure, recomendamos identidades gerenciadas. Com entidades de serviço, você deve gerenciar e girar segredos, manualmente ou programaticamente. Com identidades gerenciadas, o Microsoft Entra ID gerencia e executa a autenticação e a rotação oportuna de segredos para você.

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

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

Você deve usar identidades gerenciadas quando o cluster precisar extrair imagens de um registro de contêiner. Essa ação requer que o cluster obtenha as credenciais do Registro. Se você não usar uma identidade gerenciada, poderá armazenar essas informações na forma de um objeto secreto do Kubernetes e usá-las imagePullSecrets para recuperar o segredo. Não recomendamos essa abordagem devido a complexidades de segurança. Você não só precisa de conhecimento prévio do segredo, mas também precisa armazenar esse segredo dentro do pipeline de DevOps. Outra razão pela qual não recomendamos essa abordagem é a sobrecarga operacional de gerenciar a rotação do segredo. Em vez disso, conceda AcrPull acesso à identidade gerenciada kubelet do cluster ao seu registro. Esta abordagem dá resposta às preocupações.

Nessa arquitetura, o cluster acessa os recursos do Azure que o Microsoft Entra ID protege e o cluster executa operações que dão suporte a identidades gerenciadas. Atribua o controle de acesso baseado em função do Azure (Azure RBAC) e permissões às identidades gerenciadas do cluster, dependendo das operações que o cluster faz. O cluster autentica-se no Microsoft Entra ID e, em seguida, é permitido ou negado acesso 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 são atribuídas ao cluster:

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

• Função de Editor 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 extrair imagens das instâncias especificadas do Registro de Contêiner do Azure.

Acesso ao cluster

A integração do Microsoft Entra também simplifica a segurança para acesso externo. Por exemplo, você pode querer usar kubectl. Como etapa inicial, você pode executar o az aks get-credentials comando 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 de cluster. Para obter mais informações, consulte Permissões de funções de cluster disponíveis.

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

Associar o Kubernetes RBAC ao Microsoft Entra ID

O Kubernetes suporta RBAC através de:

• Um conjunto de permissões que você define usando um Role ou ClusterRole objeto 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 RoleBinding ou ClusterRoleBinding objeto.

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

Certifique-se de incluir os grupos do Microsoft Entra para acesso a cluster e namespace em suas revisões de acesso do Microsoft Entra.

Usar o RBAC do Azure para autorização do Kubernetes

Em vez de usar o RBAC ClusterRoleBindings nativo do Kubernetes 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 no cluster. Você pode até mesmo atribuir essas funções nos escopos do grupo de gerenciamento, da assinatura ou do grupo de recursos. Todos os clusters sob o 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 obter mais informações, consulte Azure RBAC para autorização do Kubernetes.

Contas locais

O AKS suporta 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 externamente ao seu provedor de identidade principal, o que dificulta o controle de acesso e a governança centralizados do usuário. Sempre gerencie o acesso ao cluster usando a ID do Microsoft Entra e configure o cluster para desabilitar explicitamente o acesso à conta local.

Nesta implementação de referência, o acesso às contas de cluster local é explicitamente desativado quando o sistema implanta o cluster.

Integrar o Microsoft Entra ID para a carga de trabalho

Semelhante a ter uma identidade gerenciada atribuída ao sistema do Azure para todo o cluster, 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 precisa acessar esses arquivos, o pod se autentica no recurso como uma identidade gerenciada do Azure.

Nesta implementação de referência, o ID de carga de trabalho do Microsoft Entra no AKS fornece as identidades gerenciadas para pods. Essa abordagem integra-se 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 suporta vários modelos de rede, incluindo kubenet, CNI e Azure CNI Overlay. Os modelos CNI são os mais avançados e de alto desempenho. Ao se comunicar entre pods, o desempenho da CNI é semelhante ao desempenho das VMs em uma rede virtual. A CNI também oferece controle de segurança aprimorado porque permite o uso da política de rede do Azure. Recomendamos um modelo de rede baseado em CNI.

No modelo CNI sem sobreposição, cada pod obtém um endereço IP do espaço de endereço da sub-rede. Recursos dentro da mesma rede (ou recursos emparelhados) podem acessar os pods diretamente através de seu endereço IP. A NAT (Network Address Translation) não é necessária para rotear esse tráfego.

Nesta implementação de referência, usamos a Sobreposição 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 CNI do Azure usa menos endereços IP de rede virtual do que muitas outras abordagens, recomendamos isso para implantações com restrição de endereço IP.

Para obter informações sobre os modelos, consulte Escolher um modelo de rede de Interface de Rede de Contêiner para usar e Comparar modelos de rede kubenet e de Interface de Rede de Contêiner do Azure.

Implementar recursos de entrada

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

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

  Essa arquitetura usa o Azure Load Balancer. O Balanceador de Carga está fora do cluster em uma sub-rede dedicada para recursos de entrada. Ele recebe tráfego do Application Gateway e essa comunicação é sobre a segurança da camada de transporte (TLS). Para obter mais informações sobre a criptografia TLS para tráfego de entrada, consulte Fluxo de tráfego de entrada.

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

O controlador de entrada é um componente crítico do cluster. Considere os seguintes pontos ao configurar este componente.

• Restrinja o controlador de entrada a um escopo específico de operações como parte de suas decisões de projeto. 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 este fim.

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

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

• Configure readinessProbe e livenessProbe configurações que monitoram a integridade dos pods no intervalo especificado. O controlador de ingresso deve enviar sinais que indiquem a saúde dos pods.

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

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 de router

O controlador de entrada usa rotas para determinar para onde enviar 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:

Traefik usa o provedor Kubernetes para configurar rotas. As annotationsopções , tlse indicam entrypoints que as rotas são servidas por HTTPS. A middlewares opção especifica que somente o tráfego da sub-rede do Application Gateway é permitido. As respostas usam codificação gzip se o cliente aceitar. Como Traefik faz terminação TLS, a comunicação com os serviços 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

Nesta arquitetura, o fluxo de rede inclui:

• Ingresse o tráfego do cliente para a carga de trabalho executada no cluster.

• Saída de tráfego de um pod ou nó no cluster para um serviço externo.

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

• Gerenciamento de tráfego entre o cliente e o servidor de API do Kubernetes.

Transfira um ficheiro do Visio desta arquitetura.

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

Fluxo de tráfego de entrada

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

Transfira um ficheiro do Visio desta arquitetura.

1. O cliente envia uma solicitação HTTPS para o nome de domínio: bicycle.contoso.com. Esse nome está associado a um registro DNS A para o endereço IP público do Application Gateway. 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 Application Gateway tem um firewall de aplicativo da Web integrado e negocia o handshake TLS para bicycle.contoso.com, permitindo apenas cifras seguras. O Application Gateway é um ponto de terminação TLS, o que é importante porque o firewall do aplicativo Web do Application Gateway precisa inspecionar a resposta de texto sem formatação. O Key Vault armazena o certificado TLS. O cluster acessa-o com uma identidade gerenciada atribuída pelo usuário que é integrada ao Application Gateway. Para obter mais informações, veja Terminação TLS com certificados do Key Vault.

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

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

4. O controlador de entrada recebe o tráfego criptografado através do balanceador de carga. O controlador é outro ponto de terminação TLS e *.aks-ingress.contoso.com encaminha o tráfego para os pods de carga de trabalho por HTTP. Os certificados são armazenados no Cofre da Chave e o driver CSI (Container Storage Interface) os monta no cluster. Para obter mais informações, consulte Adicionar gerenciamento secreto.

Você pode implementar tráfego TLS de ponta a ponta a cada salto através do pod de carga de trabalho. Certifique-se de medir o desempenho, a latência e os efeitos operacionais ao tomar a decisão de proteger o tráfego de pod para pod. Para a maioria dos clusters de locatário único, com RBAC de 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 Web Application Firewall. Essa abordagem minimiza a sobrecarga no gerenciamento de carga de trabalho e sobrecarga devido ao baixo desempenho da rede. Sua carga de trabalho e requisitos de conformidade ditam onde você executa a rescisã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 seu próprio dispositivo virtual de rede semelhante. Não recomendamos o uso de outras opções de saída, como o Gateway NAT do Azure ou um proxy HTTP, pois elas não fornecem inspeção de tráfego de rede. Para o controle Zero Trust e a capacidade de inspecionar o tráfego, todo o tráfego de saída do cluster é movido pelo Firewall. Você pode implementar essa configuração com rotas definidas pelo usuário (UDRs). O próximo salto da rota é o endereço IP privado do Firewall do Azure. O Firewall do Azure decide se bloqueia ou permite o tráfego de saída. Essa decisão é baseada 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 de proxy HTTP 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.

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

Uma exceção ao controle Zero Trust é quando o cluster precisa se comunicar com outros recursos do Azure. Por exemplo, o cluster pode precisar extrair uma imagem atualizada do registro do contêiner ou segredos do Cofre da Chave. Nesses cenários, recomendamos que você use o Private Link. A vantagem é que sub-redes específicas alcançam o serviço diretamente e o tráfego entre o cluster e os serviços não passa pela Internet. Uma desvantagem é que o Private Link precisa de configuração extra 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 oferecem suporte ao Private Link. Para esses casos, considere habilitar 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 das regras do Firewall do Azure e do firewall interno ao serviço de destino. Como esse tráfego passa pelos endereços IP estáticos do firewall, você pode adicionar esses endereços à lista de permissões de IP do serviço. Uma desvantagem é que o Firewall do Azure precisa de mais regras para garantir que ele permita apenas o tráfego de uma sub-rede específica. Considere esses endereços quando estiver planejando vários endereços IP para tráfego de saída com o Firewall do Azure. Caso contrário, você pode chegar à exaustão do porto. 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-to-pod

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

Habilite a diretiva de rede ao provisionar o cluster porque não é possível adicioná-lo posteriormente. Você tem algumas opções para tecnologias que implementam NetworkPolicyo . 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, consulte a seguinte nota. Outras opções incluem a política de rede Calico, uma opção de código aberto bem conhecida. Considere o Calico se precisar gerenciar políticas de rede em todo o cluster. O Calico não é coberto pelo suporte padrão do Azure.

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

Gestão de tráfego

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 na sub-rede do Azure Bastion e os próprios pools de nós. Em vez de aceitar esse tráfego de gerenciamento de todos os endereços IP, use o recurso de intervalos de IP autorizados pelo AKS para permitir apenas o tráfego de seus intervalos de IP autorizados para o servidor de API

Para obter mais informações, consulte Definir intervalos de IP autorizados pelo servidor de API.

Para outra camada de controle, ao custo de complexidade extra, você pode provisionar um cluster AKS privado. Usando um cluster privado, você pode ajudar a garantir que o tráfego de rede entre o servidor de API e os pools de nós permaneça apenas na rede privada e nunca seja exposto à Internet. Para obter mais informações, consulte Clusters privados do AKS.

Adicionar a gestão de segredos

Armazene segredos em um armazenamento de chaves gerenciado, como o Cofre de Chaves. A vantagem é que um armazenamento de chaves gerenciado lida com a rotação de segredos. Ele fornece criptografia forte e um log de auditoria de acesso. Ele também mantém os principais segredos fora do pipeline de implantação. Nessa arquitetura, um firewall do Cofre da Chave é 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 Application Gateway acessa certificados TLS para o fluxo de entrada, consulte a seção Fluxo de tráfego de entrada.

O modelo de permissão RBAC do Azure para o Cofre da Chave permite atribuir as identidades da carga de trabalho à atribuição de função Usuário de Segredos do Cofre da Chave ou Leitor do Cofre de Chaves e acessar os segredos. Para obter mais informações, consulte Cofre da chave de acesso usando RBAC.

Acessar segredos de cluster

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

O driver CSI tem muitos provedores para suportar várias lojas gerenciadas. Esta implementação usa o Key Vault com o driver CSI de armazenamento de segredos. O complemento recupera o certificado TLS do Cofre da Chave 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 as chaves pública e privada.

Armazenamento de carga de trabalho

A carga de trabalho nessa arquitetura é sem monitoração de estado. Se você precisar armazenar o estado, recomendamos mantê-lo fora do cluster. As diretrizes para o estado da carga de trabalho estão fora do escopo deste artigo.

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

Gestão de políticas

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

Para gerenciar seus clusters AKS, você pode usar a Política do Azure para:

• Impeça ou restrinja a implantação de clusters 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 tag.
• Proteja o seu cluster AKS através da Política do Azure para Kubernetes.

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

• Pretende definir um conjunto de políticas, também designadas iniciativas, ou escolher políticas individuais? A Política do Azure fornece duas iniciativas internas: básica e restrita. Cada iniciativa é uma coleção de políticas internas aplicáveis a um cluster 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 Cofre de Chaves, que interagem com o cluster. Escolha políticas com base nos requisitos da sua organização.

• Deseja auditar ou negar a ação? No modo de auditoria , a ação é permitida, mas sinalizada como não compatível. Tenha processos para verificar estados não conformes em uma cadência regular e tome as medidas necessárias. No modo Negar , a ação é bloqueada porque viola a política. Tenha cuidado ao escolher esse modo, pois ele pode ser muito restritivo para que a carga de trabalho funcione.

• Você tem áreas em sua carga de trabalho que não devem ser compatíveis por design? A Política do Azure tem a capacidade de especificar namespaces do Kubernetes que estão isentos da imposição de políticas. Recomendamos que você ainda aplique políticas no modo de auditoria para estar ciente dessas instâncias.

• Você tem requisitos que não são cobertos pelas políticas internas? Você pode criar uma definição personalizada de Política do Azure que aplique suas políticas personalizadas do OPA Gatekeeper. 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 em toda a organização? Em caso afirmativo, adicione essas políticas no nível do grupo de gerenciamento. O cluster também deve atribuir suas 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? Certifique-se de que as políticas de produção também sejam validadas em relação ao seu ambiente de pré-produção. Caso contrário, ao implantar em seu ambiente de produção, você poderá se deparar com restrições extras inesperadas que não são contabilizadas na pré-produção.

Esta implementação de referência habilita a Política do Azure quando o cluster AKS é criado. A iniciativa restritiva é atribuída no modo de auditoria para obter visibilidade sobre o incumprimento.

A implementação também define políticas extras 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 as imagens sejam extraídas apenas da instância do Registro de Contêiner implantada. Considere criar suas próprias iniciativas personalizadas. Combine as políticas aplicáveis à sua carga de trabalho em uma única atribuição.

Para observar como a Política do Azure funciona de dentro do cluster, você pode acessar os logs de pod para todos os gatekeeper-system pods no namespace e os logs para os azure-policy e azure-policy-webhook pods no kube-system namespace.

Para obter mais informações sobre considerações sobre a Política do Azure específica do Windows, consulte o artigo Contêineres do Windows no gerenciamento de políticas do AKS.

Escalabilidade de nós e pods

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

Existem 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 o dimensionamento de pods, seu operador de aplicativo pode aumentar ou diminuir o número de réplicas de pods ajustando as ReplicaSet APIs do Kubernetes. Para o dimensionamento de cluster, um método deve ser notificado quando o agendador do Kubernetes falhar. Outra maneira é observar os pods pendentes ao longo do tempo. Você pode 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 incorporados ao autoscaler.

Como método geral, comece por testar o desempenho com um número mínimo de pods e nós. Use esses valores para estabelecer a expectativa da 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. Finalmente, use esses dados para definir os parâmetros para dimensionamento automático. Para obter mais informações sobre um cenário de ajuste de desempenho usando o AKS, consulte Cenário de ajuste de desempenho: transações comerciais distribuídas.

Dimensionador Automático de Pods Horizontal

O Horizontal Pod Autoscaler (HPA) é 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 da memória e nas métricas personalizadas. Somente o uso da CPU é fornecido fora da caixa. A HorizontalPodAutoscaler definição 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 de destino e calcula uma proporção. Em seguida, ele usa a proporção para determinar se os pods estão superalocados ou subalocados. Ele depende do agendador do Kubernetes para atribuir novos pods aos nós ou remover pods dos nós.

Pode haver uma condição de corrida em que o HPA verifica antes que uma operação de dimensionamento termine. O resultado pode ser um cálculo de proporção incorreto. Para obter mais informações, consulte Cooldown de eventos de dimensionamento.

Se sua carga de trabalho for orientada a eventos, uma opção de código aberto popular é o Kubernetes event-driven autoscaling (KEDA). Considere o KEDA se uma fonte de eventos, como fila de mensagens, direcionar sua carga de trabalho, em vez de sua carga de trabalho ser vinculada à CPU ou à memória. O KEDA suporta muitas fontes de eventos ou escaladores. Use a lista de fontes de eventos que o KEDA pode dimensionar em escaladores KEDA. A lista inclui o escalonador do Azure 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 autoscaler de cluster é um componente complementar 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 autoscaler de cluster separado para cada pool de nós de usuário.

O agendador do Kubernetes aciona o autoscaler do cluster. Quando o agendador do Kubernetes não consegue agendar um pod devido a restrições de recursos, o autoscaler provisiona automaticamente um novo nó no pool de nós. Por outro lado, o autoscaler do 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 ativar o autoscaler, 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. Nesta 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 considerações de dimensionamento específicas do Windows incluídas nesta arquitetura de referência de linha de base, consulte o artigo Contêineres do Windows no AKS .

Decisões de continuidade de negócios

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

Nós do cluster

Para atender ao nível mínimo de disponibilidade para cargas de trabalho, você precisa de 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 nada menos que dois nós. Se você precisar de maior disponibilidade, provisione mais nós.

Isole seu aplicativo dos serviços do sistema colocando-o em um pool de nós separado, conhecido como pool de nós de usuário. Dessa forma, os serviços do Kubernetes são executados em nós dedicados e não competem com sua carga de trabalho. Recomendamos que você use tags, rótulos e manchas para identificar o pool de nós e agendar sua carga de trabalho. Certifique-se de que o pool de nós do sistema está contaminado com a CriticalAddonsOnly mancha.

A manutenção regular do cluster, como atualizações oportunas, é crucial para a confiabilidade. Além disso, recomendamos que você monitore a saúde dos pods através de sondas.

Disponibilidade do pod

Especificar requisitos de recursos de pod: recomendamos que você especifique os requisitos de recursos de pod em suas implantações. O agendador pode então agendar adequadamente o pod. A confiabilidade é muito reduzida se seus pods não puderem ser programados.

Definir orçamentos de interrupção de pod: essa configuração determina quantas réplicas em uma implantação podem cair durante um evento de atualização ou atualização. Para obter mais informações, consulte Orçamentos de interrupção de 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 o número necessário de réplicas de pod exista 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 de pod sejam definidos corretamente em uma implantação. Para obter mais informações, consulte Impor cotas de recursos.

Definir solicitações e limites de pod: definir solicitações e limites permite que o Kubernetes aloque recursos de CPU e memória de forma eficiente para os pods e permite que você tenha maior densidade de contêineres em um nó. Solicitações e limites também podem aumentar sua confiabilidade enquanto reduzem seus custos devido ao melhor uso de hardware.

Para estimar os limites de uma carga de trabalho, testar e estabelecer uma linha de base. Comece com valores iguais para solicitações e limites. Em seguida, ajuste gradualmente esses valores até estabelecer um limite que possa causar instabilidade no cluster.

Você pode especificar solicitações e limites em seus manifestos de implantação. Para obter mais informações, consulte Definir solicitações e limites de pod.

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

Para se proteger contra alguns tipos de interrupções, use zonas de disponibilidade se a região as suportar. Os componentes do plano de controle e os nós nos pools de nós são entã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 escala de máquina virtual separado, que gerencia instâncias de nó e escalabilidade. O serviço AKS gerencia as operações e a configuração do conjunto de escalas. Aqui estão algumas considerações quando você habilita várias zonas:

• Infraestrutura inteira: escolha uma região que ofereça suporte a zonas de disponibilidade. Para obter mais informações, consulte Limitações. Para ter um SLA de tempo de atividade, você precisa escolher o nível Standard ou Premium. O SLA de tempo de atividade é maior ao usar zonas de disponibilidade.

• Cluster: Você só pode definir zonas de disponibilidade ao criar o pool de nós. Eles não podem ser alterados mais tarde. Os tamanhos dos nós devem ser suportados em todas as zonas para que a distribuição esperada seja possível. O conjunto de dimensionamento de máquina virtual subjacente fornece a mesma configuração de hardware entre zonas.

  O suporte a várias zonas não se aplica apenas aos pools de nós, mas também ao plano de controle. O plano de controle AKS abrange as zonas solicitadas, como os pools de nós. Se você não usar o suporte a zonas em seu cluster, não é garantido que os componentes do plano de controle se espalhem pelas zonas de disponibilidade.

• Recursos dependentes: Para obter um benefício zonal completo, todas as dependências de serviço também devem oferecer suporte a zonas. Se um serviço dependente não suportar zonas, é possível que uma falha de zona possa fazer com que esse serviço falhe.

  Por exemplo, um disco gerenciado está disponível na zona onde foi provisionado. Se ocorrer uma falha, o nó pode ser movido para outra zona, mas o disco gerenciado não se move com o nó para essa zona.

Para simplificar essa 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 o Firewall do Azure e o Gateway de Aplicativos, também são implantados na mesma região com suporte a várias zonas. A replicação geográfica está habilitada para o Registro de Contêiner.

Várias regiões

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

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

• Forneça o local onde o serviço redundante tem sua instância secundária se um recurso do Azure oferecer 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 às imagens, mesmo que a região principal sofra uma interrupção.

• Escolha um roteador de tráfego que possa distribuir o tráfego entre zonas ou regiões, dependendo da sua necessidade. Essa arquitetura implanta o Balanceador de Carga porque ele pode distribuir tráfego não da Web entre zonas. Se você precisar distribuir o tráfego entre regiões, considere o Azure Front Door. Para outras opções, consulte Escolher um balanceador de carga.

Recuperação após desastre

Se ocorrer uma falha na região primária, idealmente, você poderá criar rapidamente uma nova instância em outra região. Veja a seguir algumas recomendações:

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

• Use uma carga de trabalho sem monitoração de estado que você possa replicar de forma eficiente. Se você precisar armazenar o estado no cluster, o que não recomendamos, certifique-se de fazer backup dos dados com freqüência em outra região.

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

• Provisione cada serviço do Azure usando recursos que dão suporte à recuperação de desastres. Por exemplo, nessa arquitetura, o Registro de Contêiner está habilitado para replicação geográfica. Se uma região falhar, você ainda poderá extrair imagens da região replicada.

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

Backup de cluster

Para muitas arquiteturas, você pode provisionar um novo cluster e retorná-lo ao estado operacional por meio da inicialização de cluster baseada em operações Git, seguida pela implantação de aplicativos. Mas se houver um estado crítico dos recursos, como mapas de configuração, trabalhos e segredos que não podem ser capturados no processo de inicialização, considere sua estratégia de recuperação. Recomendamos que você execute cargas de trabalho sem estado no Kubernetes. Se sua arquitetura envolver o 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 de sua estratégia de recuperação, você precisa 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 VMware Velero é um exemplo de uma solução comum de backup do Kubernetes que você pode instalar e gerenciar diretamente. Ou você pode usar a extensão de backup AKS para fornecer uma implementação gerenciada do Velero. A extensão de backup AKS suporta 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, que envolve recursos extras do Azure para gerenciar, monitorar, comprar e proteger. Esses recursos podem incluir uma conta de Armazenamento do Azure, um cofre e configuração do Backup do Azure e o recurso de acesso confiável. Em vez disso, as operações Git combinadas com a intenção de executar carga de trabalho sem estado são 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 de equipe e pratique-o para todas as cargas de trabalho críticas para os negócios.

SLA do servidor API do Kubernetes

Você pode usar o AKS como um serviço gratuito, mas esse nível não oferece um SLA apoiado financeiramente. Para obter um SLA, você deve escolher a camada Padrão. Recomendamos que todos os clusters de produção usem a camada Padrão. Reserve o nível Gratuito para clusters de pré-produção e o nível Premium apenas para cargas de trabalho de missão crítica. 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 por seus próprios SLAs. Para obter mais informações sobre SLAs específicos para cada serviço, consulte SLA para serviços online.

Compensação

Há uma compensação de custo para disponibilidade para implantar a arquitetura em zonas e, especialmente, regiões. Alguns recursos de replicação, como a replicação geográfica no Container Registry, 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 as taxas de largura de banda se aplicam quando o tráfego se move entre regiões.

Além disso, espere latência de rede extra na comunicação de nó entre zonas ou regiões. Meça o efeito dessa decisão de arquitetura em sua carga de trabalho.

Testar com simulações e ativações pós-falha forçadas

Teste a confiabilidade da sua solução por meio de testes de failover forçados com interrupções simuladas. As simulações podem incluir parar um nó, derrubar todos os recursos AKS em uma zona específica para simular uma falha zonal ou invocar 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 logs e métricas

Recomendamos o Azure Monitor de informações de contêiner para monitorar o desempenho de cargas de trabalho de contêiner porque você pode exibir eventos em tempo real. Ele captura logs de contêiner dos pods em execução e os agrega para visualização. Ele também 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 informações de contêiner para monitorar o desempenho à medida que os pods são dimensionados. Ele inclui telemetria que é crítica para monitoramento, análise e visualização dos dados coletados. O Container insights identifica tendências e permite configurar alertas para receber notificações proativas sobre problemas críticos.

O de esquema de log ContainerLogV2 do foi projetado para capturar logs de contêiner de pods do Kubernetes em uma abordagem simplificada. As entradas de log são consolidadas na tabela ContainerLogV2 em um espaço de trabalho do Azure Log Analytics.

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

Algumas soluções que não são da Microsoft integram-se ao Kubernetes, como Datadog, Grafana ou New Relic. Portanto, se a 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 para os componentes do plano de controle AKS como logs de recursos. Recomendamos que você habilite as seguintes opções 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 obter mais informações, consulte Recuperar logs e status do autoscaler do cluster.
• KubeControllerManager: obtenha 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á razão para ter ambos kube-audit e kube-audit-admin habilitado. kube-audit é um superconjunto que kube-audit-admin inclui operações sem modificação (leitura) também.
• guard: capturar auditorias do Microsoft Entra ID e do Azure RBAC.

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 de cluster, o posicionamento e o agendamento de pods adicionados e 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 estendidos em tempo integral após o término de suas necessidades de solução de problemas, você pode estar incorrendo em custos desnecessários para ingerir e armazenar os 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 ajudar a criar suas próprias consultas. À medida que sua biblioteca cresce, você pode salvar e reutilizar consultas de log usando um ou mais pacotes de consultas. Sua biblioteca personalizada de consultas fornece mais observabilidade sobre a integridade e o desempenho de seus clusters AKS. Ele suporta o alcance de seus SLOs.

Para obter mais informações sobre nossas práticas recomendadas de monitoramento para o 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

Métricas básicas de rede no nível de cluster estão disponíveis por meio de métricas de plataforma nativa e Prometheus. Você pode usar ainda mais a observabilidade da rede AKS para expor métricas de rede no nível do nó usando métricas Prometheus. A maioria dos clusters deve incluir a observabilidade da rede para fornecer recursos extras de solução de problemas de rede e para detetar o uso inesperado da rede ou problemas no nível do nó.

A implementação de referência usa insights de contêiner do Azure Monitor, que também coleta algumas métricas relacionadas à rede. A implementação de referência desabilita a coleta de métricas de insights de contêiner do Azure Monitor e, em vez disso, coleta as métricas de observabilidade de rede usando um espaço de trabalho do Azure Monitor com Prometheus gerenciado.

Para cargas de trabalho altamente sensíveis à perda de pacotes, latência ou pressão de DNS do protocolo TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol), 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 avançado de observabilidade de rede. A maioria das cargas de trabalho não requer essa profundidade de observabilidade de rede. Você não deve habilitar a observabilidade avançada da rede, a menos que seus pods exijam uma rede altamente otimizada, com sensibilidade até o nível do pacote.

Otimização de custos para registro em log

A implementação de referência configura a tabela ContainerLogV2 para usar o plano Básico como ponto de partida. O Microsoft Defender for Containers e os alertas criados para a implementação de referência não consultam esta tabela, portanto, o plano Basic provavelmente será econômico porque reduz os custos de ingestão.

À medida que o volume de log e os requisitos de consulta evoluem, selecione o plano de tabela mais econômico para suas necessidades. Se a solução se tornar intensiva em leitura, onde as consultas frequentemente verificam os dados da tabela, o plano padrão do Google Analytics pode ser mais adequado. O plano do Google Analytics elimina as cobranças de consulta, o que otimiza para cenários em que a atividade de consulta supera os custos de ingestão. Ao monitorar padrões de uso e ajustar os planos de tabela conforme necessário, você pode obter um equilíbrio entre custo e funcionalidade para sua solução de monitoramento.

Para obter mais informações, consulte Selecionar um plano de tabela com base no uso de dados em um espaço de trabalho do Log Analytics.

Habilite a autorrecuperação

Monitore a integridade dos pods definindo sondas de vivacidade e prontidão. Se o Kubernetes detetar um pod sem resposta, ele reiniciará o pod. Uma sonda de vivacidade determina se a cápsula está saudável. Se o Kubernetes detetar um pod sem resposta, ele reiniciará o pod. Uma sonda de prontidão determina se o pod está pronto para receber solicitações e tráfego.

Atualizações de rotina para clusters AKS

Parte das operações do dia 2 para clusters Kubernetes é executar atualizações rotineiras da plataforma e do sistema operacional. Há três camadas de atualizações para abordar em cada cluster 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 depreciações da API do Kubernetes. As alterações de versão nessa camada afetam todo o cluster.
• A imagem do disco rígido virtual (VHD) em cada nó, que combina atualizações do sistema operacional e atualizações de componentes 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 o Windows Update ou apto . 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 destas camadas é controlada de forma independente. Você decide como cada camada é tratada para os clusters da sua carga de trabalho. Escolha com que frequência cada cluster AKS, seus pools de nós ou seus nós são atualizados (a cadência). Além disso, escolha os dias ou horários para aplicar as atualizações (sua janela de manutenção). Escolha se as atualizações são instaladas manualmente ou automaticamente ou não. Assim como a carga de trabalho executada em seu cluster precisa de uma prática de implantação segura, o mesmo acontece com as atualizações em seus clusters.

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

Infraestrutura imutável

As cargas de trabalho que operam clusters AKS como infraestrutura imutável não atualizam automática ou manualmente seus clusters. 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 fica disponível, você deve 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 VHDs do pool de nós. Quando o novo cluster de produção está pronto, o cluster antigo é 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 AKS como infraestrutura imutável devem atualizar regularmente seus clusters em execução, para abordar todas as três camadas. Alinhe o 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 de manutenção planejada do AKS para que você possa controlar as atualizações em 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 pod 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 a ponto de impedir que atualizações de nó aconteçam, porque a maioria das atualizações requer um processo de cordão e drenagem em cada nó.
• Confirme a cota de recursos do Azure e a disponibilidade de recursos. As atualizações in-loco implantam novas instâncias de nós, conhecidas como nós de surto, 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 aumento 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 que você adicionou ao cluster. E teste seus componentes de carga de trabalho, como controladores de entrada, malhas de serviço e seus pods de carga de trabalho. Faça testes em um ambiente de pré-produção.

Atualizações in-loco para nós

Use o canal de atualização automática para atualizações de imagem do NodeImage sistema operacional do nó. Esse canal configura seu 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 cerca de uma vez por mês. Para nós Linux, essas atualizações acontecem cerca de uma vez por semana.

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

Se os requisitos de segurança do cluster exigirem uma cadência de aplicação de patches mais agressiva e o cluster puder tolerar possíveis interrupções, use o canal de SecurityPatch atualização. A Microsoft também testa essas atualizações. As atualizações só são publicadas se houver atualizações de segurança que a Microsoft considere importantes o suficiente para serem lançadas antes da próxima atualização de imagem de nó agendada. Quando você usa o SecurityPatch canal, você também recebe as atualizações que o NodeImage canal recebeu. A SecurityPatch opção de canal ainda honra suas janelas de manutenção, portanto, certifique-se de que sua janela de manutenção tenha lacunas mais frequentes (como diárias ou em dias alternados) para suportar 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 imagem e None nóUnmanaged.

Atualizações in-loco para o cluster

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

A maioria dos clusters deve ser capaz de realizar atualizações de versão do AKS in-loco com cautela e rigor suficientes. O risco de realizar uma atualização de versão do AKS in-loco pode ser mitigado principalmente por meio de testes de pré-produção suficientes, validação de cotas 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 implantação azul-verde da abordagem de clusters AKS em vez de seguir as recomendações restantes.

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

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

Você pode eventualmente chegar ao ponto de confiança com as versões do Kubernetes, as versões do AKS, seu cluster, seus componentes de nível de 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 patch. Além disso, ao atualizar automaticamente sua versão do AKS, verifique também a configuração da versão do AKS da sua infraestrutura como código (IaC) para o seu cluster para que eles não fiquem fora de sincronia. Configure a janela de manutenção planejada para dar suporte à operação de atualização automática.

Controlo de segurança

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

• Microsoft Defender for Containers para identificar e corrigir as recomendações do Defender for Cloud para suas imagens de contêiner.
• O Defender for Containers verifica regularmente suas imagens de contêiner em busca de vulnerabilidades.
• O Defender for Containers 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 de aplicativos em execução no AKS.

Operações de cluster e carga de trabalho

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

Inicialização de cluster

Depois de fazer o provisionamento, você tem um cluster de trabalho, mas ainda pode ter algumas etapas necessárias antes de implantar cargas de trabalho. O processo de preparação do cluster é chamado de bootstrapping. A inicialização pode consistir em implantar imagens de pré-requisito em nós de cluster, criar namespaces e executar 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. Têm de preparar antecipadamente os ativos relevantes. Por exemplo, se ter o Kured em execução em cada nó antes de implantar cargas de trabalho de aplicativo for importante, o operador de cluster deverá verificar se uma instância do Registro de Contêiner que contém a imagem Kured de destino já existe antes de provisionar o cluster.

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

• Extensão de cluster GitOps Flux v2
• Pipelines
• Auto-configuração com Flux ou Argo CD, por exemplo

Uma das principais vantagens de usar a extensão de cluster GitOps Flux v2 para AKS é que efetivamente não há 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 suporta a inclusão desse bootstrapping como modelos de recursos para alinhar com sua estratégia de IAC.

Finalmente, 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 correção de quebra 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 kubectl.

Isolar as responsabilidades da 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 contenha os componentes fundamentais e construa com base nela. Uma tarefa inicial é configurar a rede. Provisione redes virtuais para o hub e raios e também 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 com o Microsoft Entra ID.

Utilizar o 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 sintaxe declarativa que descreva os recursos e suas propriedades. Você pode usar Bicep, modelos do Azure Resource Manager (modelos ARM) ou Terraform.

Certifique-se de provisionar recursos de acordo com as políticas de governo. Por exemplo, quando você seleciona tamanhos de VM, fique dentro das restrições de custo e das opções de zona de disponibilidade para corresponder aos requisitos do seu aplicativo. Você também pode usar a Política do Azure para impor as políticas da sua organização para essas decisões.

Se você precisar escrever uma sequência de comandos, use a CLI do Azure. Esses comandos abrangem uma variedade de serviços do Azure e você pode automatizá-los por meio de scripts. O Windows e o Linux suportam a CLI do Azure. Outra opção de plataforma cruzada é o Azure PowerShell. A sua escolha depende do seu conjunto de competências preferido.

Armazene e faça a versão de seus scripts e arquivos de modelo em seu sistema de controle do código-fonte.

Carga de trabalho CI/CD

Os pipelines para fluxo de trabalho e implantação devem ser capazes de criar e implantar aplicativos continuamente. As atualizações devem ser implantadas com segurança e rapidez e reverter caso haja problemas.

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

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

Cluster CI/CD

Transfira um ficheiro do Visio desta arquitetura.

Em vez de usar uma abordagem imperativa como o kubectl, use ferramentas que sincronizem 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 nessa versão antes da implantação na produção, considere um fluxo GitOps.

Uma parte essencial do fluxo de CI/CD é inicializar um cluster recém-provisionado. Uma abordagem GitOps é útil porque permite que os operadores definam declarativamente o processo de inicialização como parte da estratégia 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.
• Deteta novas alterações de configuração.
• Aciona implantações.
• Atualiza a configuração de execução desejada com base nessas alterações.

Você também pode definir políticas que regem como as alterações são implantadas.

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

Transfira um ficheiro do Visio desta 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. As alterações são então enviadas por push para um servidor Git.

2. O Flux é executado em um pod ao lado da carga de trabalho. O Flux tem acesso somente leitura ao repositório Git para garantir que o Flux esteja aplicando alterações apenas conforme solicitado pelos desenvolvedores.

3. O Flux reconhece 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 através 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 pull antes que a alteração seja aplicada à produção.

Embora você possa configurar o GitOps e o Flux manualmente, recomendamos a extensão de cluster GitOps com Flux v2 para AKS.

Estratégias de carga de trabalho e implantação de 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 simula a mudança e pode 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. Ele ajuda a garantir que você possa enviar atualizações para o ambiente de produção de forma 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 de ações do GitHub ou operadores do Flux.

Técnicas avançadas de implantação, como implantação azul-verde, testes A/B e lançamentos canários, exigem processos extras e ferramentas potencialmente extras. O Flagger é uma solução de código aberto popular para ajudar a resolver cenários avançados de implantação.

Gestão de custos

Comece revisando a lista de verificação do projeto de otimização de custos e a lista de recomendações descritas no Well-Architected Framework for AKS. Use a calculadora de preços do Azure para estimar os custos dos serviços que você usa na arquitetura. Para obter outras práticas recomendadas, consulte Otimização de custos.

Considere o uso da análise de custos AKS para alocação granular de custos de infraestrutura de cluster 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.

Aprovisionar o

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

• Não tem 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 normalmente são 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á economias para clusters projetados para cargas de trabalho de desenvolvimento/teste ou experimentais em que a disponibilidade não precisa ser garantida. Por exemplo, o SLO é suficiente. Além disso, se sua carga de trabalho oferecer suporte a isso, considere o uso de pools de nós spot dedicados que executam VMs spot.

  Para cargas de trabalho não produtivas 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 AKS, avalie se você está qualificado para usar assinaturas de Desenvolvimento/Teste do Azure para receber descontos de serviço.

• Provisione um cluster com o número mínimo de nós e permita que o autoscaler do cluster monitore e tome decisões de dimensionamento em vez de começar com um cluster superdimensionado para atender às necessidades de dimensionamento.

• Defina solicitações de pod e limites para permitir que o Kubernetes aloque recursos de nó com maior densidade para que você use hardware para capacidade.

• Considere que, quando você habilita o diagnóstico no cluster, ele 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 precisar existir por um longo período de tempo. Para obter mais informações, consulte Economize custos com instâncias de máquina virtual reservadas do Azure.

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

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

• Crie orçamentos para se manter dentro das restrições de custo que sua organização identifica. Você pode criar orçamentos por meio do Microsoft Cost Management. Você também pode criar alertas para receber notificações quando determinados limites forem excedidos. Para obter mais informações, consulte Criar um orçamento usando um modelo.

Monitor

Você pode monitorar todo o cluster e o custo de computação, armazenamento, largura de banda, logs e firewall. O Azure fornece 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. Você pode então tomar medidas antes do final do mês, quando os custos já estão calculados. Além disso, monitore as tendências mensais ao longo do tempo para se manter no orçamento.

Para tomar decisões baseadas em dados, identifique qual recurso, em um nível granular, incorre em mais custo. Além disso, tenha uma boa compreensão dos medidores que calculam o uso de recursos. Por exemplo, analisando métricas, você pode determinar se a plataforma está superdimensionada. Você pode ver os medidores de uso nas métricas do Azure Monitor.

Otimização

Agir de acordo com as recomendações fornecidas pelo Azure Advisor. Existem outras maneiras de otimizar:

• Habilite o autoscaler do cluster para detetar e remover nós subutilizados no pool de nós.

  Importante

  Alterar agressivamente as configurações do autoscaler de cluster, como as configurações de nós mínimos e máximos para um pool de nós, para afetar os custos pode ter resultados contraproducentes. Por exemplo, se scale-down-unneeded-time estiver 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 será reduzido. Isso ocorre porque o cálculo do tempo desnecessário para cada nó é redefinido devido à atualização das configurações do autoscaler do cluster.

• Escolha uma SKU mais baixa para os pools de nós, se sua carga de trabalho oferecer suporte a ela.

• Se o aplicativo não exigir o burst scaling, considere dimensionar o cluster para o tamanho certo, analisando as métricas de desempenho ao longo do tempo.

• Se sua carga de trabalho oferecer suporte a isso, dimensione seus pools de nós de usuário para 0 nós quando não houver expectativa de que eles estejam em execução. Além disso, se não houver cargas de trabalho agendadas para execução em seu cluster, considere usar o recurso start/stop do AKS para desligar toda a computação, o que inclui o pool de nós do sistema e o plano de controle AKS.

Para obter outras informações relacionadas a custos, consulte Preços do AKS.

Próximos passos

• Arquitetura avançada de microsserviços AKS
• Linha de base AKS para clusters multirregionais
• Cluster regulado pelo 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 Framework bem arquitetado para AKS
• Acelerador da zona de aterragem AKS
• Guia de operações do AKS dia-2
• Arquitetura de microsserviços no AKS
• Usar o Firewall do Azure para ajudar a proteger um cluster AKS
• Operações Git para AKS
• Streaming de dados com AKS