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

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

Essa arquitetura não é focada em uma carga de trabalho, mas se concentra no cluster AKS em si. 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 fornecem observabilidade, uma topologia de rede que dá 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. Deve ser considerado como o seu ponto de partida para as fases 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 Kubernetes do Azure (AKS). Você pode usá-lo como um ponto de partida alternativo e configurá-lo com base em suas necessidades.

Configuração da rede

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

Computação em cluster

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

Gestão de identidades

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

Fluxo de dados seguro

Proteger o fluxo de rede
Adicionar gerenciamento secreto

Continuidade do negócio

Escalabilidade
Disponibilidade de cluster e nó
Disponibilidade e suporte multirregional

Operações

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

Topologia de rede

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

• Gestão segregada. Permite uma maneira de aplicar a governança e aderir ao princípio do menor privilégio. Ele também suporta o conceito de uma zona de pouso do Azure com separação de tarefas.

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

• As organizações geralmente operam com topologias regionais hub-spoke. As 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 WAF (Web Application Firewall) para ajudar a controlar o fluxo de tráfego HTTP.

• Uma escolha natural para cargas de trabalho que abrangem várias assinaturas.

• Torna a arquitetura extensível. Para acomodar novos recursos ou cargas de trabalho, novos raios podem ser adicionados em vez de redesenhar a topologia de rede.

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

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

Transfira um ficheiro do Visio desta arquitetura.

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

Para revisar as alterações de design de rede incluídas nos contêineres do Windows na arquitetura de referência de linha de base do AKS, consulte 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 globais de firewall definidas por suas equipes centrais de TI para impor a política de firewall em toda a organização, o Azure Bastion, uma sub-rede de gateway para conectividade VPN e o Azure Monitor para observabilidade de rede.

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

Sub-rede para hospedar o Firewall do Azure

O Firewall do Azure é um firewall como um 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 de terceiros mal-intencionado que pode exfiltrar dados confidenciais da empresa. O Gerenciador de Firewall do Azure permite implantar e configurar centralmente várias instâncias do Firewall do Azure e gerenciar políticas de Firewall do Azure para esse tipo de arquitetura de rede de rede virtual de hub .

Sub-rede para hospedar um gateway

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

Sub-rede para hospedar o Azure Bastion

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

Entrevistas

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

Sub-rede para hospedar o Gateway de Aplicativo do Azure

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

Sub-rede para hospedar os recursos de entrada

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

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

Sub-rede para hospedar pontos de extremidade de Link Privado

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, para que esses serviços possam ser acessados usando o ponto de extremidade privado dentro 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 de linha de base, eles são implantados em uma sub-rede dedicada dentro da rede virtual falada. Essa abordagem reduz o tráfego que passa pela conexão de rede emparelhada, mantém os recursos que pertencem ao cluster na mesma rede virtual e permite que você aplique regras de segurança granulares no nível da sub-rede usando grupos de segurança de rede.

Para obter mais informações, consulte Opções de implantação de Link Privado.

Planear os endereços IP

Transfira um ficheiro do Visio desta arquitetura.

O espaço de endereço da rede virtual deve ser grande o suficiente para armazenar todas as sub-redes. Conta para todas as entidades que receberão tráfego. Os endereços IP dessas entidades serão alocados a partir do espaço de endereço da sub-rede. Considere estes pontos.

• Atualização

  O AKS atualiza os nós regularmente para garantir que as máquinas virtuais subjacentes estejam atualizadas sobre recursos de segurança e outros patches do sistema. Durante um processo de atualização, o AKS cria um nó que hospeda temporariamente os pods, enquanto o nó de atualização é isolado e drenado. Esse nó temporário recebe um endereço IP da sub-rede do cluster.

  Para pods, você pode precisar de endereços adicionais, dependendo da sua estratégia. Para atualizações contínuas, 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 os novos serão criados. Assim, os endereços associados aos pods antigos são reutilizados.

• Escalabilidade

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

  Nesta arquitetura, cada pod pode ser contatado diretamente. Assim, cada pod precisa de um endereço individual. A escalabilidade do pod afetará o cálculo do endereço. Essa decisão dependerá da sua escolha sobre o número de vagens que você deseja cultivar.

• Endereços de Link Privado do Azure

  Considere os endereços necessários para a comunicação com outros serviços do Azure por Link Privado. Nessa arquitetura, temos dois endereços atribuídos para os links para o Registro de Contêiner do Azure e o Cofre da Chave.

• Determinados endereços são reservados para uso pelo Azure. Eles não podem ser atribuídos.

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

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

Para obter o conjunto completo de considerações para esta arquitetura, consulte Topologia de rede de linha de base AKS.

Para obter informações relacionadas ao planejamento de IP para um cluster AKS, consulte Planejar endereçamento IP para seu cluster.

Para examinar 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 e complementos AKS selecionados. A diferença entre os dois é a seguinte:

• A equipe do AKS descreve os recursos de visualização como enviados e melhorando. 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 suportadas. 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 de visualização ou complementos, em vez disso, apenas aqueles que agregam valor significativo a um cluster de uso geral são incluídos. À medida que esses recursos saem da visualização, essa arquitetura de linha de base será revisada de acordo. Existem 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 várias outras imagens, como o controlador de entrada. Algumas dessas imagens podem residir em registos públicos. Considere esses pontos ao puxá-los para o cluster.

