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

Gateway de Aplicativo do Azure
Registro de Contêiner do Azure
Firewall do Azure
AKS (Serviço de Kubernetes do Azure)
Controle de acesso baseado em função do Azure

Essa arquitetura de referência fornece uma arquitetura de infraestrutura de linha de base recomendada para implantar um cluster do Serviço de Kubernetes do Azure (AKS) no Azure. Ele usa nossos princípios de design e se baseia em nossas práticas recomendadas de arquitetura da Estrutura de Bem-Arquitetura do Azure para orientar uma equipe interdisciplinar ou várias equipes distintas, como rede, segurança e identidade, por meio da implantação dessa infraestrutura de propósito geral.

Essa arquitetura não é focada em uma carga de trabalho, mas sim no próprio cluster AKS. As informações aqui são a linha de base mínima recomendada para a maioria dos clusters AKS. Ele se integra aos serviços do Azure que oferecem observabilidade, uma topologia de rede que oferece suporte ao crescimento multirregional e protege o tráfego no cluster.

A arquitetura de destino é influenciada pelos requisitos de negócios e, como resultado, pode variar entre diferentes contextos de aplicativos. Ele deve ser considerado como seu ponto de partida para as etapas de pré-produção e produção.

Uma implementação dessa arquitetura também está disponível no GitHub: Implementação de Referência de Linha de Base do Serviço de Kubernetes do Azure (AKS). Você pode usá-lo como um ponto de partida alternativo e configurá-lo com base em suas necessidades.

Observação

Essa arquitetura de referência requer conhecimento sobre o Kubernetes e seus conceitos. Se você precisar de uma atualização, consulte a seção Saiba mais sobre o AKS para obter recursos.

Topologia de rede

Essa arquitetura usa uma topologia de rede hub-spoke. O hub e os spokes são implantados em redes virtuais separadas conectadas por meio de emparelhamento. Algumas vantagens dessa topologia são:

  • Gerenciamento segregado, Permite uma maneira de aplicar a governança e aderir ao princípio do menor privilégio. Também dá suporte ao conceito de uma Zona de destino do Azure com separação de tarefas.

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

  • As organizações geralmente operam com topologias hub-spoke regionais. Topologias de rede hub-spoke podem ser expandidas no futuro e fornecer isolamento de carga de trabalho.

  • Todos os aplicativos Web devem exigir um serviço de firewall de aplicativo Web (WAF) para ajudar a controlar o fluxo de tráfego HTTP.

  • Uma opção natural para cargas de trabalho que abrangem várias assinaturas.

  • Isso torna a arquitetura extensível. Para acomodar novos recursos ou cargas de trabalho, novos spokes podem ser adicionados em vez de reprojetar a topologia de rede.

  • Determinados recursos, como um firewall e o DNS, podem ser compartilhados entre redes.

  • Alinha-se com as zonas de aterrissagem em escala empresarial do Azure.

Architecture diagram that shows a hub-spoke network topology.

Baixe um Arquivo Visio dessa arquitetura.

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

Para revisar as alterações de design de rede incluídas nos contêineres do Windows na arquitetura de referência de linha de base AKS, consulte o artigo complementar.

Hub

A rede virtual do hub é o ponto central de conectividade e observabilidade. Um hub sempre contém um Firewall do Azure com políticas de firewall globais definidas por suas equipes centrais de TI para impor a política de firewall em toda a organização, o Bastião do Azure, uma sub-rede de gateway para conectividade VPN e o Monitor do Azure para observabilidade de rede.

Na rede, três sub-redes são implantadas.

Sub-rede para hospedar o Firewall do Azure

O Firewall do Azure é um firewall como serviço. A instância de firewall protege o tráfego de rede de saída. Sem essa camada de segurança, esse tráfego pode se comunicar com um serviço mal-intencionado de terceiros que pode exfiltrar dados confidenciais da empresa. O Azure Firewall Manager permite que você implante e configure centralmente várias instâncias do Firewall do Azure e gerencie políticas do Firewall do Azure para esse tipo de arquitetura de rede de rede virtual de hub.

Sub-rede para hospedar um gateway

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

Sub-rede para hospedar o Azure Bastion

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

Spoke

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

Sub-rede para hospedar Gateway de Aplicativo do Azure

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

Sub-rede para hospedar os recursos de entrada

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

Sub-rede para hospedar os nós de cluster

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

As conexões de Link Privado do Azure são criadas para o Registro de Contêiner do Azure e o Cofre de Chaves do Azure, portanto, esses serviços podem ser acessados usando o ponto de extremidade privado na rede virtual spoke. Os pontos de extremidade privados não exigem uma sub-rede dedicada e também podem ser colocados na rede virtual do hub. Na implementação da linha de base, eles são implantados em uma sub-rede dedicada na rede virtual spoke. Essa abordagem reduz o tráfego que passa pela conexão de rede emparelhada, mantém os recursos que pertencem ao cluster na mesma rede virtual e permite 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.

Planejar os endereços IP

Diagram showing network topology of the AKS cluster.

Baixe um Arquivo Visio dessa arquitetura.

O espaço de endereço da rede virtual precisa ser grande o suficiente para conter todas as sub-redes, além de responder por todas as entidades que recebem tráfego. Portanto, os endereços IP dessas entidades são alocados no espaço de endereço da sub-rede. Considere estes pontos.

  • Atualizar

    O AKS atualiza nós com regularidade para garantir que as máquinas virtuais de base tenham os recursos de segurança e os patches do sistema mais recentes. Durante o processo de atualização, o AKS cria um nó que hospeda temporariamente os pods; ao passo que o nó de atualização é isolado e esvaziado. Esse nó temporário recebe um endereço IP da sub-rede do cluster.

    No caso dos pods, talvez sejam necessários mais endereços de acordo com a estratégia. Já para as atualizações sem interrupção, você precisará de endereços para os pods temporários que executam a carga de trabalho enquanto os pods reais são atualizados. Se você usar a estratégia de substituição, os pods serão removidos e novos serão criados. Portanto, os endereços associados aos pods antigos são reutilizados.

  • Escalabilidade

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

    Nessa arquitetura, cada pod pode ser contatado diretamente. Portanto, cada pod precisa de um endereço individual. Vale lembrar que a escalabilidade do pod afetará o cálculo do endereço e essa decisão dependerá de sua escolha em relação ao número de pods que você quer expandir.

  • Endereços do Link Privado do Azure

    Considere os endereços necessários para a comunicação com outros serviços do Azure pelo Link Privado. Nessa arquitetura, há dois endereços atribuídos aos links para o Registro de Contêiner do Azure e o Key Vault.

  • Alguns endereços IP são reservados para uso do Azure e não podem ser atribuídos.

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

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

