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

Esta arquitetura de referência contém uma arquitetura de infraestrutura básica recomendada para a implantação de um cluster do Serviço de Kubernetes do Azure (AKS) no Azure. Ela usa nossos princípios de design e tem como base as práticas recomendadas de arquitetura da Azure Well-Architected Framework, que orienta equipes interdisciplinares ou várias equipes distintas, como de rede, segurança e identidade, por meio da implantação dessa infraestrutura de uso geral.

Esta não é uma arquitetura que prioriza uma carga de trabalho, mas sim o próprio cluster AKS. As informações aqui são as recomendações básicas mínimas para a maioria dos clusters AKS. A arquitetura se integra aos serviços do Azure que oferecem observabilidade, uma topologia de rede que acompanha o crescimento entre várias regiões e protege o tráfego no cluster.

A arquitetura de destino tem influência dos requisitos de negócios e, portanto, pode variar entre diferentes contextos de aplicação. Ela deve ser considerada o 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 segura da referência de linha de base do AKS (Serviço de Kubernetes do Azure). Você pode usar essa implementação como ponto de partida alternativo e configurá-la de acordo com suas necessidades.

Configuração de rede

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

Computação do cluster

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

Gerenciamento de identidades

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

Fluxo de dados seguro

Proteger o fluxo de rede
Adicionar o gerenciamento de segredos

Continuidade de negócios

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

Operações

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

Topologia de rede

Essa arquitetura usa uma topologia de rede hub-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 destino em escala empresarial do Azure.

Baixe um Arquivo Visio dessa arquitetura.

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

Para conferir as mudanças de design de rede incluídas nos contêineres do Windows na arquitetura básica de referência do AKS, consulte o artigo complementar.

Hub

A rede virtual do hub é o ponto central de conectividade e observabilidade. Todo hub contém um Firewall do Azure com políticas de firewall globais definidas por suas equipes centrais de TI. Elas servem para aplicar a política de firewall em toda a organização, o Azure Bastion, uma sub-rede de gateway para conectividade com a VPN e o Azure Monitor 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. Com o Gerenciador de Firewall do Azure, você implanta e configura centralmente várias instâncias do firewall do Azure e gerencia políticas dele para este tipo de arquitetura de rede virtual do 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, Traefik é o controlador de entrada que atenderá aos recursos de entrada do Kubernetes. Os balanceadores de carga internos do Azure existem nessa sub-rede. Para obter mais informações, consulte Usar um load balancer interno com 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.

Sub-rede para hospedar pontos de extremidade de Link Privado

As conexões de Link Privado do Azure são criadas para o Registro de Contêiner do Azure e o Azure Key Vault, para que esses serviços possam ser acessados usando um ponto de extremidade privado da 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 diminui 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 a aplicação de regras de segurança granulares no nível da sub-rede por meio de grupos de segurança de rede.

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

Planejar os endereços IP

Baixe um Arquivo Visio dessa arquitetura.

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 conferir as considerações de planejamento de endereço IP incluídas nos contêineres do Windows na arquitetura básica de referência do AKS, consulte o artigo complementar.

Complementos e versões prévias dos recursos

Kubernetes e AKS são produtos que passam por uma constante evolução e têm ciclos de lançamento mais rápidos do que o software para ambientes on-premises. Essa arquitetura básica depende de algumas versões prévias de recursos do AKS e complementos do AKS. A seguir estão as diferenças entre eles:

• A equipe do AKS descreve as versões prévias de recursos como lançados e em melhoria. O motivo por trás disso é que muitas das versões prévias de recursos permanecem assim por apenas alguns meses antes de passarem para a fase de lançamento geral (GA).
• Os complementos e extensões do AKS fornecem outras funcionalidades compatíveis. A instalação, configuração e ciclo de vida deles são gerenciados pelo AKS.

Essa arquitetura básica não inclui todas as versões prévias de recursos ou complementos, mas apenas aquelas que agregam valor significativo a um cluster de uso geral. À medida que esses recursos saem da versão prévia, essa arquitetura básica passa por uma revisão adequada. Existem outras versões prévias de recursos ou complementos do AKS que você talvez queira avaliar em clusters de pré-produção para aumentar a segurança, 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 o upgrade da versão do Kubernetes de um cluster.

Referência de imagem de contêiner

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

• O cluster é autenticado para efetuar pull da imagem.

