Arquitetura avançada de microsserviços do AKS (Serviço de Kubernetes do Azure)

Essa arquitetura de referência descreve várias configurações a serem consideradas quando você executa microsserviços no AKS (Serviço de Kubernetes do Azure). Este artigo discute a configuração de política de rede, o dimensionamento automático de pods e o rastreamento distribuído em um aplicativo baseado em microsserviço.

Essa arquitetura se baseia na arquitetura de linha de base do AKS, que serve como ponto de partida para a infraestrutura do AKS. A linha de base do AKS descreve recursos infraestruturais, como a ID de carga de trabalho do Microsoft Entra, restrições de entrada e saída, limites de recursos e outras configurações seguras de infraestrutura do AKS. Esses recursos não são abordados neste artigo. Recomendamos que você se familiarize com a arquitetura de linha de base do AKS antes de continuar com o conteúdo de microsserviços.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Se você preferir começar com um exemplo de microsserviços mais básico no AKS, consulte a arquitetura de microsserviços no AKS.

Workflow

Esse fluxo de solicitação implementa os padrões de design de nuvem Publicador-Assinante, Consumidores Concorrentes e Roteamento de Gateway.

O fluxo de dados a seguir corresponde ao diagrama anterior:

1. Uma solicitação HTTPS é enviada para agendar uma retirada de drone. A solicitação passa pelo Gateway de Aplicativo do Azure para o aplicativo Web de ingestão, que é executado como um microsserviço no cluster no AKS.

2. O aplicativo Web de ingestão produz uma mensagem e a envia para a fila de mensagens do Barramento de Serviço do Azure.

3. O sistema de back-end atribui um drone e notifica o usuário. O microsserviço de fluxo de trabalho realiza as seguintes tarefas:

   • Consome informações de mensagem da fila de mensagens do Service Bus.

   • Envia uma solicitação HTTPS para o microsserviço de entrega, que passa dados para o armazenamento de dados externo do Redis Gerenciado do Azure.

   • Envia uma solicitação HTTPS para o microsserviço do agendador de drones.

   • Envia uma solicitação HTTPS para o microsserviço de pacote, que passa dados para o armazenamento de dados externo do Azure DocumentDB.

   • As políticas avançadas dos Serviços de Rede de Contêiner (Cilium NetworkPolicy) regem o tráfego entre serviços dentro do cluster, e o plano de dados de rede impõe, de forma transparente, a criptografia opcional de pods em comunicação entre nós (WireGuard). Os Serviços Avançados de Rede de Contêineres não estão habilitados por padrão. Ele busca dados em nível de nó e de pod e faz a ingestão deles no Azure Monitor para visibilidade completa de ponta a ponta.

4. A arquitetura usa uma solicitação HTTPS GET para retornar o status de entrega. Essa solicitação passa pelo Gateway de Aplicativo para o microsserviço de entrega.

5. O microsserviço de entrega lê dados do Redis Gerenciado do Azure.

Componentes