Para ver a lista completa de considerações sobre essa arquitetura, confira, Topologia de rede de linha de base do AKS.

Para saber mais sobre o planejamento de IP de um cluster do AKS, confira Planejar o endereçamento IP para o cluster.

Para revisar 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 o artigo complementar.

Complementos e recursos de visualização

Kubernetes e AKS são produtos em constante evolução, 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 AKS selecionados e complementos AKS. A diferença entre os dois é a seguinte:

  • A equipe do AKS descreve os recursos de visualização como enviados e aprimorados. A razão por trás disso é que muitos dos recursos de visualização permanecem nesse estado por apenas alguns meses antes de passar para a fase de lançamento geral (GA).
  • Os complementos e extensões do AKS fornecem funcionalidades adicionais com suporte. Sua instalação, configuração e ciclo de vida são gerenciados pelo AKS.

Essa arquitetura de linha de base não inclui todos os recursos ou complementos de visualização, em vez disso, apenas aqueles que agregam valor significativo a um cluster de uso geral são incluídos. À medida que esses recursos saírem da visualização, essa arquitetura de linha de base será revisada de acordo. Há alguns recursos de visualização adicionais ou complementos AKS que você pode querer avaliar em clusters de pré-produção que aumentam sua segurança, capacidade de gerenciamento ou outros requisitos. Com complementos de terceiros, você precisa 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 diversas outras imagens, como o controlador de entrada. Algumas dessas imagens podem residir em registros públicos. Considere estes pontos ao efetuar pull dessas imagens para o cluster.

  • O cluster é autenticado para efetuar pull da imagem.

  • Se você estiver usando uma imagem pública, considere importá-la para o registro de contêiner que se alinhe ao SLO. Caso contrário, a imagem pode ficar sujeita a problemas inesperados de disponibilidade, que poderão atrapalhar a operação se a imagem não estiver disponível quando você precisar. Veja alguns benefícios de usar o registro de contêiner em vez de um registro público:

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

    Uma opção é o ACR (Registro de Contêiner do Azure).

  • Extraia imagens de registros autorizados. Você pode impor essa restrição por meio de Azure Policy. Nesta implementação de referência, o cluster só extrai imagens do ACR implantadas como parte da arquitetura.

Configurar a computação para o cluster base

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

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

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

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

  • Os tamanhos reais do nó para a carga de trabalho dependerão dos requisitos determinados pela equipe de design. Com base nos requisitos de negócios, escolhemos DS4_v2 para a carga de trabalho de produção. Para reduzir os custos, é possível reduzir o tamanho para DS3_v2, que é a recomendação mínima.

  • Ao planejar a capacidade do cluster, suponha que a carga de trabalho possa consumir até 80% de cada nó; os 20% restantes são reservados para serviços do AKS.

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

Integrar o Microsoft Entra ID para o cluster

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

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

Acesso do AKS ao Azure

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

Das duas maneiras, as identidades gerenciadas são recomendadas. Com as entidades de serviço, você é responsável por gerenciar e alternar segredos manual ou programaticamente. Com identidades gerenciadas, o Microsoft Entra ID gerencia e executa a autenticação e a rotação oportuna de segredos para você.

É recomendável que as identidades gerenciadas sejam habilitadas para que o cluster possa interagir com recursos externos do Azure por meio da ID do Microsoft Entra. É possível habilitar essa configuração somente durante a criação do cluster. Mesmo que o Microsoft Entra ID não seja usado imediatamente, você pode incorporá-lo mais tarde.

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

Como exemplo para o caso de acesso interno, vamos estudar o uso de identidades gerenciadas quando o cluster precisa extrair imagens de um registro de contêiner. Essa ação exige que o cluster obtenha as credenciais do registro. Uma jeito de fazer isso é armazenar essas informações na forma do objeto Segredos do Kubernetes e usar imagePullSecrets para recuperar o segredo. Essa abordagem não é recomendada devido a complexidades de segurança. Não só você precisa de conhecimento prévio do segredo, mas também da divulgação desse segredo por meio do pipeline de DevOps. Outro motivo é a sobrecarga operacional do gerenciamento da rotação do segredo. Em vez disso, conceda acrPull acesso à identidade gerenciada kubelet do cluster ao seu registro. Essa abordagem resolve essas preocupações.

Nessa arquitetura, o cluster acessa recursos do Azure protegidos pela ID do Microsoft Entra e executa operações que oferecem suporte a identidades gerenciadas. Atribua o RBAC (controle de acesso baseado em função) do Azure e permissões às identidades gerenciadas do cluster, dependendo das operações que o cluster pretende realizar. O cluster se autentica na ID do Microsoft Entra e, em seguida, tem acesso permitido ou negado com base nas funções que lhe foram atribuídas. Aqui estão alguns exemplos dessa implementação de referência em que as funções internas do Azure foram atribuídas ao cluster:

  • Colaborador de rede. A capacidade do cluster de controlar a rede virtual spoke. Essa atribuição de função permite que a identidade atribuída ao sistema de cluster do AKS funcione com a sub-rede dedicada para os serviços do Controlador de Entrada Interno.
  • Publicador de Métricas de Monitoramento. A capacidade do cluster de enviar métricas para o Azure Monitor.
  • AcrPull. A capacidade do cluster de extrair imagens dos Registros de Contêiner do Azure especificados.

Acesso ao cluster