• Se você estiver usando uma imagem pública, importe-a para o registro de contêiner que esteja alinhado com seu 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 alternância adequada de segredos para você.

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

Por padrão, há duas identidades primárias usadas pelo cluster: a identidade do cluster e a identidade do 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 acesso acrPull à identidade gerenciada do kubelet do cluster ao registro. Essa abordagem resolve essas preocupações.

Nessa arquitetura, o cluster acessa recursos do Azure protegidos pelo Microsoft Entra ID e realiza operações compatíveis com identidades gerenciadas. Atribua o RBAC (controle de acesso baseado em função) do Azure e permissões às identidades gerenciadas do cluster, dependendo das operações que o cluster pretende realizar. O cluster faz sua própria autenticação no Microsoft Entra ID. Depois, ele tem acesso permitido ou negado com base nas funções atribuídas. 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. Para começar, ele usa executa o comando az aks get-credentials para obter as credenciais do cluster. O Microsoft Entra ID autentica a identidade do usuário em relação às funções do Azure que têm permissão para obter credenciais do cluster. Para saber mais, confira Permissões de funções de cluster disponíveis.

O AKS usa duas maneiras para permitir o acesso ao Kubernetes com o Microsoft Entra ID. 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 RBAC do Kubernetes 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 ClusterRoleBinding.

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

Verifique se os grupos do Microsoft Entra usados para acesso ao cluster e ao namespace estão 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 a autenticação integrada do Microsoft Entra, outra opção recomendada é usar atribuições de função do RBAC do Azure e do Azure para aplicar 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 seu cluster para desabilitar explicitamente o acesso à conta local.

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

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

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

Nesta implementação de referência, as identidades gerenciadas para pods são fornecidas pela identidade da carga de trabalho do Microsoft Entra no AKS. Assim é feita a integração com os recursos nativos do Kubernetes para federar com provedores de identidade externos. Para obter mais informações sobre a federação da identidade da 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.

Para conferir o design de entrada usado nos contêineres do Windows na arquitetura básica de referência do 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.

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.

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

Nesta arquitetura, recomendamos usar 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 da 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.

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

Uma exceção ao controle de Confiança Zero é quando o cluster precisa se comunicar com outros recursos do Azure. Por exemplo, o cluster precisa extrair uma imagem atualizada do registro de contêiner ou segredos do Azure Key Vault. A abordagem recomendada é usar o Link Privado do Azure. A vantagem é que sub-redes específicas chegam diretamente ao serviço, no lugar 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. Nesses casos, habilite um ponto de extremidade de serviço de rede virtual na sub-rede para acessar o serviço.

Se o Link Privado ou os pontos de extremidade de serviço não forem uma opção, você poderá acessar outros serviços por meio de seus pontos de extremidade públicos e controlar o acesso por meio de regras do Firewall do Azure e do firewall incorporado ao serviço de destino. Como esse tráfego passará pelos endereços IP estáticos do firewall, esses endereços poderão ser adicionados à lista de IPs permitidos do serviço. Uma desvantagem é que Firewall do Azure precisa de regras adicionais para garantir que apenas o tráfego de uma sub-rede específica seja permitido. Leve em conta 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 como planejar vários endereços IP, consulte Restringir e controlar o tráfego de saída.

Para verificar as considerações de saída específicas do Windows usadas nos contêineres do Windows na arquitetura básica de referência 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 Políticas 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 suas funcionalidades.

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 obter uma camada adicional de controle, com um pouco a mais de complexidade, você pode provisionar um cluster AKS privado. Ao usar um cluster privado, é possível garantir que o tráfego de rede entre o servidor de API e os seus pools de nós permaneça somente na rede privada, sem que seja exposto à Internet. Para obter mais informações, consulte Clusters privados do AKS.

Adicionar o gerenciamento de segredos

Armazene segredos em um repositório de chaves gerenciadas, como 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. Nesta arquitetura, o firewall do Azure Key Vault é 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 Key Vault permite atribuir as identidades de carga de trabalho à função Usuário de segredos do Key Vault ou Leitor do Key Vault e acessar os segredos. Para obter mais informações, consulte Acessar o Azure Key Vault 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 Azure Key Vault com o driver CSI do repositório de segredos usando o complemento para recuperar o certificado TLS do Azure Key Vault 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. No AKS, as políticas são oferecidas por meio de Azure Policy. 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. É normal ocorrerem atrasos.

Há dois cenários que o Azure Policy oferece para gerenciar seus clusters do AKS:

• Impedir ou restringir a implantação de clusters do AKS em um grupo de recursos ou assinatura com a avaliação de padrões das organizações. Por exemplo, siga uma convenção de nomenclatura, especifique uma tag etc.
• Proteja seu cluster do AKS por meio do Azure Policy para Kubernetes.

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

• Você quer definir uma coleção de políticas (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 Auditoria para que você esteja ciente dessas instâncias.

• Você tem requisitos que não são cobertos pelas políticas internas? Você pode criar uma definição personalizada do Azure Policy que aplique suas políticas personalizadas do Gatekeeper do OPA. Não aplique políticas personalizadas diretamente ao cluster. Para saber mais sobre como criar políticas personalizadas, consulte Criar e atribuir definições de políticas 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 no ambiente de produção, você poderá encontrar restrições adicionais inesperadas que não foram previstas na pré-produção.

Nesta implementação de referência, o Azure Policy é habilitado quando o cluster do AKS é criado e atribui a iniciativa restritiva no modo 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 conferir as considerações do Azure Policy específicas do Windows incluídas nos contêineres do Windows na arquitetura básica de referência 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 conferir as considerações de dimensionamento incluídas nos contêineres do Windows na arquitetura de referência básica 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 seus aplicativos dos serviços do sistema colocando-os em um pool de nós separado, conhecido como pool de nós do usuário. Assim, os serviços do Kubernetes são executados em nós dedicados e não competem com a carga de trabalho. O uso de tags, rótulos e taints é recomendado para identificar o pool de nós para programar sua carga de trabalho e garantir que o pool de nós do sistema seja afetado 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.

Defina solicitações de limites de pods. Definir esses limites permite que o Kubernetes aloque com eficiência a CPU e/ou os recursos de memória para os pods e tenha maior densidade de contêiner 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. Use as 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. Determinadas ferramentas de DevOps, como o Flux, podem facilitar as implantações de 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.

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 do cluster

Para muitas arquiteturas, o provisionamento de um novo cluster e seu 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 que, por algum motivo, não possam ser capturados em seu processo de inicialização, use sua estratégia de recuperação. Geralmente, a recomendação é executar cargas de trabalho sem estado no Kubernetes. Mas se sua arquitetura envolver o estado baseado em disco, você também precisará usar sua estratégia de recuperação para esse conteúdo.

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

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

A implementação de referência não implementa backup, pois envolveria recursos extras do Azure na arquitetura para gerenciar, monitorar, pagar e proteger, como uma conta de Armazenamento do Azure, cofre de Backup do Azure e configuração, e Acesso Confiável. O GitOps combinado com a intenção de executar uma carga de trabalho sem 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 da equipe e pratique-o em todas as cargas de trabalho importantes para os negócios.

SLA do servidor de 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, escolha a camada Standard. Recomendamos que todos os clusters de produção usem a camada Standard. Reserve clusters de camada Free 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

Verifique a confiabilidade por meio de testes de failover forçados com interrupções simuladas, como deixar um nó interrompido, indisponibilizar todos os recursos do AKS em uma zona específica para simular uma falha zonal ou chamar uma falha de dependência externa. O Azure Chaos Studio também pode ser usado 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 é possível exibir eventos em tempo real. Esse recurso também captura logs de contêiner dos pods em execução e os agrega para exibição. Além disso, coleta informações da API de Métricas sobre 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á-la para monitorar o desempenho à medida que os pods são dimensionados. Ele inclui a coleta de telemetria crítica para monitoramento, análise e visualização de dados coletados a fim de identificar tendências e configurar alertas de notificação de forma proativa 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 a visualização de métricas de aplicativos e cargas de trabalho que ele coleta de nós e do Kubernetes.

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

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 RBAC do Azure.

Pode ser muito útil habilitar outras categorias de log, como KubeScheduler ou KubeAudit, durante o desenvolvimento inicial do ciclo de vida do cluster ou da carga de trabalho, pois a inclusão de dimensionamento automático de cluster, posicionamento de pod, agendamento e dados semelhantes podem ajudar a solucionar problemas do cluster ou preocupações com as operações de carga de trabalho.& Manter os logs de solução de problemas ampliados em tempo integral após o fim das necessidades de solução de problemas pode ser considerado um custo desnecessário de ingestão e armazenamento no Azure Monitor.

Embora o Azure Monitor inclua um conjunto de consultas de log existentes para começar, você também pode usá-las como base para criar suas próprias consultas. À medida que sua biblioteca aumenta, você pode salvar e reutilizar consultas de log usando um ou mais pacotes de consultas. Sua biblioteca personalizada de consultas ajuda a habilitar a observabilidade adicional na integridade e no desempenho de seus clusters do 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 Monitorar o Serviço de Kubernetes do Azure (AKS) com o Azure Monitor.

Para conferir as considerações de monitoramento específicas do Windows incluídas nos contêineres do Windows na arquitetura básica de referência do 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.

Atualizações de cluster do AKS

Definir uma estratégia de atualização consistente com os requisitos da empresa é fundamental. Compreender o nível de previsibilidade para a data e a hora em que a versão do cluster do AKS ou seus nós são atualizados, e o nível desejado de controle sobre qual imagem específica ou binários são instalados são aspectos fundamentais que vão moldar seu plano de atualização de cluster do AKS. A previsibilidade está ligada a duas propriedades principais de atualização de cluster do AKS, que são a cadência de atualização e a janela de manutenção. O controle é se as atualizações são instaladas manual ou automaticamente. As organizações com clusters do AKS que não estão sob uma regulamentação de segurança estrita podem considerar atualizações semanais ou mesmo mensais, enquanto as outras devem atualizar os patches rotulados de segurança assim que disponíveis (diariamente). As organizações que operam clusters do AKS como infraestrutura imutável não estão fazendo a atualização. Ou seja, nem atualizações automáticas nem manuais são realizadas. Em vez disso, quando uma atualização desejada é disponibilizada, um carimbo de réplica é implantado. Somente quando a nova instância de infraestrutura está pronta, a antiga é drenada, conferindo a ela o mais alto nível de controle.

Uma vez que o plano de atualização do cluster do AKS é determinado, ele pode ser facilmente mapeado para as opções de atualização disponíveis para nós AKS e versão do cluster AKS:

• Nós AKS:

  1. Atualizações manuais/sem atualizações: é para infraestrutura imutável ou quando as atualizações manuais são a preferência. Atinge o maior nível de previsibilidade e controle sobre as atualizações dos nós AKS.
  2. Atualizações autônomas automáticas: o AKS faz atualizações nativas do sistema operacional. Isso dá previsibilidade, configurando janelas de manutenção alinhadas com o que é melhor para a empresa. Pode ser baseado nos horários de pico e no que é melhor em termos de operações. O nível de controle é baixo, pois não é possível saber com antecedência o que será instalado especificamente dentro do nó AKS.
  3. Atualizações automáticas de imagem do nó: recomenda-se atualizar automaticamente as imagens do nó AKS quando novos VHDs (discos rígidos virtuais) são disponibilizados. Projete janelas de manutenção em alinhamento máximo com as necessidades da empresa. Para atualizações VHD com rótulo de segurança, recomenda-se configurar uma janela de manutenção diária que garanta a menor previsibilidade. As atualizações regulares do VHD podem ser configuradas com uma janela de manutenção semanal, a cada duas semanas ou até mensalmente. Dependendo da necessidade, de VHDs rotulados de segurança ou regulares combinados com a janela de manutenção programada, a previsibilidade oscila oferecendo mais ou menos flexibilidade para estar alinhada com os requisitos da empresa. Embora deixar isso sempre para os requisitos da empresa seja o ideal, a realidade exige que as organizações encontrem o ponto de inflexão. O nível de controle é baixo, já que não é possível saber com antecedência quais binários específicos foram incluídos em um novo VHD. Ainda assim, esse tipo de atualização automática é a opção recomendada, já que as imagens são verificadas antes de ficarem disponíveis.

  Observação

  Para obter mais informações sobre como configurar atualizações automáticas de nós AKS, confira Imagens do sistema operacional de nó de atualização automática.

• Versão do cluster AKS:

  1. Atualizações manuais/sem atualizações: é para infraestrutura imutável ou quando as atualizações manuais são a preferência. Alcança o maior nível de previsibilidade e controle sobre as atualizações de versão do cluster AKS. Recomenda-se essa opção por garantir o controle total, dando a chance de testar uma nova versão de cluster AKS (ou seja, 1.14.x a 1.15.x) em ambientes inferiores antes de entrar em produção.
  2. Atualizações automáticas: não é recomendado que um cluster de produção seja automaticamente corrigido ou atualizado de qualquer forma (ou seja, 1.16.x a 1.16.y) para a nova versão do cluster AKS disponível sem ser devidamente testado em ambientes inferiores. Embora as versões upstream do Kubernetes e as atualizações de versão do cluster AKS sejam coordenadas para oferecer uma cadência regular, a recomendação ainda é agira na defensiva com clusters AKS em produção, aumentando a previsibilidade e o controle sobre o processo de atualização. Em relação a considerar essa configuração para ambientes inferiores como parte da Excelência Operacional, permite execuções proativas de testes de rotina para detectar possíveis problemas o quanto antes.

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 da Grade de Eventos para que você possa assinar o evento Microsoft.ContainerService.NewKubernetesVersionAvailable da solução de notificação do 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:

• Habilite o Microsoft Defender para contêineres para identificar e corrigir as recomendações do Defender para Nuvem nas imagens de contêiner.
• O Microsoft Defender para contêineres regularmente verifica suas imagens de contêiner em busca de vulnerabilidades.
• O Microsoft Defender para contêineres também gera alertas de segurança em tempo real para atividades suspeitas.
• Para saber mais sobre a proteção de segurança aplicada aos hosts de máquina virtual do AKS, confira Proteção de segurança no sistema operacional host.

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

Depois que o provisionamento for concluído, 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:

• Configuração automática com o Flux ou Argo CD
• Pipelines
• Extensão do cluster GitOps Flux v2

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 aceita a inclusão desse bootstrapping como modelos de recursos para alinhar com sua estratégia de 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 pode ser integrar a carga de trabalho básica ao 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 são os modelos do Azure Resource Manager (ARM). Outra é 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

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:

Baixe um Arquivo Visio dessa arquitetura.

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

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

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

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

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

Enquanto o GitOps e o Flux podem ser configurados manualmente, a extensão de cluster do GitOps com Flux v2 é recomendada 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 custos

Para começar, consulte 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.

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

Para ver 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 básica de referência do AKS, consulte o artigo complementar.

Provisionar o

• Não há custos associados à implantação, ao gerenciamento e às operações do AKS do cluster do 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 que o cluster consome. 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 para alta disponibilidade e serão geralmente 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 as zonas de disponibilidade de uma região não são gratuitas. Se a carga de trabalho for de várias regiões ou houver transferências entre zonas de disponibilidade, haverá 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.

Monitorar

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:

• Assistente do Azure

• Gerenciamento de Custos do Azure

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

Saiba mais sobre a arquitetura básica do AKS:

• Para saber mais sobre a hospedagem de Microsserviços na linha de base do AKS, confira Arquitetura de microsserviços avançada do AKS (Serviço de Kubernetes do Azure).
• Para implantar a linha de base do AKS em várias regiões, confira Linha de base do AKS para clusters de várias regiões.
• Para implantar a linha de base do AKS em um ambiente PCI-DSS 3.2.1, confira Cluster regulamentado do AKS para PCI-DSS 3.2.1.
• Para saber mais sobre as considerações para adicionar contêineres do Windows à arquitetura de referência, consulte o artigo complementar: Contêineres do Windows na arquitetura básica de referência do AKS

Saiba mais sobre o AKS

• Consulte o roteiro do produto AKS em Roteiro do Serviço de Kubernetes do Azure no GitHub.
• Caso você precise de uma reciclagem sobre o Kubernetes, faça os roteiros de aprendizagem Introdução ao Kubernetes e Desenvolver e implantar aplicativos no Kubernetes.

Recursos relacionados

Confira os seguintes guias relacionados:

• Revisão do Azure Well-Architected Framework para o Serviço de Kubernetes do Azure (AKS)
• O Acelerador de zona de destino do AKS, que é uma implementação em escala empresarial baseada nessa arquitetura. O acelerador ajuda você a configurar seu ambiente do Azure de maneira consistente e repetível usando IaC (Infraestrutura como código) para uma implantação do Serviço de Kubernetes do Azure (AKS).
• Guia de operações do AKS (Serviços de Kubernetes do Azure) – Dia 2

Consulte as seguintes arquiteturas relacionadas:

• Arquitetura de microsserviços no Serviço de Kubernetes do Azure
• Usar o Firewall do Azure para ajudar a proteger um cluster do AKS (Serviço de Kubernetes do Azure)
• GitOps para Serviço de Kubernetes do Azure
• Streaming de dados com o AKS