• O AKS é uma plataforma gerenciada do Kubernetes que fornece clusters gerenciados para implantar e dimensionar aplicativos em contêineres. Quando você usa o AKS, o Azure gerencia o servidor de API do Kubernetes. O operador de cluster pode acessar e gerenciar os nós ou pools de nós do Kubernetes. Essa arquitetura usa os seguintes recursos de infraestrutura do AKS:

  • A ID do Microsoft Entra gerenciada pelo AKS para o RBAC do Azure (controle de acesso baseado em função) do Azure é um recurso que integra a ID do Microsoft Entra ao AKS para impor o controle de acesso baseado em identidade. Nessa arquitetura, ela garante autenticação e autorização seguras e centralizadas para usuários de cluster e cargas de trabalho.

  • A CNI do Azure alimentada pelo Cilium é a solução de rede recomendada para se conectar diretamente a uma rede virtual do Azure. Nessa arquitetura, ele atribui endereços IP da rede virtual aos pods, fornecendo recursos internos de política de rede e visibilidade de tráfego.

  • Os Serviços Avançados de Rede de Contêineres são um conjunto de recursos de rede gerenciados para o AKS que fornece observabilidade de rede e segurança aprimorada no cluster:

    • A Observabilidade de Rede de Contêineres usa ferramentas baseadas no Filtro de Pacotes Berkeley Estendido (eBPF), como Hubble e Retina, para coletar consultas do Sistema de Nomes de Domínio (DNS), fluxos de pod a pod e de pod a serviço, quedas de pacotes e outras métricas. Ele funciona em planos de dados Cilium e não Cilium Linux. Ele também se integra ao serviço gerenciado do Azure Monitor para Prometheus e Azure Grafana Gerenciado para visualização e alertas. Nessa arquitetura, a Observabilidade de Rede de Contêiner diagnostica configurações incorretas de política, latência ou erros de DNS e desequilíbrios de tráfego entre microsserviços.

    • A Segurança de Rede de Contêiner aplica-se a clusters que usam o CNI do Azure alimentado pelo Cilium. Ele impõe recursos do Cilium NetworkPolicy, como a filtragem de saída baseada em FQDN (nome de domínio totalmente qualificado), para reduzir a sobrecarga operacional e implementar a segmentação de rede com confiança zero. Nessa arquitetura, as políticas de FQDN no cluster funcionam com o Firewall do Azure ou o Gateway de NAT do Azure para impor a saída com privilégios mínimos, simplificando a manutenção da política.

  • O complemento do Azure Policy para AKS é uma extensão interna que traz controles de governança e conformidade diretamente para seus clusters do AKS. Ele aplica regras de governança em recursos do AKS usando o Azure Policy. Nessa arquitetura, ela impõe a conformidade validando as configurações e restringindo implantações não autorizadas.

  • A entrada NGINX gerenciada com o complemento de roteamento de aplicativos é um recurso no AKS que ajuda você a expor seus aplicativos à Internet usando o tráfego HTTP ou HTTPS. Ele fornece um controlador de entrada NGINX pré-configurado para o AKS. Nessa arquitetura, a solução executa o roteamento de tráfego para serviços e permite a exposição dos pods ao Gateway de Aplicações.

  • A separação do pool de nós do sistema e do usuário é uma prática arquitetônica que divide os nós de cluster em dois tipos distintos de pools de nós e isola os componentes de infraestrutura do AKS das cargas de trabalho do aplicativo. Nessa arquitetura, a segurança e a eficiência de recursos são aprimoradas dedicando pools de nós a funções operacionais específicas.

  • ID de Carga de Trabalho é uma maneira segura e escalável para cargas de trabalho do Kubernetes acessarem recursos do Azure usando a Microsoft Entra ID sem precisar de segredos ou credenciais armazenadas no cluster. A ID da carga de trabalho permite que as cargas de trabalho do AKS acessem com segurança os recursos do Azure usando a identidade federada. Nessa arquitetura, ela elimina a necessidade de segredos e melhora a postura de segurança por meio do acesso baseado em identidade.

• O Gateway de Aplicativo é um serviço gerenciado pelo Azure que fornece balanceamento de carga de camada 7 e recursos de Firewall de Aplicativos Web (WAF). Nessa arquitetura, ela expõe o microsserviço de ingestão como um ponto de extremidade público e equilibra o tráfego da Web de entrada para o aplicativo.

• O Firewall do Azure é um serviço gerenciado pelo Azure que fornece segurança de rede inteligente e nativa de nuvem e proteção contra ameaças. Nessa arquitetura, ela controla as comunicações de saída de microsserviços para recursos externos, o que permite apenas FQDNs aprovados como tráfego de saída.

• O Link Privado do Azure é um serviço gerenciado pelo Azure que permite a conectividade privada com ofertas de PaaS (plataforma como serviço) do Azure por meio da rede de backbone da Microsoft. Nessa arquitetura, ele atribui endereços IP privados para acessar o Registro de Contêiner do Azure e o Azure Key Vault de pools de nós do AKS por meio de pontos de extremidade privados.

• A Rede Virtual do Azure é um serviço gerenciado pelo Azure que fornece ambientes isolados e seguros para executar aplicativos e VMs (máquinas virtuais). Nessa arquitetura, ela usa uma topologia de hub-spoke emparelhada. A rede de hub hospeda o Firewall do Azure e o Azure Bastion. A rede spoke contém sub-redes do sistema AKS e do pool de nós de usuário, juntamente com a sub-rede do Gateway de Aplicativo.

Armazenamento externo e outros componentes

• O Redis Gerenciado do Azure é um serviço gerenciado pelo Azure que fornece um armazenamento de dados na memória de alto desempenho para cache, armazenamento de sessão e acesso a dados em tempo real. Além do cache tradicional, ele inclui suporte para tipos de dados avançados e recursos como armazenamento de documentos JSON, pesquisa de texto completo e vetor e processamento de fluxo. Nessa arquitetura, o microsserviço de entrega usa o Redis Gerenciado do Azure como repositório de estado e cache lateral para melhorar a velocidade e a capacidade de resposta durante o tráfego pesado.