• O cluster é autenticado para extrair a imagem.

• Se você estiver usando uma imagem pública, considere importá-la para seu registro de contêiner que esteja alinhado com seu SLO. Caso contrário, a imagem pode estar sujeita a problemas de disponibilidade inesperados. Esses problemas podem causar problemas operacionais se a imagem não estiver disponível quando você precisar dela. Aqui estão alguns benefícios de usar seu registro de contêiner em vez de um registro público:

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

  Uma opção é o Azure Container Registry (ACR).

• Extraia imagens de registos autorizados. Você pode impor essa restrição por meio da Política do Azure. Nessa implementação de referência, o cluster só extrai imagens do ACR que é implantado como parte da arquitetura.

Configurar a computação para o cluster base

No AKS, cada pool de nós é mapeado para um Conjunto de Escala de Máquina Virtual. Os nós são VMs em cada pool de nós. Considere o uso de um tamanho de VM menor para o pool de nós do sistema para minimizar os custos. Esta implementação de referência implanta o pool de nós do sistema com três nós DS2_v2. Esse tamanho é suficiente para atender à carga esperada dos pods do sistema. O disco do SO tem 512 GB.

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

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

• Implante pelo menos dois nós. Dessa forma, a carga de trabalho terá um padrão de alta disponibilidade com duas réplicas. Com o AKS, você pode alterar a contagem de nós sem recriar o cluster.

• Os tamanhos reais dos nós para sua 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, pode-se baixar o tamanho para DS3_v2, que é a recomendação mínima.

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

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

Integrar o Microsoft Entra ID para o cluster

Proteger o acesso de e para o cluster é fundamental. Pense na perspetiva do cluster quando estiver fazendo escolhas de segurança:

• Acesso de dentro para fora. Acesso AKS a componentes do Azure, como infraestrutura de rede, Azure Container Registry e Azure Key Vault. Autorize apenas os recursos que o cluster tem permissão para acessar.
• Acesso exterior-in. Fornecendo acesso de identidades ao cluster do Kubernetes. Autorize apenas as entidades externas que têm permissão de acesso ao servidor de API do Kubernetes e ao Gerenciador de Recursos do Azure.

Acesso do AKS ao Azure

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

Das duas maneiras, as identidades gerenciadas são recomendadas. Com as entidades de serviço, você é responsável por gerenciar e girar 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. Você pode 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 AKS para gerenciar recursos do cluster, incluindo balanceadores de carga de entrada, IPs públicos gerenciados pelo AKS, etc. A identidade kubelet é usada para autenticar com o Azure Container Registry (ACR). Alguns complementos também oferecem suporte à autenticação usando uma identidade gerenciada.

Como exemplo para o caso de dentro para fora, vamos estudar o uso de identidades gerenciadas quando o cluster precisa extrair imagens de um registro de contêiner. Essa ação requer que o cluster obtenha as credenciais do Registro. Uma maneira é armazenar essas informações na forma do objeto Kubernetes Secrets e usar imagePullSecrets para recuperar o segredo. Essa abordagem não é recomendada devido às complexidades de segurança. Você não só precisa de conhecimento prévio do segredo, mas também da divulgação desse segredo através do pipeline de DevOps. Outra razão é a sobrecarga operacional de gerir a rotação do segredo. Em vez disso, conceda acrPull acesso à identidade gerenciada kubelet do cluster ao seu registro. Esta abordagem dá resposta a essas preocupações.

Nessa arquitetura, o cluster acessa recursos do Azure protegidos pela ID do Microsoft Entra e executa operações que dão suporte a identidades gerenciadas. Atribua o controle de acesso baseado em função do Azure (Azure RBAC) e permissões às identidades gerenciadas do cluster, dependendo das operações que o cluster pretende fazer. O cluster autentica-se no Microsoft Entra ID e, em seguida, é permitido ou negado o acesso 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 falada. Esta atribuição de função permite que a identidade atribuída ao sistema de cluster AKS trabalhe com a sub-rede dedicada para os serviços do Controlador de Entrada Interno.
• Editor 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 acesso externo. Suponha que um usuário queira 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 obter mais informações, consulte Permissões de funções de cluster disponíveis.

O AKS permite o acesso ao Kubernetes usando o Microsoft Entra ID de duas maneiras. O primeiro é usar o Microsoft Entra ID como um provedor de identidade integrado com o sistema RBAC nativo do Kubernetes. 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 suporta controle de acesso baseado em função (RBAC) através de:

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

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

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

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

Em vez de usar 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é ser adicionadas nos escopos de assinatura ou grupo de recursos para que todos os clusters sob o escopo herdem um conjunto consistente de atribuições de função em relação a quem tem permissões para acessar os objetos no cluster do Kubernetes.

Para obter mais informações, consulte RBAC do Azure para Autorização do Kubernetes.

Contas locais

O AKS suporta autenticação de usuário nativa do Kubernetes. O acesso do usuário a clusters usando esse método não é sugerido. Ele é baseado em certificado e é executado fora do seu provedor de identidade principal; dificultando o controle centralizado de acesso de usuários e a governança. Sempre gerencie o acesso ao cluster usando a ID do Microsoft Entra 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 locais é explicitamente desabilitado quando o cluster é implantado.