A integração do Microsoft Entra também simplifica a segurança para o acesso vindo de fora. Imagine que um usuário quer usar kubectl. Como etapa inicial, eles executam o az aks get-credentials comando para obter as credenciais do cluster. A ID do Microsoft Entra autenticará a identidade do usuário em relação às funções do Azure que têm permissão para obter credenciais de cluster. Para saber mais, confira Permissões de funções de cluster disponíveis.

O AKS permite o acesso ao Kubernetes usando o Microsoft Entra ID de duas maneiras. A primeira é o uso do Microsoft Entra ID como um provedor de identidade integrado ao sistema RBAC do Kubernetes nativo. O outro é usar o RBAC nativo do Azure para controlar o acesso ao cluster. Ambos são detalhados abaixo.

Associar o Kubernetes RBAC ao Microsoft Entra ID

O Kubernetes é compatível com RBAC (controle de acesso baseado em função) por meio de:

  • Um conjunto de permissões. Definido por um objeto Role ou ClusterRole para permissões em todo o cluster.

  • Associações que atribuem usuários e grupos que têm permissão para executar as ações. Definidas por um objeto RoleBinding ou CluserRoleBinding.

O Kubernetes tem algumas funções internas, como administrador de cluster, edição, exibição e assim por diante. 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 que os grupos do Microsoft Entra usados para acesso a cluster e namespace estejam incluídos nas revisões de acesso do Microsoft Entra.

Usar o Azure RBAC para autorização do Kubernetes

Em vez de usar o RBAC nativo do Kubernetes (ClusterRoleBindings e RoleBindings) para autorização com autenticação integrada do Microsoft Entra, outra opção que recomendamos é usar o RBAC do Azure e as atribuições de função do Azure para impor verificações de autorização no cluster. Essas atribuições de função podem até mesmo ser adicionadas nos escopos de assinatura ou grupo de recursos para que todos os clusters no escopo herdem um conjunto consistente de atribuições de função referentes a quem tem permissões para acessar os objetos no cluster do Kubernetes.

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

Contas locais

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

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

Integrar o Microsoft Entra ID para a carga de trabalho

Semelhante a ter uma identidade gerenciada atribuída pelo 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 precisar acessar esses arquivos, o pod se autenticará no recurso como uma identidade gerenciada do Azure.

Nesta implementação de referência, as identidades gerenciadas para pods são fornecidas por meio do Microsoft Entra Workload ID no AKS. Isso se integra aos recursos nativos do Kubernetes para federar com provedores de identidade externos. Para obter mais informações sobre a federação de ID de carga de trabalho do Microsoft Entra, consulte a visão geral a seguir.

Implantar recursos de entrada

Os recursos de entrada do Kubernetes roteiam e distribuem o tráfego de entrada para o cluster. Há duas partes dos recursos de entrada:

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

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

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

O controlador de entrada é um componente crítico do cluster. Considere esses pontos ao configurar esse componente.

  • Como parte de suas decisões de design, escolha um escopo dentro do qual o controlador de entrada terá permissão para operar. 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 garantir a continuidade dos negócios se um nó estiver inativo. Use podAntiAffinity para essa finalidade.

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

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

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

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

Observação

A escolha do controlador de entrada apropriado é orientada pelos requisitos da carga de trabalho, do conjunto de habilidades do operador e da compatibilidade das opções de tecnologia. E mais importante, a capacidade de atender às suas expectativas de SLO.

Traefik é uma opção de código aberto popular para um cluster Kubernetes e é escolhido nesta arquitetura para fins ilustrativos . Ele mostra a integração de produtos de terceiros com os serviços do Azure. Por exemplo, a implementação mostra como integrar o Traefik com o Microsoft Entra Workload ID e o Azure Key Vault.

Outra opção é o Controlador de Entrada do Gateway de Aplicativo do Azure e está bem integrado ao AKS. Além de suas funcionalidades como um controlador de entrada, há outros benefícios. Por exemplo, o Gateway de Aplicativo atua como o ponto de entrada de rede virtual do cluster. e pode observar o tráfego entrando no cluster. Se você tem um aplicativo que exige WAF, o Gateway de Aplicativo é uma boa opção, porque está integrado ao WAF. Além disso, oferece a oportunidade de realizar a terminação TLS.

Para revisar o design de entrada usado nos contêineres do Windows na arquitetura de referência de linha de base AKS, consulte o artigo complementar.

Configurações do roteador

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

Aqui está um exemplo dessa arquitetura:

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

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

Proteger o fluxo de rede

O fluxo de rede, nesse contexto, pode ser categorizado como:

  • Tráfego de entrada. Do cliente à carga de trabalho em execução no cluster.

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

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

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

Diagram showing cluster traffic flow.

Baixe um Arquivo Visio dessa arquitetura.

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

Fluxo de tráfego de entrada

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

Diagram showing TLS termination.

Baixe um Arquivo Visio dessa arquitetura.

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

  2. O Gateway de Aplicativo tem um WAF (firewall do aplicativo Web) integrado e negocia o handshake TLS para bicycle.contoso.com, permitindo apenas criptografias seguras. O Gateway de Aplicativo é um ponto de terminação TLS, porque é necessário para processar regras de inspeção de WAF e executar regras de roteamento que encaminham o tráfego para o back-end configurado. O certificado TLS é armazenado no Azure Key Vault e acessado usando uma identidade gerenciada atribuída pelo usuário integrada ao Gateway de Aplicativo. Para saber mais sobre esse recurso, confira Terminação TLS com certificados do Key Vault.

  3. À medida que o tráfego passa do Gateway de Aplicativo para o back-end, ele é criptografado novamente com outro certificado TLS (curinga para *.aks-ingress.contoso.com), pois é encaminhado para o balanceador de carga interno. Essa nova criptografia garante 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 por meio do balanceador de carga. O controlador é outro ponto de terminação TLS para *.aks-ingress.contoso.com e encaminha o tráfego para os pods de carga de trabalho por HTTP. Os certificados são armazenados no Azure Key Vault e montados no cluster com o driver CSI (Interface de Armazenamento de Contêiner). Para saber mais, confira Adicionar gerenciamento de segredos.

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

