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

Gateway de Aplicativo do Azure
Registro de Contêiner do Azure
AKS (Serviço de Kubernetes do Azure)
Rede Virtual do Azure

Essa arquitetura de referência detalha várias configurações a serem consideradas ao executar microsserviços nos Serviços de Kubernetes do Azure. Os tópicos incluem a configuração de políticas 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 da linha de base do AKS, o ponto de partida recomendado pela Microsoft para a infraestrutura do Azure Kubernetes Service (AKS). A linha de base do AKS detalha recursos de infraestrutura como o Microsoft Entra Workload ID, restrições de entrada e saída, limites de recursos e outras configurações seguras de infraestrutura do AKS. Esses detalhes infraestruturais não são abordados neste documento. É recomendável que você se familiarize com a linha de base do AKS antes de prosseguir com o conteúdo de microsserviços.

Logotipo do GitHub Uma implementação de referência desta arquitetura está disponível no GitHub.

Arquitetura

Diagrama de rede mostrando a rede hub-spoke com duas redes virtuais emparelhadas e os recursos do Azure usados por essa implementação.

Baixe um Arquivo Visio dessa arquitetura.

Se você preferir começar com um exemplo de microsserviços mais básico no AKS, confira 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 mensagens prossegue da seguinte maneira:

  1. Uma solicitação HTTPS é enviada para agendar uma retirada de drone. As solicitações passam 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.

  3. O sistema de back-end atribui um drone e notifica o usuário. O fluxo de trabalho:

    • Consome informações de mensagem da fila de mensagens do Barramento de Serviço.
    • Envia uma solicitação HTTPS para o microsserviço de entrega, que transmite dados para o armazenamento de dados externo do Cache do Azure para Redis.
    • 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 transmite dados para o armazenamento de dados externo do MongoDB.

  4. Uma solicitação HTTPS GET é usada 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 Cache do Azure para Redis.

Componentes

Essa arquitetura usa os seguintes componentes do Azure:

Serviço de Kubernetes do Azure é uma oferta do Azure que fornece um cluster do Kubernetes gerenciado. Ao usar o AKS, o servidor de API do Kubernetes é gerenciado pelo Azure. Os nós do Kubernetes ou os pools de nós são acessíveis e podem ser gerenciados pelo operador de cluster.

Os recursos de infraestrutura do AKS usados nessa arquitetura incluem:

As Redes Virtuais do Azure são ambientes isolados e altamente seguros para executar máquinas virtuais (VMs) e aplicativos. Essa arquitetura de referência usa uma topologia de rede virtual hub-spoke emparelhada. A rede virtual do hub contém o firewall do Azure e as sub-redes do Azure Bastion. A rede virtual spoke contém as sub-redes do sistema AKS e do pool de nós de usuário e a sub-rede Gateway de Aplicativo do Azure.

O Link Privado do Azure aloca endereços IP privados específicos para acessar Registro de Contêiner do Azure e Key Vault de Pontos de Extremidade Privados dentro do sistema AKS e da sub-rede do pool de nós de usuário.

O Gateway de Aplicativo do Azure com o WAF (firewall do aplicativo Web) expõe as rotas HTTP(S) para o cluster do AKS e balanceia a carga do tráfego da Web para o aplicativo Web. Essa arquitetura usa o AGIC (Controlador de Entrada do Gateway de Aplicativo do Azure) como o controlador de entrada do Kubernetes.

O Azure Bastion fornece acesso seguro de protocolo RDP (protocolo de área de trabalho remota) e SSH (secure shell) a VMs nas redes virtuais usando uma SSL (camada de soquete seguro), sem a necessidade de expor as VMs por meio de endereços IP públicos.

O Firewall do Azure é um serviço de segurança de rede que protege todos os recursos da Rede Virtual do Azure. O firewall permite apenas serviços aprovados e FQDNs (nomes de domínio totalmente qualificados) como tráfego de saída.

Armazenamento externo e outros componentes:

O Azure Key Vault armazena e gerencia chaves de segurança para serviços do AKS.

O Registro de Contêiner do Azure armazena imagens de contêiner privadas que podem ser executadas no cluster do AKS. O AKS se autentica com o Registro de Contêiner utilizando a sua identidade gerenciada pelo Microsoft Entra. Também é possível usar outros registros de contêiner, como o Docker Hub.

O Azure Cosmos DB armazena dados usando o código aberto Azure Cosmos DB for MongoDB. Os microsserviços são normalmente sem estado e gravam o estado em armazenamentos de dados externos. O Azure Cosmos DB é um serviço de banco de dados NoSQL com APIs de código aberto para MongoDB e Cassandra.

O Barramento de Serviço do Azure fornece mensagens de nuvem como serviço confiáveis e integração híbrida simples. O Barramento de Serviço dá suporte a padrões de mensagens assíncronas que são comuns com aplicativos de microsserviços.

O Cache do Azure para Redis adiciona uma camada de cache à arquitetura do aplicativo para melhorar a velocidade e o desempenho para cargas de tráfego pesadas.