Integrar o Microsoft Entra ID para a carga de trabalho

Semelhante a ter uma identidade gerenciada atribuída ao sistema do Azure para todo o cluster, você pode atribuir identidades gerenciadas no nível do pod. Uma identidade de carga de trabalho permite que a carga de trabalho hospedada acesse recursos por meio do Microsoft Entra ID. Por exemplo, a carga de trabalho armazena arquivos no Armazenamento do Azure. Quando 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 ID de carga de trabalho do Microsoft Entra 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 ingresso

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

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

  Nessa arquitetura, o Azure Load Balancer é usado. Ele é 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 obter informações sobre a criptografia TLS para tráfego de entrada, consulte Fluxo de tráfego de entrada.

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

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

• Como parte de suas decisões de projeto, escolha um escopo dentro do qual o controlador de entrada será permitido 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ó ficar inativo. Use podAntiAffinity para este fim.

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

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

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

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

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

Configurações de router

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

Aqui está um exemplo dessa arquitetura:

Traefik usa o provedor Kubernetes para configurar rotas. O annotations, tls, e entrypoints indicam que as rotas serão servidas por HTTPS. O middlewares especifica que apenas 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 Traefik faz 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, neste contexto, pode ser categorizado como:

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

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

• Tráfego de pod-to-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 sua carga de trabalho for composta por vários aplicativos implantados no cluster, a comunicação entre esses aplicativos se enquadrará nessa categoria.

• Gestão de tráfego. Tráfego que vai entre o cliente e o servidor de API do Kubernetes.

Transfira um ficheiro do Visio desta arquitetura.

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

Fluxo de tráfego de entrada

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

Transfira um ficheiro do Visio desta arquitetura.

1. O cliente envia uma solicitação HTTPS para o nome de domínio: bicycle.contoso.com. Esse nome é 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 do cliente e o gateway não possa ser inspecionado ou alterado.

2. O Application Gateway tem um firewall de aplicativo da Web (WAF) integrado e negocia o handshake TLS para bicycle.contoso.com, permitindo apenas cifras seguras. O Application Gateway é um ponto de terminação TLS, pois é necessário processar regras de inspeção WAF e executar regras de roteamento que encaminham o tráfego para o back-end configurado. O certificado TLS é armazenado no Cofre da Chave do Azure. Ele é acessado usando uma identidade gerenciada atribuída pelo usuário integrada ao Application Gateway. Para obter informações sobre esse recurso, consulte Terminação TLS com certificados do Cofre de Chaves.

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

4. O controlador de entrada recebe o tráfego criptografado através do balanceador de carga. O controlador é outro ponto de terminação TLS 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 Cofre da Chave do Azure e montados no cluster usando o driver CSI (Container Storage Interface). Para obter mais informações, consulte Adicionar gerenciamento secreto.

Você pode implementar o tráfego TLS de ponta a ponta em todos os saltos até o pod de carga de trabalho. Certifique-se de medir o desempenho, a latência e o impacto operacional ao tomar a decisão de proteger o tráfego de pod para pod. Para a maioria dos clusters de locatário único, com RBAC de plano de controle adequado e práticas maduras de ciclo de vida de desenvolvimento de software, é suficiente criptografar TLS até o controlador de entrada e proteger com o Web Application Firewall (WAF). Isso minimizará a sobrecarga no gerenciamento da carga de trabalho e os impactos no desempenho da rede. Sua carga de trabalho e requisitos de conformidade ditarão onde você executa a rescisão TLS.

Fluxo de tráfego de saída

Nessa arquitetura, recomendamos todo o tráfego de saída do cluster se comunicando por meio do Firewall do Azure ou de seu próprio dispositivo virtual de rede semelhante, em relação a outras opções, como Gateway NAT ou proxy HTTP. Para controle de confiança zero e a capacidade de inspecionar o tráfego, todo o tráfego de saída do cluster é movido pelo Firewall do Azure. Você pode implementar essa opção usando rotas definidas pelo usuário (UDRs). O próximo salto da rota é o endereço IP privado do Firewall do Azure. Aqui, o Firewall do Azure decide se bloqueia ou permite o tráfego de saída. Essa decisão é baseada nas regras específicas definidas no Firewall do Azure ou nas regras internas de inteligência contra ameaças.

Uma alternativa ao uso do Firewall do Azure é utilizar o recurso de 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 soltá-lo.

Com qualquer um dos métodos, revise 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 do contêiner ou segredos do Cofre da Chave do Azure. A abordagem recomendada é usar o Azure Private Link. A vantagem é que sub-redes específicas atingem o serviço diretamente, em vez do tráfego entre o cluster e os serviços que passam pela Internet. Uma desvantagem é que o Private Link 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 oferecem suporte ao Private Link. Para esses casos, considere habilitar um ponto de extremidade de serviço de Rede Virtual na sub-rede para acessar o serviço.

Se o Link Privado ou os pontos de extremidade de serviço não forem uma opção, você poderá acessar outros serviços por meio de seus pontos de extremidade públicos e controlar o acesso por meio das regras do Firewall do Azure e do firewall interno ao serviço de destino. Como esse tráfego 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 à exaustão 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 examinar 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-to-pod

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