Fluxo de tráfego de saída

Nessa arquitetura, recomendamos todo o tráfego de saída do cluster que se comunica por meio do Firewall do Azure ou de seu próprio dispositivo virtual de rede semelhante, em vez de outras opções, como Gateway NAT ou proxy HTTP. Para o controle de Confiança Zero e a capacidade de inspecionar o tráfego, todo o tráfego de saída do cluster passa pelo Firewall do Azure. É possível implementar essa escolha usando UDRs (rotas definidas pelo usuário). O próximo salto da rota é o endereço IP privado do Firewall do Azure. Aqui, Firewall do Azure decide se vai bloquear ou permitir o tráfego de saída. Essa decisão se baseia nas regras específicas definidas no Firewall do Azure ou nas regras internas de inteligência contra ameaças.

Uma alternativa ao uso do Firewall do Azure é utilizar o recurso Proxy HTTP do AKS. Todo o tráfego que sai do cluster é definido primeiro para o endereço IP do Proxy HTTP, que decide encaminhar o tráfego ou descartá-lo.

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

Observação

Se você usar um balanceador de carga público como ponto público para o tráfego de entrada e saída por meio do Firewall do Azure usando UDRs, poderá ver uma situação de roteamento assimétrico. Essa arquitetura usa balanceadores de carga internos em uma sub-rede de entrada dedicada por trás do Gateway de Aplicativo. Essa opção de design não apenas aumenta a segurança, mas também elimina preocupações de roteamento assimétrico. Como alternativa, você pode rotear o tráfego de entrada pelo Firewall do Azure antes ou depois do Gateway de Aplicativo, no entanto, essa abordagem não é necessária ou recomendada para a maioria das situações. Para saber mais sobre o roteamento assimétrico, confira Integrar o Firewall do Azure com o Azure Standard Load Balancer.

Uma exceção ao controle de Confiança Zero é quando o cluster precisa se comunicar com outros recursos do Azure. Por exemplo, o cluster precisa extrair uma imagem atualizada do registro de contêiner ou segredos do Cofre de Chaves do Azure. A abordagem recomendada é usar o Link Privado do Azure. A vantagem é que sub-redes específicas chegam diretamente ao serviço, em vez do tráfego entre o cluster e os serviços que passam pela internet. Uma desvantagem é que o Link Privado precisa de configuração adicional em vez de usar o serviço de destino em seu ponto de extremidade público. Além disso, nem todos os serviços ou SKUs do Azure são compatíveis com o Link Privado. 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 passará pelos endereços IP estáticos do firewall, esses endereços podem ser adicionados à lista de permissões de IP do serviço. Uma desvantagem é que o Firewall do Azure precisa ter regras adicionais para garantir que apenas o tráfego de uma sub-rede específica seja permitido. Considere esses endereços quando estiver planejando vários endereços IP para o tráfego de saída com o Firewall do Azure, caso contrário, você poderá chegar ao esgotamento da porta. Para obter mais informações sobre o planejamento de vários endereços IP, consulte Restringir e controlar o tráfego de saída.

Para revisar as considerações de saída específicas do Windows usadas nos contêineres do Windows na arquitetura de referência de linha de base do AKS, consulte o artigo complementar.

Tráfego de pod para pod

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

Habilite a política de rede quando o cluster for provisionado, porque ele não poderá ser adicionado posteriormente. Há algumas opções para tecnologias que implementam NetworkPolicy. É recomendável usar a Política de Rede do Azure, que requer a CNI (Interface de Rede de Contêiner) do Azure, confira a nota abaixo. Outras opções incluem a Política de Rede Calico, uma opção de código aberto conhecida. Considere o Calico se precisar gerenciar políticas de rede em todo o cluster. O Calico não é coberto pelo Suporte do Azure padrão.

Para obter mais informações, consulte Diferenças entre a Política de Rede do Azure e as políticas do Calico e seus recursos.

Observação

O AKS dá suporte a esses modelos de rede: kubenet, CNI (Azure Container Networking Interface) e Azure CNI Overlay. Os modelos CNI são os modelos mais avançados e um modelo baseado em CNI é necessário para habilitar a Política de Rede do Azure. No modelo CNI sem sobreposição, cada pod obtém um endereço IP do espaço de endereço da sub-rede. Os recursos na mesma rede (ou recursos emparelhados) podem acessar os pods diretamente por meio do endereço IP. O NAT não é necessário para rotear esse tráfego. Ambos os modelos CNI são de alto desempenho, com desempenho entre pods no mesmo nível das máquinas virtuais em uma rede virtual. O Azure CNI também oferece controle de segurança aprimorado porque permite o uso da Política de Rede do Azure. É recomendável que a Sobreposição CNI do Azure seja usada para implantações com restrição de endereço IP, que aloca apenas endereços IP da(s) sub-rede(s) do pool de nós para os nós e usa uma camada de sobreposição altamente otimizada para IPs de pod. Recomenda-se um modelo de rede baseado em CNI.

Para obter informações sobre os modelos, consulte Escolhendo um modelo de rede CNI para usar e Comparar modelos de rede kubenet e Azure CNI.

Tráfego de gerenciamento

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

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

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

Adicionar o gerenciamento de segredos

Armazene segredos em um repositório de chaves gerenciadas, como o Azure Key Vault. A vantagem é que o repositório gerenciado lida com a rotação de segredos, oferece criptografia forte, fornece um log de auditoria de acesso e mantém os segredos principais fora do pipeline de implantação. Nessa arquitetura, o firewall do Cofre de Chaves do Azure é habilitado e configurado com conexões de link privado para os recursos no Azure que precisam acessar segredos e certificados.

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

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

Acessar segredos de cluster

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

O driver CSI tem muitos provedores compatíveis com vários repositórios gerenciados. Nesta implementação, escolhemos o Cofre de Chaves do Azure com o Driver CSI do Repositório de Segredos usando o complemento para recuperar o certificado TLS do Cofre de Chaves do Azure e carregá-lo no pod que executa o controlador de entrada. Isso é feito durante a criação do pod e o volume armazena chaves públicas e privadas.