O Azure Monitor coleta e armazena métricas e logs, incluindo telemetria de aplicativo e métrica de serviço e plataforma do Azure. Você pode usar esses dados para monitorar o aplicativo, configurar alertas e painéis e executar a análise da causa raiz de falhas.

Outros componentes do sistema de suporte a operações (OSS):

Helm, um gerenciador de pacotes para Kubernetes que agrupa objetos Kubernetes em uma única unidade que você pode publicar, implantar, atualizar e controlar a versão.

O provedor CSI do Repositório Secreto do Azure Key Vault obtém segredos armazenados no Azure Key Vault e usa a interface do driver CSI da Loja Secreta para montá-los em pods do Kubernetes.

Flux, uma solução de entrega contínua aberta e extensível para Kubernetes, alimentada pelo GitOps Toolkit.

Detalhes do cenário

O exemplo do aplicativo de entrega por drone da Fabrikam, mostrado no diagrama anterior, implementa os componentes e as práticas de arquitetura discutidos neste artigo. 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 coleta, um sistema de back-end atribui um drone ao usuário e notifica-o com um tempo de entrega previsto. Enquanto a entrega está em andamento, o cliente pode acompanhar a localização do drone, com um ETA atualizado continuamente.

Possíveis casos de uso

Esta solução é ideal para as indústrias aeronáutica, aeroespacial e de aviação.

Recomendações

Implemente essas recomendações ao implantar arquiteturas avançadas de microsserviços do AKS.

AGIC (Controlador de Entrada do Gateway de Aplicativo)

O Roteamento de Gateway de API é um padrão geral de design de microsserviços. Um gateway de API atua 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:

O roteamento de solicitações de cliente para os serviços de back-end corretos fornece um único ponto de extremidade para clientes e ajuda a separar clientes dos serviços.

  • Agregação de várias solicitações em uma única solicitação para reduzir conversas entre o cliente e o back-end.
  • Funcionalidade de descarregamento, como terminação de SSL, autenticação, restrições de IP e limitação de taxa de cliente dos serviços de back-end.

O estado do cluster AKS é convertido na configuração específica do gateway de aplicativo e aplicado ao Azure Resource Manager (ARM).

Os controladores de entrada externos simplificam a ingestão de tráfego em clusters do AKS, melhoram a segurança e o desempenho e salvam recursos. Essa arquitetura usa o AGIC (Controlador de Entrada do Gateway de Aplicativo do Azure) para controle de entrada. Usar o Gateway de Aplicativo para lidar com todo o tráfego elimina a necessidade de um balanceador de carga extra. Como os pods estabelecem conexões diretas com o Gateway de Aplicativo, o número de saltos necessários é reduzido, o que resulta em um melhor desempenho.

O Gateway de Aplicativo tem recursos internos de dimensionamento automático, ao contrário dos controladores de entrada no cluster que devem ser dimensionados, se consumirem uma quantidade indesejada de recursos de computação. O Gateway de Aplicativo pode executar roteamento de camada 7 e terminação SSL e tem TLS (Segurança de Camada de Transporte) de ponta a ponta integrado a um WAF (firewall de aplicativo Web) interno.

Para a opção de entrada do AGIC, você deve habilitar a rede CNI ao configurar o cluster do AKS porque o Gateway de Aplicativo é implantado em uma sub-rede da rede virtual 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.

Políticas de rede de confiança zero

As políticas de rede especificam como os pods do AKS têm permissão para se comunicar entre si e com outros pontos de extremidade 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.

Uma estratégia na implementação de 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 de tudo que se aplicaria a todos os pods localizados no namespace back-end-dev.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Para obter mais informações sobre políticas de rede do Kubernetes e exemplos adicionais de possíveis políticas padrão, confira Políticas de Rede na documentação do Kubernetes.

Cotas de recursos

As cotas de recursos são uma maneira de os administradores reservarem e limitarem recursos em uma equipe de desenvolvimento ou um projeto. Você pode definir cotas de recursos em um namespace e usá-las para definir limites em:

  • Recursos de computação, como CPU e memória ou GPUs.
  • Recursos de armazenamento, incluindo o número total de volumes ou 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 do total acumulado de solicitações de recursos ou limites passa a cota atribuída, não há outras implantações bem-sucedidas.

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 enfraquecer os serviços de back-end por causa de recursos ou vice-versa.

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, confira:

Dimensionamento automático

O Kubernetes dá suporte ao dimensionamento automático para aumentar o número de pods alocados a 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. Embora você possa dimensionar pods e nós manualmente, o dimensionamento automático minimiza as chances de os serviços ficarem sem recursos em cargas altas. Uma estratégia de dimensionamento automático precisa levar em consideração pods e nós.

Dimensionamento automático do cluster

O CA (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, o dimensionador automático de cluster 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 da AC do modelo do ARM:

"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 do ARM definem os nós mínimos e máximos de exemplo para a AC:

"minCount": 2,
"maxCount": 5,

Dimensionamento automático de pods

O HPA (Dimensionador Automático de Pod Horizontal) dimensiona os pods com base em métricas personalizadas, memória ou CPU 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 a carga dos serviços para determinar esses números.

Como a AC e o HPA funcionam bem juntos, habilite ambas as opções de dimensionamento automático no seu 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/v2beta2
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
        targetAverageUtilization: 60

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

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 foram iniciados com êxito e estão íntegros recebem tráfego. Em caso de falha de um contêiner, o Kubernetes remove o pod e agenda uma substituição.

No Kubernetes, um pod pode expor dois tipos de investigação de integridade:

  • A investigação de atividade informa ao Kubernetes se um pod começou com êxito e está íntegro.
  • A investigação de preparação informa ao Kubernetes se o pod está pronto para aceitar solicitações.

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 deixará de atender às solicitações. A investigação de atividade HTTP para de responder, o que informa o Kubernetes para reiniciar o pod.

Às vezes, um pod pode não estar pronto para receber tráfego, mesmo que tenha sido iniciado com êxito. Por exemplo, o aplicativo em execução 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 adaptados especificamente às verificações executadas. Como a fórmula do HPA usa como base quase exclusivamente a fase Pronto em um pod, é fundamental que as investigações de integridade existam e sejam precisas.

Monitoramento

Em um aplicativo de microsserviços, o monitoramento do APM (Gerenciamento de Desempenho de Aplicativos) é essencial para detectar anomalias, diagnosticar problemas e entender rapidamente as dependências entre os serviços. O Application Insights, que faz parte do Azure Monitor, fornece monitoramento do APM para aplicativos dinâmicos escritos em .NET Core, Node.js, Java e muitas outras linguagens de aplicativo.

Application Insights:

  • Registra solicitações HTTP, incluindo latência e código de resultado.
  • Habilita o rastreamento distribuído por padrão.
  • Inclui uma ID de operação em rastreamentos, para que você possa corresponder a todos os rastreamentos de uma operação específica.
  • Geralmente inclui informações contextuais adicionais em rastreamentos.

Para contextualizar a telemetria de serviços com o mundo do Kubernetes, integre a telemetria do Azure Monitor ao AKS para coletar métricas de controladores, nós e contêineres, bem como logs de contêineres e nós. Se você estiver usando o .NET, a biblioteca do Application Insights para Kubernetes enriquece a telemetria do Application Insights com informações de imagem, contêiner, nó, pod, rótulo e conjunto de réplicas.

O diagrama a seguir mostra um exemplo do mapa de dependência do aplicativo gerado pelo Application Insights para um rastreamento de telemetria de microsserviços do AKS:

Exemplo de um mapa de dependência do Application Insights para um aplicativo de microsserviços do AKS.

Para obter mais informações sobre as opções de instrumentação de linguagens comuns para integração do Application Insights, confira Monitoramento de aplicativos para Kubernetes.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Escalabilidade

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. Os usuários e um dimensionador automático que tentam modificar o número de réplicas podem causar um comportamento inesperado. 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 frequentemente, de acordo com os eventos de expansão e redução horizontal ocorridos. Para atenuar esses efeitos:

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

  • Como não é possível mudar o tamanho da VM depois de criar um cluster, faça um planejamento da capacidade inicial para escolher um tamanho de VM adequado para os nós de agente ao criar o cluster.

  • 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 sobre como criar pools de nós com sub-redes exclusivas, confira Adicionar um pool de nós com uma sub-rede exclusiva. As organizações têm padrões diferentes para suas implementações hub-spoke. Certifique-se de seguir suas diretrizes organizacionais.

Capacidade de gerenciamento

Considere os seguintes pontos ao planejar o gerenciamento.

  • Gerencie a infraestrutura de cluster do AKS por meio de um pipeline de implantação automatizado. A implementação de referência para essa arquitetura fornece um fluxo de trabalho GitHub Actions que você pode referenciar ao criar seu pipeline.

  • 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 resolver preocupações operacionais e de ciclo de vida distintas.

  • Considere o 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 entrada.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Considere os seguintes pontos ao planejar a segurança.

  • Um pod AKS se autentica usando uma identidade de carga de trabalho armazenada no Microsoft Entra ID. Usar uma identidade de carga de trabalho é preferível porque ela não requer um segredo do cliente.

  • Com identidades gerenciadas, o processo de execução pode rapidamente obter tokens do Azure Resource Manager OAuth 2.0. Não há necessidade de senhas ou cadeias de conexão. No AKS, você pode atribuir identidades a pods individuais usando o Microsoft Entra Workload ID.

  • Cada serviço no aplicativo de microsserviço deve receber uma identidade de carga de trabalho exclusiva para facilitar atribuições RBAC menos privilegiadas. Você só deve atribuir identidades a serviços que as exigem.

  • 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 sobre como configurar e gerenciar a conta de serviços do Kubernetes, confira Como gerenciar contas de serviço do Kubernetes.

  • Nem todos os serviços do Azure dão suporte à autenticação de plano de dados usando o Microsoft Entra ID. Para armazenar credenciais ou segredos de aplicativo para esses serviços, para serviços de terceiros ou para chaves de API, use o Azure Key Vault. O Azure Key Vault fornece gerenciamento centralizado, controle de acesso, criptografia inativa e auditoria de 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, confira o projeto secrets-store-csi-driver-provider-azure no GitHub.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Próximas etapas