Habilite a diretiva de rede quando o cluster for provisionado porque ele não pode ser adicionado posteriormente. Existem algumas opções para as tecnologias que implementam NetworkPolicyo . A Política de Rede do Azure é recomendada, o que requer a CNI (Interface de Rede de Contêiner) do Azure, consulte a observação abaixo. Outras opções incluem Calico Network Policy, uma opção de código aberto bem conhecida. Considere o Calico se precisar gerenciar políticas de rede em todo o cluster. O Calico não é coberto pelo suporte padrão do Azure.

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

Gestão de tráfego

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

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

Para 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 seja exposto à Internet. Para obter mais informações, consulte AKS Private Clusters.

Adicionar a gestão de segredos

Armazene segredos em um repositório de chaves gerenciado, como o Cofre de Chaves do Azure. 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 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 obter um exemplo sobre como o Gateway de Aplicativo do Azure acessa certificados TLS para o fluxo de entrada, consulte a seção Fluxo de tráfego de entrada.

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

Acessando segredos de cluster

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

O driver CSI tem muitos provedores para suportar várias lojas gerenciadas. Nesta implementação, escolhemos o Azure Key Vault with Secrets Store CSI Driver 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 as chaves públicas e privadas.

Armazenamento de carga de trabalho

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

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

Gestão de políticas

Uma maneira eficaz de gerenciar um cluster AKS é aplicando a governança por meio de políticas. O Kubernetes implementa políticas através do OPA Gatekeeper. Para o AKS, as políticas são entregues por meio da Política do Azure. Cada política é aplicada a todos os clusters em seu escopo. Em última análise, a imposição da Política do Azure é tratada pelo OPA Gatekeeper 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 no 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 implementação de clusters AKS num grupo de recursos ou subscrição através da avaliação dos padrões da sua organização. Por exemplo, siga uma convenção de nomenclatura, especifique uma tag, etc.
• Proteja o seu cluster AKS através da Política do Azure para Kubernetes.

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

• Pretende definir um conjunto de políticas (chamadas iniciativas) ou escolher políticas individuais? A Política do Azure fornece duas iniciativas internas: básica e restrita. Cada iniciativa é uma coleção de políticas internas aplicáveis a um cluster AKS. É recomendável selecionar uma iniciativa e escolher políticas adicionais para o cluster e os recursos (ACR, Application Gateway, Key Vault e outros) que interagem com o cluster, de acordo com os requisitos da sua organização.

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

• Você tem áreas em sua carga de trabalho que não devem ser compatíveis por design? A Política do Azure tem a capacidade de especificar namespaces do Kubernetes que estão isentos da imposição de políticas. É recomendável que ainda aplique 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 personalizada de Política do Azure que aplique suas políticas personalizadas do OPA Gatekeeper. Não aplique políticas personalizadas diretamente ao cluster. Para saber mais sobre como criar políticas personalizadas, consulte Criar e atribuir definições de política personalizadas.

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

• As políticas do Azure são atribuídas a escopos específicos. Certifique-se de que as políticas de produção também sejam validadas em relação ao seu ambiente de pré-produção. Caso contrário, ao implantar em seu ambiente de produção, você 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 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 à sua carga de trabalho em uma única atribuição.

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

Para examinar 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 de nós e pods

Com o aumento da demanda, o Kubernetes pode expandir adicionando mais pods aos nós existentes, por meio do dimensionamento automático de pods horizontal (HPA). 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 AKS. Uma solução de dimensionamento completa deve ter maneiras de dimensionar as réplicas de pod e a contagem de nós no cluster.

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

A maneira manual ou programática requer que você monitore e defina alertas sobre a utilização da CPU ou métricas personalizadas. Para o dimensionamento de pods, o operador de aplicativo pode aumentar ou diminuir o número de réplicas de pods ajustando as ReplicaSet APIs do Kubernetes. Para o dimensionamento de cluster, uma maneira é ser notificado quando o agendador do Kubernetes falhar. Outra maneira é observar os pods pendentes ao longo do tempo. Você pode ajustar a contagem de nós por meio da CLI do Azure ou do portal.

O dimensionamento automático é a abordagem recomendada porque alguns desses mecanismos manuais são incorporados ao autoscaler.

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

Dimensionador Automático de Pods Horizontal

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

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

A HPA pode ser dimensionada com base na utilização da CPU, no uso da memória e nas métricas personalizadas. Somente a utilização da CPU é fornecida prontamente. A definição HorizontalPodAutoscaler especifica valores de destino para essas métricas. Por exemplo, a especificação define uma utilização da CPU de destino. Enquanto os pods estão em execução, o controlador HPA usa a API Kubernetes Metrics para verificar a utilização da CPU de cada pod. Ele compara esse valor com a utilização de destino e calcula uma proporção. Em seguida, ele usa a proporção para determinar se os pods estão superalocados ou subalocados. Ele depende do agendador do Kubernetes para atribuir novos pods aos nós ou remover pods dos nós.

Pode haver uma condição de corrida em que (HPA) verifica antes que uma operação de dimensionamento seja concluída. O resultado pode ser um cálculo de proporção incorreto. Para obter detalhes, consulte Cooldown de eventos de dimensionamento.

Se a sua carga de trabalho for orientada por eventos, uma opção de código aberto popular é o KEDA. Considere o KEDA se sua carga de trabalho for conduzida por uma fonte de eventos, como fila de mensagens, em vez de estar vinculada à CPU ou à memória. O KEDA suporta muitas fontes de eventos (ou scalers). Você pode encontrar a lista de escaladores KEDA suportados aqui, incluindo o escalador do Azure Monitor, uma maneira conveniente de dimensionar cargas de trabalho KEDA com base nas métricas do Azure Monitor.

Dimensionador automático de cluster

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

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

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

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

Para examinar 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 de 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 obter informações sobre o cálculo do tempo de atividade mensal, consulte SLA para o Serviço Kubernetes do Azure (AKS).

Nós do cluster

Para atender ao nível mínimo de disponibilidade para cargas de trabalho, vários nós em um pool de nós são necessários. 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 pelo menos dois nós. Se você precisar de maior disponibilidade, provisione mais nós.

Isole o(s) seu(s) aplicativo(s) dos serviços do sistema colocando-os em um pool de nós separado, conhecido como pool de nós de usuário. Dessa forma, os serviços do Kubernetes são executados em nós dedicados e não competem com sua carga de trabalho. O uso de tags, rótulos e taints é 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 seu cluster, como atualizações oportunas, é crucial para a confiabilidade. Também é recomendado monitorar a saúde das cápsulas através de sondas.

Disponibilidade do pod

Garanta os recursos do pod. É altamente recomendável que as implantações especifiquem os requisitos de recursos do pod. O agendador pode então agendar adequadamente o pod. A confiabilidade diminuirá significativamente se os pods não puderem ser programados.

Defina orçamentos de interrupção de pod. Essa configuração determina quantas réplicas em uma implantação podem cair durante um evento de atualização ou atualização. Para obter mais informações, consulte Orçamentos de interrupção de pod.

Configure várias réplicas na implantação para lidar com interrupções, como falhas de hardware. Para eventos planejados, como atualizações e upgrades, um orçamento de interrupção pode garantir que o número necessário de réplicas de pod exista 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 e limites de pod. A definição desses limites permite que o Kubernetes aloque recursos de CPU e/ou memória de forma eficiente 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 à melhor utilização do hardware.

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

Esses limites podem ser especificados em seus manifestos de implantação. Para obter mais informações, consulte Definir solicitações e limites de pod.

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

Se o seu SLA exigir um tempo de atividade maior, proteja-se contra interrupções usando zonas de disponibilidade. Você pode usar zonas de disponibilidade se a região oferecer suporte a elas. Os componentes do plano de controle e os nós nos pools de nós são então capazes de se espalhar entre zonas. Se uma zona inteira não estiver disponível, um nó em outra zona dentro da região ainda estará disponível. Cada pool de nós é mapeado para um Conjunto de Escala de Máquina Virtual separado, que gerencia instâncias de nó e escalabilidade. As operações e a configuração do conjunto de escala são gerenciadas pelo serviço AKS. Aqui estão algumas considerações ao ativar a multizona:

• Toda a infraestrutura. Escolha uma região que ofereça suporte a zonas de disponibilidade. Para obter mais informações, consulte Limitações e disponibilidade da região. Se você quiser comprar um SLA de tempo de atividade, escolha uma região que ofereça suporte a essa opção. O SLA de tempo de atividade é maior ao usar zonas de disponibilidade.

• Aglomeração. As zonas de disponibilidade só podem ser definidas quando o pool de nós é criado e não podem ser alteradas posteriormente. Os tamanhos dos nós devem ser suportados em todas as zonas para que a distribuição esperada seja possível. O Conjunto de Dimensionamento de Máquina Virtual subjacente fornece a mesma configuração de hardware entre zonas.

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

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

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

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

Várias regiões

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

• Use regiões emparelhadas. Considere o uso de um pipeline de CI/CD configurado para usar uma região emparelhada para 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 no par seja atualizada de cada vez. Certas ferramentas de DevOps, como o Flux, podem facilitar as implantações em várias regiões.

• Se um recurso do Azure der suporte à redundância geográfica, forneça o local onde o serviço redundante terá seu secundário. Por exemplo, habilitar a replicação geográfica para o Registro de Contêiner do Azure replicará automaticamente as imagens para as regiões selecionadas do Azure e fornecerá acesso contínuo às imagens, mesmo que uma região esteja passando por uma interrupção.

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

Recuperação após 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 a seguir algumas recomendações:

• Use regiões emparelhadas.

• Uma carga de trabalho sem monitoração de estado pode ser replicada de forma eficiente. Se você precisar armazenar o estado no cluster (não recomendado), certifique-se de fazer backup dos dados com freqüência na região emparelhada.

• Integre a estratégia de recuperação, como replicar para outra região, como parte do pipeline de DevOps para atender aos seus Objetivos de Nível de Serviço (SLO).

• Ao provisionar cada serviço do Azure, escolha recursos que ofereçam suporte à recuperação de desastres. 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á extrair 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 de aplicativos. No entanto, se houver um estado crítico do recurso, como mapas de configuração, trabalhos e segredos potenciais que, por algum motivo, não podem ser capturados em seu processo de inicialização, considere sua estratégia de recuperação. Geralmente, é recomendado executar cargas de trabalho sem 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 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 uma solução comum de backup do Kubernetes que você pode instalar e gerenciar diretamente. Como alternativa, a extensão de backup AKS pode ser usada para fornecer uma implementação gerenciada do Velero. A extensão de backup AKS suporta o backup de recursos do Kubernetes e volumes persistentes, com agendamentos e escopo de backup externalizados como configuração de cofre no Backup do Azure.

A implementação de referência não implementa 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 estado é a solução de recuperação implementada.

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

Kubernetes API Server SLA

O AKS pode ser usado como um serviço gratuito, mas esse nível não oferece um SLA apoiado financeiramente. Para obter esse SLA, você deve escolher a camada Padrão. Recomendamos que todos os clusters de produção usem a camada Padrão. 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 por seu próprio SLA.

Compensação

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

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

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

Garanta a confiabilidade por meio de testes de failover forçados com interrupçõ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 porque você pode exibir eventos em tempo real. Ele captura logs de contêiner dos pods em execução e os agrega para visualização. Ele também coleta informações da API de métricas sobre a utilização da memória e da CPU para monitorar a integridade dos recursos e cargas de trabalho em execução. Você também pode usá-lo para monitorar o desempenho à medida que os pods escalam. Ele inclui a 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 de problemas críticos.

A maioria das cargas de trabalho hospedadas em pods emite métricas 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, Grafana ou New Relic, se sua organização já as usa.

Com o AKS, o Azure gerencia alguns serviços principais do Kubernetes e os logs para os componentes do plano de controle do AKS são implementados no Azure como logs de recursos. É recomendável que a maioria dos clusters tenha sempre o seguinte habilitado, pois eles podem ajudá-lo a solucionar problemas de cluster e têm uma densidade de log relativamente baixa:

• Registro em log no ClusterAutoscaler para obter observabilidade nas operações de dimensionamento. Para obter mais informações, consulte Recuperar logs e status do autoscaler do 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á razão para ter o KubeAudit e o KubeAuditAdmin habilitados, pois o KubeAudit é um superconjunto do KubeAuditAdmin que também inclui operações não modificadas (leituras).
• 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, 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, uma vez que as necessidades de solução de problemas terminam, 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 consultas. Sua biblioteca personalizada de consultas ajuda a permitir observabilidade adicional na integridade e no desempenho de seus clusters AKS e suporta 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 Kubernetes do Azure (AKS) com o Azure Monitor.

Para examinar 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 do AKS, consulte o artigo complementar.

Habilite a autorrecuperação

Monitore a integridade dos pods definindo sondas Liveness e Readiness (Vivacidade) e Prontidão. Se um pod que não responde for detetado, o Kubernetes reinicia o pod. A sonda Liveness determina se a cápsula está saudável. Se ele não responder, o Kubernetes reiniciará o pod. A sonda de prontidão determina se o pod está pronto para receber solicitações/tráfego.

Atualizações do cluster AKS

Definir uma estratégia de atualização que seja consistente com os requisitos de negócios é fundamental. Compreender o nível de previsibilidade para a data e hora em que a versão do cluster AKS ou seus nós são atualizados, e o grau desejado de controle sobre qual imagem específica ou binários são instalados são aspetos fundamentais que delinearão seu plano de atualização do cluster AKS. A previsibilidade está ligada a duas propriedades principais de atualização do cluster 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 AKS que não estão sob uma regulamentação de segurança rigorosa podem considerar atualizações semanais ou até mensais, enquanto o restante deve atualizar patches rotulados de segurança assim que disponíveis (diariamente). As organizações que operam clusters AKS como infraestrutura imutável não estão atualizando-os. Isso significa que nem atualizações automáticas nem manuais são realizadas. Em vez disso, quando uma atualização desejada fica disponível, um carimbo de réplica é implantado e somente quando a nova instância de infraestrutura está pronta, a antiga é drenada, dando a eles o mais alto nível de controle.

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

• Nós AKS:

  1. Nenhuma/Atualizações manuais: Destina-se a infraestruturas imutáveis ou quando as atualizações manuais são a preferência. Isso alcança um maior nível de previsibilidade e controle sobre as atualizações dos nós AKS.
  2. Atualizações automáticas autônomas: o AKS executa atualizações nativas do sistema operacional. Isso dá previsibilidade ao configurar janelas de manutenção alinhadas com o que é bom para o negócio. Pode basear-se nas horas de ponta e no que é melhor em termos de operações. O nível de controlo é baixo, uma vez que não é possível saber antecipadamente o que vai ser especificamente instalado no nó AKS.
  3. Atualizações automáticas de imagens de nós: Recomenda-se atualizar automaticamente as imagens de nós AKS quando novos discos rígidos virtuais (VHDs) estiverem disponíveis. Projete janelas de manutenção para estar alinhadas tanto quanto possível com as necessidades do negócio. Para atualizações de VHD rotuladas como segurança, recomenda-se configurar uma janela de manutenção diária que ofereça a menor previsibilidade. As atualizações regulares de VHD podem ser configuradas com uma janela de manutenção semanal, a cada duas semanas ou até mensalmente. Dependendo se a necessidade é de VHDs com rótulo de segurança versus VHDs regulares combinados com a janela de manutenção programada, a previsibilidade flutua, oferecendo mais ou menos flexibilidade para estar alinhada com os requisitos de negócios. Embora deixar isso sempre ao critério dos requisitos de negócio fosse o ideal, a realidade obriga as organizações a encontrar o ponto de inflexão. O nível de controle é baixo, pois não é possível saber com antecedência quais binários específicos foram incluídos em um novo VHD e ainda assim esse tipo de atualizações automáticas são a opção recomendada, já que as imagens são verificadas antes de ficarem disponíveis.

  Nota

  Para obter mais informações sobre como configurar atualizações automáticas de nós AKS, dê uma olhada nas imagens do sistema operacional do nó de atualização automática.

• Versão do cluster AKS:

  1. Nenhuma/Atualizações manuais: Destina-se a infraestruturas imutáveis ou quando as atualizações manuais são a preferência. Isso alcança um maior nível de previsibilidade e controle sobre as atualizações de versão do cluster AKS. Recomenda-se optar por isso, uma vez que isso está deixando o controle total, dando a chance de testar uma nova versão do cluster AKS (ou seja, 1.14.x a 1.15.x) em ambientes mais baixos antes de atingir a produção.
  2. Atualizações automáticas: Não se recomenda que um cluster de produção seja corrigido ou atualizado automaticamente 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 da versão do cluster AKS sejam coordenadas fornecendo uma cadência regular, a recomendação ainda deve ser defensiva com clusters AKS em produção, aumentando a previsibilidade e o controle sobre o processo de atualização. Não considere essa configuração para ambientes inferiores como parte da Excelência Operacional, permitindo execuções proativas de testes de rotina para detetar possíveis problemas o mais cedo possível.

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

Para obter mais informações, consulte Atualizar regularmente para a versão mais recente do Kubernetes e Atualizar um cluster do Serviço Kubernetes do Azure (AKS).

A notificação de eventos gerados pelo cluster, como a disponibilidade da nova versão do AKS para o cluster, pode ser obtida por meio do Tópico do Sistema AKS para a Grade de Eventos do Azure. A implementação de referência implanta este Tópico do Sistema de Grade de Eventos para que você possa se inscrever no evento a Microsoft.ContainerService.NewKubernetesVersionAvailable partir de sua solução de notificação de fluxo de eventos.

Atualizações semanais

O AKS fornece novas imagens de nó que têm as atualizações mais recentes do sistema operacional e do tempo de execução. 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 que você tenha um processo para atualizar a imagem base dos pools de nós semanalmente. Para obter mais informações, consulte Atualizar a imagem do nó do Serviço Kubernetes do Azure (AKS) nas Notas de Versão do AKS.

Atualizações diárias

Entre atualizações de imagem, os nós AKS baixam e instalam patches de sistema operacional e tempo de execução, individualmente. Uma instalação pode exigir que as VMs do nó sejam reinicializadas. O AKS não reinicializará 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 é Kured (daemon de reinicialização do Kubernetes).

Manter as imagens do nó sincronizadas com a versão semanal mais recente minimizará essas solicitações ocasionais de reinicialização, mantendo uma postura de segurança aprimorada. Confiar apenas em atualizações de imagem de nó garantirá compatibilidade com AKS e patches de segurança semanais. 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 sua principal estratégia semanal de aplicação de patches de segurança.

Controlo de segurança

Monitore sua infraestrutura de contêiner quanto a ameaças ativas e potenciais riscos à segurança:

• Habilite o Microsoft Defender for Containers para identificar e corrigir as recomendações do Defender for Cloud para suas imagens de contêiner.
• O Microsoft Defender for Containers verifica regularmente suas imagens de contêiner em busca de vulnerabilidades.
• O Microsoft Defender for Containers também gera alertas de segurança em tempo real para atividades suspeitas.
• Para obter informações sobre proteção de segurança aplicada a hosts de máquinas virtuais AKS, consulte Proteção de segurança no sistema operacional do host.

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

Aqui estão algumas considerações. Para obter mais informações, consulte o pilar Excelência Operacional .

Inicialização de cluster

Após a conclusão do provisionamento, você terá um cluster de trabalho, mas ainda pode haver etapas necessárias antes de implantar cargas de trabalho. O processo de preparação do cluster é chamado de bootstrapping e pode consistir em ações como implantar imagens de pré-requisito em nós de cluster, criar namespaces e qualquer outra coisa que satisfaça os 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á seu processo de inicialização exclusivo e preparar ativos relevantes com antecedência. Por exemplo, se ter Kured em execução em cada nó antes de implantar cargas de trabalho de aplicativo for importante, o operador de cluster desejará garantir que um ACR contendo a imagem Kured de destino já exista antes de provisionar o cluster.

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

• Auto-configuração usando algo como Flux ou Argo CD
• Pipelines
• Extensão de cluster GitOps Flux v2

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

Finalmente, ao usar a extensão, kubectl não é necessário para qualquer parte do processo de inicialização, e o uso do acesso baseado em -based pode ser reservado para situações de reparo de kubectlfalha 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 kubectlo .

Isolar as responsabilidades da carga de trabalho

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

Comece com uma carga de trabalho básica que contenha os componentes fundamentais e construa com base nela. Uma tarefa inicial seria configurar a rede. Provisione redes virtuais para o hub e spoke e 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 infraestrutura como código (IaC)

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

Certifique-se de provisionar recursos de acordo com as políticas de governança. Por exemplo, ao selecionar os tamanhos de VM corretos, mantenha-se dentro das restrições de custo, opções de zona de disponibilidade para corresponder aos requisitos do seu aplicativo.

Se você precisar escrever uma sequência de comandos, use a CLI do Azure. Esses comandos abrangem uma variedade de serviços do Azure e podem ser automatizados por meio de scripts. A CLI do Azure é suportada no Windows e Linux. Outra opção de plataforma cruzada é o Azure PowerShell. Sua escolha dependerá do conjunto de habilidades preferidas.

Armazene scripts e arquivos de modelo e arquivos de modelo em seu sistema de controle de origem.

Carga de trabalho CI/CD

Os pipelines para fluxo de trabalho e implantação devem ter a capacidade de criar e implantar aplicativos continuamente. As 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 entrega contínua (CD) 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 as Ações do GitHub para gerenciar o fluxo de trabalho e a implantação. Outras opções populares incluem os Serviços de DevOps do Azure e o Jenkins.

Cluster CI/CD

Transfira um ficheiro do Visio desta arquitetura.

Em vez de usar uma abordagem imperativa como o kubectl, use ferramentas que sincronizem automaticamente as alterações de cluster e repositório. Para gerenciar o fluxo de trabalho, como o lançamento de uma nova versão e a validação dessa versão antes da implantação na 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 GitOps é útil para esse fim, permitindo que os operadores definam declarativamente o processo de inicialização como parte da estratégia IaC e vejam a configuração refletida no cluster automaticamente.

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.
• Deteta novas alterações de configuração.
• Aciona implantações.
• Atualiza a configuração de execução desejada com base nessas alterações.

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

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

Transfira um ficheiro do Visio desta arquitetura.

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

2. O Flux é executado em pod juntamente com a carga de trabalho. O Flux tem acesso somente leitura ao repositório git para garantir que o Flux esteja aplicando apenas as alterações solicitadas 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 através do kubectl.

5. Tenha políticas de ramificação no 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 carga de trabalho e implantação de 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 desvendar problemas antes de implantar na produção.

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

Técnicas avançadas de implantação, como implantação azul-verde, testes A/B e versões Canary, exigirão processos adicionais e, potencialmente, ferramentas. O Flagger é uma solução de código aberto popular para ajudar a resolver seus cenários avançados de implantação.

Gestão de custos

Comece por rever a lista de verificação do projeto de otimização de custos e a lista de recomendações descritas no Well Architected Framework for AKS. Use a calculadora de preços do Azure para estimar os custos dos serviços usados na arquitetura. Outras práticas recomendadas são descritas na seção Otimização de custos no Microsoft Azure Well-Architected Framework.

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

Para examinar 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 do AKS, consulte o artigo complementar.

Aprovisionar 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 da 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 DS2_v2 SKU é um tipo de VM típico para o pool de nós do sistema.

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

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

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

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

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

• Habilitar diagnósticos 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 obter mais informações, consulte VMs reservadas.

• Use tags ao criar pools de nós. As tags são úteis na criação de relatórios personalizados para acompanhar os custos incorridos. As tags dão a capacidade de rastrear o total de despesas e mapear qualquer custo para um recurso ou equipe específica. Além disso, se o cluster for compartilhado entre equipes, crie relatórios de estorno por consumidor para identificar custos medidos para serviços de nuvem compartilhados. Para obter mais informações, consulte Especificar uma mancha, rótulo ou marca para um pool de nós.

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

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

Monitor

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

• Assistente do Azure

• Azure Cost Management

O ideal é monitorar o custo em tempo real ou, pelo menos, em uma cadência regular para agir antes do final do mês, quando os custos já estão calculados. Monitore também a tendência mensal ao longo do tempo para se manter no orçamento.

Para tomar decisões orientadas por dados, identifique qual recurso (nível granular) incorre em mais custos. Tenha também uma boa compreensão dos medidores que são usados para calcular o uso de cada recurso. Ao analisar métricas, você pode determinar se a plataforma está superdimensionada, por exemplo. Você pode ver os medidores de uso nas métricas do Azure Monitor.

Otimização

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

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

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

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

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

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

Próximos passos

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

• Para saber mais sobre como hospedar microsserviços na linha de base do AKS, consulte Arquitetura avançada de microsserviços do Serviço Kubernetes do Azure (AKS).
• Para implantar a linha de base AKS em várias regiões, consulte Linha de base AKS para clusters multirregionais.
• Para implantar a linha de base AKS em um ambiente PCI-DSS 3.2.1, consulte Cluster regulado pelo 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 de referência de linha de base AKS

Saiba mais sobre o AKS

• Analise o roteiro do produto AKS, consulte Roteiro do Serviço Kubernetes do Azure no GitHub.
• Se você precisar de uma atualização no Kubernetes, conclua a Introdução ao Kubernetes e Desenvolva e implante aplicativos nos caminhos de aprendizado do Kubernetes .

Recursos relacionados

Consulte os seguintes guias relacionados:

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

Veja as seguintes arquiteturas relacionadas:

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