Armazenamento da carga de trabalho

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

Para saber mais sobre as opções de armazenamento, confira Opções de armazenamento para aplicativos no AKS (Serviço de Kubernetes do Azure).

Gerenciamento de política

Uma forma eficaz de gerenciar um cluster do AKS é impor governança por meio de políticas. O Kubernetes implementa políticas por meio do Gatekeeper do OPA. Para o AKS, as políticas são fornecidas por meio da Política do Azure. Cada política é aplicada a todos os clusters em seu escopo. A imposição do Azure Policy é, em última análise, feita pelo Gatekeeper do OPA no cluster, e todas as verificações de política são registradas. As alterações de política não são refletidas imediatamente em seu cluster, espere ver alguns atrasos.

Há dois cenários diferentes que a Política do Azure oferece para gerenciar seus clusters AKS:

  • Impedir ou restringir a implantação de clusters AKS em um grupo de recursos ou assinatura avaliando os padrões de suas organizações. Por exemplo, siga uma convenção de nomenclatura, especifique uma tag etc.
  • Proteja seu cluster AKS por meio da Política do Azure para Kubernetes.

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

  • Você quer definir uma coleção de políticas (chamadas de iniciativas) ou escolher políticas individuais? O Azure Policy tem duas iniciativas internas: básicas e restritas. Cada iniciativa é uma coleção de políticas internas aplicáveis a um cluster do AKS. É recomendável selecionar uma iniciativa e escolher políticas adicionais para o cluster e os recursos (ACR, Gateway de Aplicativo, Key Vault e outros) que interagem com o cluster, de acordo com os requisitos da organização.

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

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

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

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

  • As políticas do Azure são atribuídas a escopos específicos. Verifique se as políticas de produção também são validadas em relação ao ambiente de pré-produção. Caso contrário, ao implantar em seu ambiente de produção, você pode se deparar com restrições adicionais inesperadas que não foram contabilizadas na pré-produção.

Nesta implementação de referência, a Política do Azure é habilitada quando o cluster AKS é criado e atribui a iniciativa restritiva no modo de auditoria para obter visibilidade sobre a não conformidade.

A implementação também define políticas adicionais 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 do ACR implantado. Considere criar suas próprias iniciativas personalizadas. Combine as políticas aplicáveis à carga de trabalho em uma única atribuição.

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

Para revisar as considerações da Política do Azure específicas do Windows incluídas nos contêineres do Windows na arquitetura de referência de linha de base do AKS, consulte o artigo complementar.

Escalabilidade do nó e do pod

Com o aumento da demanda, o Kubernetes pode escalar horizontalmente adicionando mais pods a nós existentes, por meio do HPA (dimensionamento automático de pod horizontal). Quando pods adicionais não podem mais ser agendados, o número de nós deve ser aumentado por meio do dimensionamento automático do cluster do AKS. Uma solução de escala completa deve ter maneiras de dimensionar as réplicas de pod e a contagem de nós no cluster.

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

A maneira manual ou programática exige que você monitore e defina alertas sobre utilização da CPU ou métricas personalizadas. Para dimensionamento de pod, o operador de aplicativo pode aumentar ou diminuir o número de réplicas de pod ajustando ReplicaSet por meio das APIs do Kubernetes. Para dimensionamento de cluster, uma abordagem é receber uma notificação quando o agendador do Kubernetes falhar. Outra maneira é inspecionar pods pendentes ao longo do tempo. É possível ajustar a contagem de nós por meio da CLI do Azure ou do portal.

O dimensionamento automático é a abordagem recomendada porque alguns desses mecanismos manuais são criados no dimensionador automático.

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

Dimensionador automático de pod horizontal

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

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

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

Pode haver uma condição de corrida em que (HPA) verifica antes de uma operação de dimensionamento ser concluída. O resultado pode ser um cálculo de taxa incorreta. Para saber mais detalhes, confira Resfriamento de eventos de dimensionamento.

Se a carga de trabalho é controlada por eventos, uma opção de código aberto popular é o KEDA. Considere o KEDA se a carga de trabalho for controlada por uma origem do evento, como fila de mensagens, em vez de ser associada à CPU ou à memória. O KEDA é compatível com diversas origens de evento (ou dimensionadores). Veja a lista de dimensionadores KEDA compatíveis neste link, incluindo o do Azure Monitor, um jeito prático de escalar cargas de trabalho KEDA com base nas métricas do Azure Monitor.

Dimensionador automático de cluster

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

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

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

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

Para revisar as considerações de dimensionamento incluídas nos contêineres do Windows na arquitetura de referência de linha de base do AKS, consulte o artigo complementar.

Decisões de continuidade dos negócios

Para manter a continuidade dos negócios, defina o Contrato de Nível de Serviço para a infraestrutura e seu aplicativo. Para saber mais sobre o cálculo de tempo de atividade mensal, confira SLA para o AKS (Serviço de Kubernetes do Azure).

Nós de cluster

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

Isole o(s) seu(s) aplicativo(s) dos serviços do sistema colocando-o em um pool de nós separado, conhecido como pool de nós do usuário. Assim, os serviços do Kubernetes são executados em nós dedicados e não competem com a carga de trabalho. O uso de tags, rótulos e manchas é recomendado para identificar o pool de nós para agendar sua carga de trabalho e garantir que o pool de nós do sistema esteja contaminado com o CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

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

Disponibilidade do pod

Garanta a disponibilidade de recursos do pod. É altamente recomendado que as implantações especifiquem requisitos de recursos do pod. O agendador pode agendar o pod adequadamente. A confiabilidade será significativamente preterida se os pods não puderem ser agendados.

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

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

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

Observação

Definir as cotas de recursos no nível do cluster pode causar problemas ao implantar cargas de trabalho de terceiros que não têm solicitações e limites adequados.

Defina solicitações de limites de pods. A definição desses limites permite que o Kubernetes aloque com eficiência recursos de CPU e/ou memória para os pods e tenha maior densidade de contêineres em um nó. Os limites também podem aumentar a confiabilidade com custos reduzidos devido ao melhor uso do hardware.

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