• O Registro de Contêiner é um serviço gerenciado pelo Azure que armazena imagens de contêiner privado para implantação no AKS. Nessa arquitetura, o repositório contém as imagens de contêiner para microsserviços, e o AKS autentica-se com ele usando sua identidade gerenciada do Microsoft Entra. Você também pode usar outros registros, como o Hub do Docker.

• O Azure Cosmos DB é um serviço de banco de dados noSQL, relacional e vetor distribuído globalmente pelo Azure. Nessa arquitetura, o Azure Cosmos DB e o Azure DocumentDB servem como armazenamentos de dados externos para cada microsserviço.

• O Key Vault é um serviço gerenciado pelo Azure que armazena e gerencia com segurança segredos, chaves e certificados. Nessa arquitetura, o Key Vault armazena credenciais que os microsserviços usam para acessar o Azure Cosmos DB e o Azure Managed Redis.

• O Azure Monitor é uma plataforma de observabilidade gerenciada pelo Azure que coleta métricas, logs e telemetria entre serviços. Nessa arquitetura, ela permite o monitoramento do aplicativo, alertas, dashboards e análise de causa raiz para falhas no AKS e serviços integrados.

  A Observabilidade de Rede de Contêiner para Serviços Avançados de Rede de Contêineres usa o Hubble para visibilidade de fluxo e Retina para telemetria de rede selecionada. Essas ferramentas se integram com back-ends de observabilidade gerenciado, como o serviço gerenciado Azure Monitor para Prometheus e o Azure Managed Grafana, para resolução de problemas e relatórios SLO (Objetivo de Nível de Serviço).

• Service Bus é um serviço de mensagens do Azure que dá suporte à comunicação confiável e assíncrona entre aplicativos distribuídos. Nessa arquitetura, o Barramento de Serviço serve como a camada de enfileiramento entre os microsserviços de ingestão e fluxo de trabalho, o que permite a troca de mensagens desacopladas e escalonáveis.

Outras operações dão suporte a componentes do sistema

• O Flux é uma solução de entrega contínua extensível, de código aberto e com suporte do Azure para Kubernetes, que habilita GitOps em AKS. Nessa arquitetura, o Flux automatiza as implantações sincronizando arquivos de manifesto do aplicativo de um repositório Git, o que garante a entrega consistente e declarativa de microsserviços para o cluster do AKS.

• O Helm é um gerenciador de pacotes nativo do Kubernetes que agrupa objetos kubernetes em uma única unidade para publicação, implantação, controle de versão e atualização. Nessa arquitetura, o Helm é usado para empacotar e implantar microsserviços no cluster do AKS.

• O provedor do driver CSI para o armazenamento de segredos do Key Vault é um driver integrado ao Azure para que os clusters do AKS configurem segredos do Key Vault usando volumes CSI. Nessa arquitetura, os segredos são montados diretamente em contêineres de microsserviço, o que permite a recuperação segura de credenciais para o Azure Cosmos DB e o Redis Gerenciado do Azure.

Alternativas

Em vez de usar um complemento de roteamento de aplicativo, você pode utilizar alternativas como o Application Gateway for Containers e o complemento Istio gateway. Para obter uma comparação das opções de entrada no AKS, consulte Entrada no AKS. O Gateway de Aplicação para Contêineres é uma evolução do controlador de ingresso do Gateway de Aplicação e oferece recursos adicionais, como divisão de tráfego e balanceamento de carga round robin ponderado.

Você pode usar o ArgoCD como a ferramenta GitOps em vez de Flux. O Flux e o ArgoCD estão disponíveis como extensões de cluster.

Em vez de armazenar credenciais para o Azure Cosmos DB e o Redis Gerenciado do Azure em cofres de chaves, recomendamos que você use identidades gerenciadas para autenticar porque os mecanismos de autenticação sem senha são mais seguros. Para obter mais informações, consulte Usar identidades gerenciadas para se conectar ao Azure Cosmos DB de uma VM do Azure e autenticar uma identidade gerenciada usando a ID do Microsoft Entra para acessar os recursos do Barramento de Serviço. O Redis Gerenciado do Azure também dá suporte à autenticação usando identidades gerenciadas.

Detalhes do cenário

Nesse exemplo, a Fabrikam, Inc., uma empresa fictícia, gerencia uma frota de drones. Empresas se registram no serviço e os usuários podem solicitar que um drone colete mercadorias para entrega. Quando um cliente agenda uma retirada, o sistema de back-end atribui um drone e notifica o usuário com um tempo de entrega estimado. O cliente pode acompanhar a localização do drone e ver uma hora estimada de chegada continuamente atualizada enquanto a entrega está em andamento.

Recomendações

Você pode aplicar as recomendações a seguir à maioria dos cenários. Siga estas recomendações, a menos que você tenha um requisito específico que as substitua.

Entrada NGINX gerenciada com complemento de roteamento de aplicativo

O Roteamento de Gateway de API é um padrão geral de design de microsserviços. Um gateway de API funciona como um proxy reverso que roteia solicitações de clientes para microsserviços. O recurso de entrada do Kubernetes e o controlador de entrada lidam com a maioria das funcionalidades do gateway de API executando as seguintes ações:

• Roteamento de solicitações de cliente para os serviços de back-end corretos para fornecer um único ponto de extremidade para clientes e ajudar a desacoplar clientes de serviços

• Agregando várias solicitações em uma única solicitação para reduzir as conversas entre o cliente e o back-end

• Funcionalidade de descarregamento, como terminação de SSL (Secure Sockets Layer), autenticação, restrições de endereço IP e limitação de taxa de cliente ou limitação dos serviços de back-end

Os controladores de entrada simplificam a ingestão de tráfego em clusters do AKS, melhoram a segurança e o desempenho e salvam recursos. Essa arquitetura usa a entrada NGINX gerenciada com o complemento de roteamento de aplicativos para controle de entrada.

Recomendamos que você use o controlador de entrada com um endereço IP interno (privado) e um balanceador de carga interno e integre-se às zonas DNS privadas do Azure para resolução de nomes de host de microsserviços. Configure o endereço IP privado ou o nome do host do controlador de entrada como o endereço do pool de back-end no Gateway de Aplicativo. O Gateway de Aplicativo recebe tráfego no ponto de extremidade público, executa inspeções de WAF e roteia o tráfego para o endereço IP privado de entrada.

Configure o controlador de entrada com um nome de domínio personalizado e um certificado SSL para que o tráfego seja criptografado de ponta a ponta. O Gateway de Aplicativo recebe tráfego no ouvinte HTTPS. Após inspeções do WAF, o Gateway de Aplicativo roteia o tráfego para o ponto de extremidade HTTPS do controlador de entrada. Configure todos os microsserviços para usar nomes de domínio personalizados e certificados SSL, que garantem a comunicação entre microsserviços no cluster do AKS.

Cargas de trabalho multilocatários ou um único cluster que dá suporte a ambientes de desenvolvimento e teste podem exigir mais controladores de entrada. O complemento de roteamento de aplicativos dá suporte a configurações e personalizações avançadas, incluindo vários controladores de entrada no mesmo cluster do AKS e usando anotações para configurar recursos de entrada.

Rede e política de rede

Use o CNI do Azure alimentado pelo Cilium. O plano de dados eBPF tem um desempenho de roteamento adequado e dá suporte a qualquer cluster de tamanho. O Cilium impõe nativamente o Kubernetes NetworkPolicy e fornece uma observabilidade de tráfego avançada. Para obter mais informações, consulte Configurar o CNI do Azure alimentado pelo Cilium no AKS.

Para necessidades específicas de gerenciamento de endereço IP, a CNI do Azure alimentada pelo Cilium dá suporte a modelos IP de pod roteados por rede virtual e sobreposição. Para obter mais informações, consulte a CNI do Azure alimentada pelo Cilium.

Políticas de rede de confiança zero

Políticas de rede definem como os pods do AKS se comunicam entre si e com outros endpoints de rede. Por padrão, todo o tráfego de entrada e saída tem permissão para e de pods. Ao projetar como seus microsserviços se comunicam entre si e com outros pontos de extremidade, considere seguir um princípio de confiança zero, em que o acesso a qualquer serviço, dispositivo, aplicativo ou repositório de dados requer configuração explícita. Defina e imponha a NetworkPolicy do Kubernetes (implementada pelo Advanced Container Networking Services/Cilium) para segmentar o tráfego entre microsserviços e restringir a saída a somente os FQDNs permitidos.

Uma estratégia para implementar uma política de confiança zero é criar uma política de rede que nega todo o tráfego de entrada e saída para todos os pods dentro do namespace de destino. O exemplo a seguir mostra uma política de negação que se aplica a todos os pods localizados no backend-dev namespace.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
  namespace: backend-dev
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  ingress:
  - fromEntities: []
  egress:
  - toEntities: []

Depois que uma política restritiva estiver em vigor, comece a definir regras de rede específicas para permitir o tráfego dentro e fora de cada pod no microsserviço. No exemplo a seguir, a política de rede Cilium é aplicada a qualquer pod no backend-dev namespace que tenha um rótulo correspondente app.kubernetes.io/component: backend. A política nega qualquer tráfego, a menos que seja proveniente de um pod que tenha um rótulo correspondente app.kubernetes.io/part-of: dronedelivery.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/part-of: dronedelivery
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

Para obter mais informações sobre políticas de rede do Kubernetes e mais exemplos de possíveis políticas padrão, consulte políticas de rede na documentação do Kubernetes. Para obter as práticas recomendadas para políticas de rede no AKS, consulte Usar políticas de rede no AKS.

Quando você usa o CNI do Azure alimentado pelo Cilium, o Kubernetes NetworkPolicy é imposto pelo Cilium. Para requisitos especializados, o Azure fornece outros mecanismos de política de rede, incluindo o gerenciador de políticas de rede do Azure e o Calico. Recomendamos o Cilium como o mecanismo de política de rede padrão.

Cotas de recursos

Os administradores usam cotas de recursos para reservar e limitar recursos em uma equipe de desenvolvimento ou projeto. Você pode definir cotas de recursos em um namespace e usá-las para definir limites nos seguintes recursos:

• Recursos de computação, como CPUs (unidades de processamento central), GPUs (unidades de processamento de memória e gráficos)

• Recursos de armazenamento, incluindo o número de volumes ou a quantidade de espaço em disco para uma classe de armazenamento específica

• Contagem de objetos, como o número máximo de segredos, serviços ou trabalhos que podem ser criados

Depois que o total cumulativo de solicitações ou limites de recursos passar pela cota atribuída, nenhuma implantação adicional será bem-sucedida.

As cotas de recursos garantem que o conjunto total de pods atribuídos ao namespace não possa exceder a cota de recursos do namespace. O front-end não pode usar todos os recursos para os serviços de back-end e o back-end não pode usar todos os recursos para os serviços front-end.

Quando você define as cotas de recursos, todos os pods criados no namespace devem fornecer limites ou solicitações em suas especificações de pod. Se eles não fornecerem esses valores, a implantação é rejeitada.

O exemplo a seguir mostra uma especificação de pod que define solicitações e limites de cota de recursos:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Para obter mais informações sobre cotas de recursos, consulte os seguintes artigos:

• Impor cotas de recursos
• Cotas de recursos

Dimensionamento automático

O Kubernetes dá suporte ao dimensionamento automático para aumentar o número de pods alocados para uma implantação ou aumentar os nós no cluster para aumentar o total de recursos de computação disponíveis. O dimensionamento automático é um sistema de comentários autônomos autocorretivo. Você pode dimensionar pods e nós manualmente, mas o dimensionamento automático minimiza as chances de os serviços atingirem limites de recursos em cargas altas. Uma estratégia de dimensionamento automático deve considerar pods e nós.

Dimensionamento automático do cluster

A AC (Dimensionador Automático de Cluster) dimensiona o número de nós. Se os pods não puderem ser agendados devido a restrições de recursos, a AC provisionará mais nós. Você define um número mínimo de nós para manter o cluster do AKS e suas cargas de trabalho operacionais e um número máximo de nós para tráfego pesado. A AC verifica a cada poucos segundos se há pods pendentes ou nós vazios e dimensiona o cluster do AKS adequadamente.

O exemplo a seguir mostra a configuração de AC do modelo Bicep do cluster:

autoScalerProfile: {
  'scan-interval': '10s'
  'scale-down-delay-after-add': '10m'
  'scale-down-delay-after-delete': '20s'
  'scale-down-delay-after-failure': '3m'
  'scale-down-unneeded-time': '10m'
  'scale-down-unready-time': '20m'
  'scale-down-utilization-threshold': '0.5'
  'max-graceful-termination-sec': '600'
  'balance-similar-node-groups': 'false'
  expander: 'random'
  'skip-nodes-with-local-storage': 'true'
  'skip-nodes-with-system-pods': 'true'
  'max-empty-bulk-delete': '10'
  'max-total-unready-percentage': '45'
  'ok-total-unready-count': '3'
}

As seguintes linhas no modelo Bicep definem o exemplo de nós mínimos e máximos para a AC:

minCount: 2
maxCount: 5

Dimensionamento horizontal automático de pod

O HPA (Dimensionador Automático de Pod Horizontal) dimensiona pods com base em CPU, memória ou métricas personalizadas observadas. Para configurar o dimensionamento horizontal do pod, especifique as métricas de destino e o número mínimo e máximo de réplicas na especificação do pod de implantação do Kubernetes. Teste de carga de seus serviços para determinar esses números.

A AC e o HPA funcionam juntos, portanto, habilite ambas as opções de dimensionamento automático no cluster do AKS. O HPA dimensiona o aplicativo, enquanto a AC dimensiona a infraestrutura.

O exemplo a seguir define as métricas de recurso para o HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

O HPA analisa os recursos reais consumidos ou outras métricas da execução de pods. A AC provisiona nós para pods que ainda não estão agendados. Como resultado, a AC examina os recursos solicitados, conforme especificado na especificação do pod. Use o teste de carga para ajustar esses valores.

Para obter mais informações, consulte opções de dimensionamento para aplicativos no AKS.

Dimensionamento automático de pod vertical

O VPA (Dimensionador Automático de Pod Vertical) ajusta automaticamente as solicitações de CPU e memória para seus pods para corresponder aos padrões de uso de suas cargas de trabalho. Quando ele é configurado, o VPA define automaticamente solicitações de recursos e limites em contêineres para cada carga de trabalho com base no uso anterior. A VPA disponibiliza CPU e memória para outros pods e ajuda a garantir a utilização efetiva dos clusters do AKS.

Nessa arquitetura, o VPA aumenta as solicitações de CPU e memória e os limites para microsserviços com base em seu uso anterior. Por exemplo, se o microsserviço de fluxo de trabalho consumir mais CPU em comparação com outros microsserviços, o VPA poderá monitorar esse uso e aumentar os limites de CPU para o microsserviço de fluxo de trabalho.

Dimensionamento automático orientado por eventos do Kubernetes

O complemento KEDA (Kubernetes Event-Driven Autoscaling) permite que o dimensionamento automático controlado por eventos dimensione seu microsserviço para atender à demanda de maneira sustentável e econômica. Por exemplo, o KEDA pode escalar microsserviços verticalmente quando o número de mensagens na fila do Barramento de Serviço ultrapassar limites específicos.

No cenário de entrega de drones da Fabrikam, o KEDA dimensiona o microsserviço de fluxo de trabalho dependendo da profundidade da fila do Barramento de Serviço e com base na saída do microsserviço de ingestão. Para obter uma lista de dimensionadores KEDA para serviços do Azure, consulte Integrações com KEDA no AKS.

Investigações de integridade

A carga do Kubernetes balanceia o tráfego para pods que correspondem a um seletor de rótulo para um serviço. Somente os pods que iniciam com êxito e são saudáveis recebem tráfego. Em caso de falha de um contêiner, o Kubernetes remove o pod e agenda uma substituição. O Kubernetes define três tipos de investigações de integridade que um pod pode expor:

• A investigação de preparação informa ao Kubernetes se o pod está pronto para aceitar solicitações.

• A investigação de atividade informa ao Kubernetes se um pod deve ser removido e uma nova instância iniciada.

• A investigação de inicialização informa ao Kubernetes se o pod foi iniciado.

As investigações de atividade lidam com pods que ainda estão em execução, mas não estão íntegros e devem ser reciclados. Por exemplo, se um contêiner que atende solicitações HTTP for travado, o contêiner não falhará, mas interromperá o atendimento de solicitações. A investigação de atividade HTTP para de responder, o que alerta o Kubernetes para reiniciar o pod.

Às vezes, um pod pode não estar pronto para receber tráfego, ainda que o pod seja iniciado com êxito. Por exemplo, o aplicativo executado no contêiner pode estar executando tarefas de inicialização. A investigação de preparação indica se o pod está pronto para receber tráfego.

Os microsserviços devem expor pontos de extremidade em seu código que facilitam investigações de integridade, com atraso e tempo limite personalizados especificamente para as verificações executadas. A fórmula HPA depende da fase pronta do pod, portanto, é crucial que as investigações de integridade existam e sejam precisas.

Monitoramento

O monitoramento é essencial em uma arquitetura de microsserviços para detectar anomalias, diagnosticar problemas e entender as dependências de serviço. O Application Insights, parte do Azure Monitor, fornece APM (monitoramento de desempenho de aplicativos) para aplicativos escritos em .NET, Node.js, Java e muitos outros idiomas. O Azure fornece vários recursos integrados para visibilidade de ponta a ponta:

• O serviço gerenciado do Azure Monitor para Prometheus coleta e alertas sobre métricas de infraestrutura e carga de trabalho.

• O recurso Live Data no Container Insights monitora clusters, nós e contêineres do AKS para integridade e uso de recursos.

• O Grafana Gerenciado do Azure visualiza métricas e dashboards para clusters e microserviços.

A observabilidade dos Serviços Avançados de Rede de Contêineres complementa essas ferramentas ao fornecer visibilidade profunda, baseada em eBPF, no comportamento da rede de clusters de AKS. Ele captura latência DNS, fluxos de pod para pod e serviço, quedas de política de rede e métricas de protocolo de nível 7, como códigos de status HTTP e tempos de resposta. Essa telemetria se integra ao serviço gerenciado do Azure Monitor do Prometheus para métricas e ao Grafana Gerenciado do Azure para o monitoramento por meio de dashboards. O plano de dados Cilium eBPF fornece visibilidade e solução de problemas no nível do fluxo. Quando combinado com os Serviços Avançados de Rede de Contêineres e o Azure Monitor, essa funcionalidade oferece observabilidade de rede de ponta a ponta. Essa integração permite a detecção de gargalos de rede, configurações incorretas de política e problemas de comunicação que o APM tradicional pode perder.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design parade segurança.

Considere os seguintes pontos ao planejar a segurança:

• Use proteções de implantação no cluster do AKS. A implantação de medidas de segurança impõem as melhores práticas do Kubernetes em seu cluster do AKS por meio dos controles do Azure Policy.

• Integre a verificação de segurança aos pipelines de build e implantação de microsserviços. Gerencie seu ambiente de DevOps usando a segurança do Microsoft Defender para Cloud DevOps. Use a verificação de código sem agente e execute ferramentas de análise de código estático como parte de pipelines de CI/CD (integração contínua e implantação contínua) para que você possa identificar e resolver as vulnerabilidades de código de microsserviço como parte dos processos de build e implantação.

• Um pod do AKS se autentica usando uma identidade de carga de trabalho armazenada na ID do Microsoft Entra. Você deve usar uma identidade de carga de trabalho porque ela não requer um segredo do cliente.

• Quando você usa identidades gerenciadas, o aplicativo pode obter rapidamente tokens OAuth 2.0 do Azure Resource Manager quando ele é executado. Ele não precisa de senhas ou cadeias de conexão. No AKS, você pode atribuir identidades a pods individuais usando a ID da Carga de Trabalho.

• Cada serviço no aplicativo de microsserviço deve receber uma identidade de carga de trabalho exclusiva para facilitar atribuições de RBAC do Azure com privilégios mínimos. Atribua apenas identidades a serviços que exigem elas.

• Nos casos em que um componente de aplicativo requer acesso à API do Kubernetes, verifique se os pods de aplicativo estão configurados para usar uma conta de serviços com acesso à API com escopo apropriado. Para obter mais informações, consulte Gerenciar contas de serviço do Kubernetes.

• Nem todos os serviços do Azure dão suporte à ID do Microsoft Entra para autenticação de plano de dados. Para armazenar credenciais ou segredos de aplicativo para esses serviços, para serviços que não são da Microsoft ou para chaves de API, use o Key Vault. Ele fornece gerenciamento centralizado, controle de acesso, criptografia em repouso e auditoria para todas as chaves e segredos.

• No AKS, você pode montar um ou mais segredos do Key Vault como um volume. O pod, em seguida, pode ler os segredos do Key Vault como um volume normal. Para obter mais informações, consulte Usar o provedor do Key Vault para o Driver CSI do Repositório de Segredos em um cluster do AKS. Recomendamos que você mantenha cofres de chaves separados para cada microsserviço.

Os Serviços Avançados de Rede de Contêiner fornecem segmentação de rede no cluster e controles de confiança zero para clusters do AKS. Use políticas de rede Cilium no CNI do Azure alimentado pelo Cilium para implementar a segmentação de camada 3 e camada 4 dentro do cluster. A segurança avançada dos Serviços de Rede de Contêineres estende essa base adicionando funcionalidades avançadas:

• Filtragem de saída baseada em FQDN para restringir o tráfego de saída a domínios aprovados.

• Políticas com reconhecimento de nível 7 para protocolos como HTTP e gRPC Remote Procedure Call (gRPC) para validar e controlar a comunicação no nível do aplicativo.

• Criptografia WireGuard para proteger o tráfego pod-to-pod e proteger dados confidenciais em trânsito.

  Esses recursos funcionam juntamente com defesas de perímetro, como NSGs (grupos de segurança de rede) e Firewall do Azure para fornecer uma abordagem de segurança em camadas que impõe o controle de tráfego de dentro do cluster.

• Se o microsserviço precisar se comunicar com recursos, como URLs externas fora do cluster, controle o acesso por meio do Firewall do Azure. Se o microsserviço não precisar fazer chamadas de saída, use clusters isolados de rede.

• Habilite o Microsoft Defender para Contêineres para fornecer gerenciamento de postura de segurança, avaliação de vulnerabilidade para microsserviços, proteção contra ameaças de runtime e outros recursos de segurança.

Plano de dados de rede e mecanismos de política

Atualmente, o Cilium no AKS tem suporte para nós Linux e aplica a política de rede no plano de dados. Lembre-se de advertências de política, como ipBlock relacionado ao uso de endereços IP de nó e endereços IP de pod e que pods com rede de host utilizam uma identidade de host. Políticas no nível de pod não se aplicam. Alinhe as versões do AKS e do Cilium com a matriz de versão com suporte. Para obter mais informações, consulte limitações do Azure CNI, impulsionado pelo Cilium.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design parade Otimização de Custos.

• A seção Otimização de Custos no Well-Architected Framework descreve as considerações de custo.

• Use a calculadora de preços do Azure para estimar os custos para seu cenário específico.

• Na camada Gratuita, o AKS não tem custos associados à implantação, gerenciamento e operações do cluster kubernetes. Você paga apenas pelas instâncias de VM, armazenamento e recursos de rede que o cluster consome. O dimensionamento automático do cluster pode reduzir significativamente o custo do cluster removendo nós vazios ou não utilizados.

• Considere usar a camada gratuita do AKS para cargas de trabalho de desenvolvimento e use as camadas Standard e Premium para cargas de trabalho de produção.

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

Excelência Operacional

A Excelência Operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design parade Excelência Operacional.

Considere os seguintes pontos ao planejar a capacidade de gerenciamento:

• Gerencie a infraestrutura de cluster do AKS por meio de um pipeline de implantação automatizado, como fluxos de trabalho do GitHub Actions .

• O arquivo de fluxo de trabalho implanta a infraestrutura somente, não a carga de trabalho, na rede virtual já existente e na configuração do Microsoft Entra. Implantar a infraestrutura e a carga de trabalho separadamente permite que você resolva diferentes preocupações operacionais e de ciclo de vida.

• Considere seu fluxo de trabalho como um mecanismo para implantar em outra região se houver uma falha regional. Crie o pipeline para que você possa implantar um novo cluster em uma nova região com alterações de parâmetro e de entrada.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da carga de trabalho de dimensionar para atender às demandas do usuário com eficiência. Para obter mais informações, consulte Lista de verificação de design parade Eficiência de Desempenho.

Considere os seguintes pontos ao planejar a escalabilidade:

• Não combine o dimensionamento automático e o gerenciamento imperativo ou declarativo do número de réplicas. Se os usuários e um dimensionador automático tentarem alterar o número de réplicas, um comportamento inesperado poderá ocorrer. Quando o HPA estiver habilitado, reduza o número de réplicas para o número mínimo que você deseja implantar.

• Um efeito colateral do dimensionamento automático do pod é que os pods podem ser criados ou removidos com frequência quando o aplicativo é escalado ou escalado horizontalmente. Para atenuar esses efeitos, execute as seguintes ações:

  • Use investigações de preparação para que o Kubernetes saiba quando um novo pod está pronto para aceitar tráfego.

  • Use os orçamentos de interrupção de pod para limitar quantos pods podem ser removidos de um serviço de cada vez.

• Se houver um grande número de fluxos de saída do microsserviço, considere usar gateways NAT (tradução de endereço de rede) para evitar o esgotamento da porta SNAT (tradução de endereço de rede de origem).

• Multilocatário ou outras cargas de trabalho avançadas podem ter requisitos de isolamento de pool de nós que exigem mais e provavelmente sub-redes menores. Para obter mais informações, consulte Adicionar pools de nós que têm sub-redes exclusivas. As organizações têm padrões diferentes para suas implementações hub-spoke. Certifique-se de seguir suas diretrizes organizacionais.

• Considere usar o CNI do Azure com rede de sobreposição para conservar o espaço de endereço de rede.

Próximas etapas

• Introdução ao AKS
• O que é Rede Virtual?
• O que é o Link Privado?
• O que é o Gateway de Aplicativo?
• O que é o Azure Bastion?
• Introdução ao Key Vault
• Introdução ao Registro de Contêiner
• Visão geral do Azure Monitor
• Serviços avançados de rede de contêineres

Recursos relacionados

• Arquitetura padrão para um cluster do AKS
• Projetar, compilar e operar microsserviços no Azure com o Kubernetes
• Arquitetura de microsserviços no AKS
• Criar um pipeline de CI/CD para microsserviços no Kubernetes