Esses limites podem ser especificados nos manifestos de implantação. Para saber mais, confira Definir solicitações e limites de pods.

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

Se o SLA exigir um tempo de atividade mais alto, proteja-se contra interrupções usando zonas de disponibilidade. Use zonas de disponibilidade se a região tiver compatibilidade com esse recurso. Os componentes do plano de controle e os nós nos pools de nós são capazes de se espalhar entre zonas. Se uma zona inteira não estiver disponível, um nó em outra zona dentro da região ainda estará disponível. Cada pool de nós é mapeado para um Conjunto de Dimensionamento de Máquina Virtual separado, que gerencia instâncias de nó e escalabilidade. As operações e a configuração do conjunto de dimensionamento são gerenciadas pelo serviço AKS. Aqui estão algumas considerações ao habilitar várias zonas:

  • Infraestrutura inteira. Escolha uma região compatível com as zonas de disponibilidade. Para saber mais, confira Limitações e disponibilidade da região. Se você quiser comprar um SLA de tempo de atividade, escolha uma região compatível com essa opção. O SLA de tempo de atividade é maior quando você usa zonas de disponibilidade.

  • Cluster. Só é possível definir as zonas de disponibilidade quanto o pool de nós é criado, e não é permitido alterá-las posteriormente. Os tamanhos de nó devem ser aceitos em todas as zonas para que a distribuição esperada seja possível. O Conjunto de Dimensionamento de Máquina Virtual subjacente fornece a mesma configuração de hardware entre zonas.

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

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

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

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

Várias regiões

Habilitar as zonas de disponibilidade não será suficiente se toda a região ficar inativa. Para ter maior disponibilidade, execute vários clusters do AKS em regiões diferentes.

  • Use regiões emparelhadas. Considere usar um pipeline de CI/CD configurado para usar uma região emparelhada a fim de se recuperar de falhas de região. Um benefício do uso de regiões emparelhadas é a confiabilidade durante as atualizações. O Azure garante que apenas uma região do par seja atualizada por vez. Certas ferramentas de DevOps, como o Flux, podem facilitar as implantações em várias regiões.

  • Se um recurso do Azure for compatível com redundância geográfica, informe o local em que o serviço redundante terá sua região secundária. Por exemplo, habilitar a replicação geográfica para o Registro de Contêiner do Azure replicará automaticamente imagens para as regiões do Azure selecionadas e fornecerá acesso contínuo às imagens, mesmo que uma região estivesse enfrentando uma interrupção.

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

Observação

Ampliamos esta arquitetura de referência para incluir várias regiões em uma configuração ativa/ativa e altamente disponível. Para saber mais sobre essa arquitetura de referência, confira Linha de base do AKS para clusters de várias regiões.

GitHub logo Uma implementação da arquitetura multirregião está disponível no GitHub: Serviço de Kubernetes do Azure (AKS) para implantação de várias regiões. Use essa implementação como ponto de partida e configure de acordo com suas necessidades.

Recuperação de desastre

Em caso de falha na região primária, você deve ser capaz de criar rapidamente uma nova instância em outra região. Veja algumas recomendações:

  • Use regiões emparelhadas.

  • É possível replicar com eficiência uma carga de trabalho sem estado. Caso você precise armazenar o estado no cluster (não recomendado), não se esqueça de fazer backup dos dados com frequência na região emparelhada.

  • Integre a estratégia de recuperação, como a replicação para outra região, como parte do pipeline de DevOps para atender aos SLOs (objetivos de nível de serviço).

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

Backup de cluster

Para muitas arquiteturas, o provisionamento de um novo cluster e o retorno ao estado operacional podem ser realizados por meio de [Cluster bootstrapping}(#cluster-bootstrapping) baseado em GitOps e seguido pela implantação do aplicativo. No entanto, se houver um estado crítico de recursos, como mapas de configuração, trabalhos e segredos potencialmente que, por algum motivo, não possam ser capturados em seu processo de inicialização, considere sua estratégia de recuperação. Geralmente, é recomendado executar cargas de trabalho sem monitoração de estado no Kubernetes, mas se sua arquitetura envolver o estado baseado em disco, você também precisará considerar sua estratégia de recuperação para esse conteúdo.

Quando o backup de cluster precisa 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 será responsável por enviar o estado do recurso de cluster para um destino de sua escolha e coordenar instantâneos de volume persistentes baseados em disco do Azure.

O Velero da VMware é um exemplo de uma solução de backup Kubernetes comum que você pode instalar e gerenciar diretamente. Como alternativa, a extensão de backup AKS pode ser usada para fornecer uma implementação Velero gerenciada. A extensão de backup AKS oferece suporte ao 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 backup, o que envolveria recursos extras do Azure na arquitetura para gerenciar, monitorar, pagar e proteger; como uma conta de Armazenamento do Azure, configuração do cofre do Backup do Azure e Acesso Confiável. O GitOps combinado com a intenção de executar carga de trabalho sem monitoração de estado é a solução de recuperação implementada.

Escolha e valide uma solução que atenda ao seu objetivo de negócios, incluindo o RPO (Recovery Point Objective, objetivo de ponto de recuperação) definido e o RTO (Recovery Time Objective, objetivo de tempo de recuperação). Defina esse 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

O AKS pode ser usado como um serviço gratuito, mas essa camada não oferece um SLA com suporte financeiro. Para obter esse SLA, você deve escolher a camada Standard. Recomendamos que todos os clusters de produção usem a camada Standard. Reserve clusters de camada livre para clusters de pré-produção. Quando combinado com as Zonas de Disponibilidade do Azure, o SLA do servidor da API do Kubernetes é aumentado para 99,95%. Seus pools de nós e outros recursos são cobertos pelos próprios SLAs.

Vantagens e desvantagens

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

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

Testar com simulações e failovers forçados

Garanta a confiabilidade por meio de testes de failover forçado com paralisações simuladas, como parar um nó, derrubar todos os recursos do AKS em uma zona específica para simular uma falha zonal ou invocar uma falha de dependência externa. O Azure Chaos Studio também pode ser aproveitado para simular vários tipos de interrupções no Azure e no cluster.

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

Monitorar e coletar métricas

O Azure Monitor Container insights é a ferramenta recomendada para monitorar o desempenho de cargas de trabalho de contêiner, pois você pode exibir eventos em tempo real. Esse recurso também captura logs de contêiner dos pods em execução e os agrega para exibição. Além disso, coleta informações da API de Métricas sobre a utilização de memória e CPU para monitorar a integridade de recursos e cargas de trabalho em execução. Você também pode usá-lo para monitorar o desempenho à medida que os pods são dimensionados. Inclui coleta de telemetria crítica para monitoramento, análise e visualização de dados coletados para identificar tendências e configurar alertas para serem notificados proativamente sobre problemas críticos.

A maioria das cargas de trabalho hospedadas em pods emitem métricas do Prometheus. O Container Insights é capaz de se integrar ao Prometheus para visualizar métricas de aplicativos e cargas de trabalho que ele coleta de nós e Kubernetes.

Existem algumas soluções de terceiros que se integram ao Kubernetes que você pode aproveitar, como Datadog, Gragana ou New Relic, se sua organização já as usar.

Com o AKS, o Azure gerencia alguns serviços principais do Kubernetes e os logs dos componentes do plano de controle do AKS são implementados no Azure como logs de recursos. É recomendável que a maioria dos clusters tenham estes elementos habilitados sempre para ajudar a solucionar problemas de cluster e ter uma densidade de log relativamente baixa:

  • Faça logon no ClusterAutoscaler para ter observabilidade das operações de escala. Para saber mais, confira Recuperar logs e status do dimensionador automático de cluster.
  • KubeControllerManager para ter observabilidade na interação entre o Kubernetes e o plano de controle do Azure.
  • KubeAuditAdmin para ter observabilidade em atividades que modificam seu cluster. Não há motivos para ter KubeAudit e KubeAuditAdmin habilitados, já que KubeAudit é um superconjunto de KubeAuditAdmin que também inclui operações de não modificação (leitura).
  • O Guard captura auditorias do Microsoft Entra ID e do Azure RBAC.

Outras categorias de log, como KubeScheduler ou KubeAudit, podem ser muito úteis para habilitar durante o desenvolvimento inicial do ciclo de vida do cluster ou da carga de trabalho, onde o dimensionamento automático de cluster adicionado, o agendamento de posicionamento de pod e dados semelhantes podem ajudar a solucionar problemas de operações de cluster ou carga de trabalho. Manter os logs de solução de problemas estendidos em tempo integral, quando as necessidades de solução de problemas acabarem, pode ser considerado um custo desnecessário para ingerir e armazenar 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 consulta. Sua biblioteca personalizada de consultas ajuda a habilitar observabilidade adicional na integridade e no desempenho de seus clusters AKS e oferece suporte a seus SLOs (objetivos de nível de serviço).

Para obter mais informações sobre nossas práticas recomendadas de monitoramento para AKS, consulte Monitorando o Serviço de Kubernetes do Azure (AKS) com o Azure Monitor.

Para revisar as considerações de monitoramento específicas do Windows incluídas nos contêineres do Windows na arquitetura de referência de linha de base AKS, consulte o artigo complementar.

Habilitar a autorrecuperação

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

Observação

O AKS fornece a autorrecuperação interna de nós de infraestrutura usando o Reparo Automático de Nó.

Atualizações de segurança

Mantenha a versão do Kubernetes atualizada com as versões N-2 compatíveis. A atualização para a versão mais recente do Kubernetes é essencial porque novas versões são lançadas com frequência.

Para saber mais, confira Atualizar regularmente para a versão mais recente do Kubernetes e Atualizar um cluster do AKS (Serviço de Kubernetes do Azure).

A notificação de eventos gerados pelo cluster, como a nova disponibilidade de versão do AKS para seu cluster, pode ser obtida por meio do Tópico do Sistema AKS para 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 Microsoft.ContainerService.NewKubernetesVersionAvailable evento de sua solução de notificação de fluxo de eventos.

Atualizações semanais

O AKS fornece novas imagens de nó que têm as atualizações mais recentes do sistema operacional e do runtime. Essas novas imagens não são aplicadas automaticamente. Você é responsável por decidir com que frequência as imagens devem ser atualizadas. É recomendável ter um processo para atualizar a imagem base dos pools de nós semanalmente. Para saber mais, confira Atualização de imagem de nó do AKS (Serviço de Kubernetes do Azure) nas Notas sobre a versão do AKS.

Atualizações diárias

Entre atualizações de imagem, os nós do AKS baixam e instalam patches de sistema operacional e runtime individualmente. Uma instalação pode exigir que as VMs do nó sejam reinicializadas. O AKS não reinicializará os nós devido a atualizações pendentes. Tenha um processo que monitore os nós para as atualizações aplicadas que exigem uma reinicialização e execute a reinicialização desses nós de maneira controlada. Uma opção de código aberto é o Kured (daemon de reinicialização do Kubernetes).

Manter suas imagens de nó em sincronia com a versão semanal mais recente minimizará essas solicitações de reinicialização ocasionais, mantendo uma postura de segurança aprimorada. Depender apenas de atualizações de imagem de nó garantirá a compatibilidade do AKS e a aplicação de patch de segurança semanal. Embora a aplicação de atualizações diárias corrija problemas de segurança mais rapidamente, elas não foram necessariamente testadas no AKS. Sempre que possível, use a atualização de imagem de nó como estratégia principal de patch de segurança semanal.

Monitoramento de segurança

Monitore sua infraestrutura de contêiner para ameaças ativas e possíveis riscos à segurança:

Operações de cluster e carga de trabalho (DevOps)

Aqui estão algumas considerações. Para saber mais, confira o pilar Excelência operacional.

Inicialização do cluster

Após a conclusão do provisionamento, você terá um cluster em funcionamento, mas ainda pode haver etapas necessárias antes de implantar cargas de trabalho. O processo de preparação do cluster é chamado de inicialização e pode consistir em ações como a implantação de imagens de pré-requisito em nós de cluster, criação de namespaces e qualquer outra tarefa que atenda aos requisitos do seu caso de uso ou organização.

Para diminuir a lacuna entre um cluster provisionado e um cluster que foi configurado corretamente, os operadores de cluster devem pensar em como será o processo de inicialização exclusivo e preparar ativos relevantes com antecedência. Por exemplo, se ter o Kured em execução em cada nó antes de implantar cargas de trabalho do aplicativo for importante, o operador de cluster desejará garantir que um ACR que contenha a imagem de destino do Kured já exista antes de provisionar o cluster.

O processo de inicialização pode ser configurado usando um dos seguintes métodos:

Observação

Qualquer um desses métodos funcionará com todas as topologias de cluster, mas a extensão de cluster GitOps Flux v2 é recomendada para frotas devido à uniformidade e à governança mais fácil em escala. O GitOps pode parecer muito complexo para a execução de apenas alguns clusters. No entanto, você tem a alternativa de integrar esse processo em um ou mais pipelines de implantação para garantir que a inicialização ocorra. Use o método que melhor se alinha aos objetivos de sua organização e equipe.

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

Por fim, ao usar a extensão, kubectl não é necessário para qualquer parte do processo de inicialização, e o uso do acesso baseado em kubectl pode ser reservado para situações de correção de interrupção/reparo de emergência. Entre modelos para definições de recursos do Azure e a inicialização de manifestos por meio da extensão GitOps, todas as atividades de configuração normais podem ser executadas sem a necessidade de usar kubectl.

Isolar responsabilidades de carga de trabalho

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

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

Outra parte poderia ser integrar a carga de trabalho básica com o Microsoft Entra ID.

Usar IaC (infraestrutura como código)

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

Provisione os recursos de acordo com as políticas de governança. Por exemplo, ao selecionar os tamanhos corretos da VM, fique dentro das restrições de custo e das opções de zona de disponibilidade para corresponder aos requisitos do aplicativo.

Se for necessário escrever uma sequência de comandos, use a CLI do Azure. Esses comandos abrangem um intervalo de serviços do Azure e podem ser automatizados por meio de scripts. Windows e Linux são compatíveis com a CLI do Azure. Outra opção multiplataforma é o Azure PowerShell. Sua escolha dependerá do conjunto de habilidades preferido.

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

CI/CD da carga de trabalho

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

Sua estratégia de implantação deve incluir um pipeline de CD (entrega contínua) confiável e automatizado. As alterações nas imagens do contêiner de carga de trabalho devem ser implantadas automaticamente no cluster.

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

CI/CD de cluster

Diagram showing workload CI/CD.

Baixe um Arquivo Visio dessa arquitetura.

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

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

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

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

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

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

Diagram that shows the GitOps flow.

Baixe um Arquivo Visio dessa arquitetura.

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

  2. O fluxo é executado no pod junto com a carga de trabalho. O Flux tem acesso somente leitura ao repositório git para garantir que o Flux esteja aplicando alterações somente 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 por meio do kubectl.

  5. Tenha políticas de ramificação em seu servidor Git. Dessa forma, vários desenvolvedores podem aprovar uma alteração por meio de uma solicitação pull antes que ela seja aplicada à produção.

Enquanto o GitOps e o Flux podem ser configurados manualmente, o GitOps com extensão de cluster Flux v2 é recomendado para AKS.

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

Implante qualquer alteração (componentes de arquitetura, carga de trabalho, configuração de cluster) em pelo menos um cluster AKS de pré-produção. Isso simulará que a alteração pode solucionar problemas antes de ser implantada na produção.

Execute testes/validações em cada estágio antes de passar para o próximo para garantir o envio atualizações por push ao ambiente de produção de modo altamente controlado e minimizar a interrupção de problemas de implantação não previstos. Essa implantação deve seguir um padrão semelhante ao da produção, usando o mesmo pipeline do GitHub Actions ou operadores Flux.

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

Gerenciamento de custo

Comece revisando a lista de verificação de 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 para os serviços usados na arquitetura. Outras melhores práticas são descritas na seção Otimização de custos no Microsoft Azure Well-Architected Framework.

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

Para revisar as considerações de gerenciamento de custos específicas para cargas de trabalho baseadas no Windows incluídas nos contêineres do Windows na arquitetura de referência de linha de base AKS, consulte o artigo complementar.

Provisionar o

  • Não há custos associados ao AKS na implantação, gerenciamento e operações do cluster Kubernetes. O que influencia o custo são as instâncias de máquina virtual, 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. O SKU DS2_v2 é um tipo de VM típico para o pool de nós do sistema.

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

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

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

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

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

  • Habilite o diagnóstico no cluster pode aumentar o custo.

  • Se a carga de trabalho for esperada por um longo período, você poderá se comprometer com instâncias de máquina virtual reservadas de um ou três anos para reduzir os custos do nó. Para saber mais, confira VMs reservadas.

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

  • As transferências de dados entre zonas de disponibilidade em uma região não são gratuitas. Se sua carga de trabalho for de várias regiões ou houver transferências entre zonas de disponibilidade, espere um custo adicional de largura de banda. Para saber mais, confira Tráfego em zonas de cobrança e regiões.

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

Monitor

Para monitorar o custo de todo o cluster, junto com o custo de computação, também colete informações de custo sobre armazenamento, largura de banda, firewall e logs. O Azure conta com vários painéis para monitorar e analisar o custo:

Idealmente, monitore o custo em tempo real ou pelo menos uma cadência regular para tomar medidas antes do final do mês, quando os custos já estiverem calculados. Monitore também a tendência mensal ao longo do tempo para não sair do orçamento.

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

Otimizar

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

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

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

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

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

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

Próximas etapas

Continue aprendendo sobre a arquitetura de linha de base do AKS:

Saiba mais sobre o AKS

Consulte os seguintes guias relacionados:

Consulte as seguintes arquiteturas relacionadas: