Editar

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

Azure Application Gateway
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Virtual Network

Esta arquitetura de referência detalha várias configurações a serem consideradas ao executar microsserviços nos Serviços Kubernetes do Azure. Os tópicos incluem a configuração de políticas de rede, dimensionamento automático de pods e rastreamento distribuído em um aplicativo baseado em microsserviços.

Esta arquitetura baseia-se na arquitetura AKS Baseline , o ponto de partida recomendado pela Microsoft para a infraestrutura AKS. A linha de base do AKS detalha recursos de infraestrutura, como 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. Estes pormenores infraestruturais não são abordados no presente documento. É recomendável que você se familiarize com a linha de base do AKS antes de prosseguir com o conteúdo dos microsserviços.

GitHub logo Uma implementação de referência dessa arquitetura está disponível no GitHub.

Arquitetura

Network diagram showing the hub-spoke network with two peered virtual networks and the Azure resources this implementation uses.

Transfira um ficheiro do Visio desta arquitetura.

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

Fluxo de Trabalho

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 forma:

  1. Uma solicitação HTTPS é enviada para agendar uma coleta 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 em cluster no AKS.

  2. O aplicativo Web de ingestão produz uma mensagem e a envia para a fila de mensagens do Service Bus.

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

    • Consome informações de mensagens da fila de mensagens do Service Bus.
    • Envia uma solicitação HTTPS para o microsserviço de Entrega, que passa dados para o Cache do Azure para armazenamento de dados externos Redis.
    • Envia uma solicitação HTTPS para o microsserviço Drone Scheduler.
    • Envia uma solicitação HTTPS para o microsserviço Package, que passa 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 Application Gateway 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:

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

Os recursos de infraestrutura AKS usados nesta 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 do usuário e a sub-rede do Gateway de Aplicativo do Azure.

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

O Gateway de Aplicativo do Azure com firewall de aplicativo Web (WAF) expõe rotas HTTP(S) para o cluster AKS e equilibra a carga do tráfego da Web para o aplicativo Web. Essa arquitetura usa o Azure Application Gateway Ingress Controller (AGIC) como o controlador de ingresso do Kubernetes.

O Azure Bastion fornece acesso seguro ao protocolo de área de trabalho remota (RDP) e ao shell seguro (SSH) para VMs nas redes virtuais usando uma camada de soquete segura (SSL), 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 AKS.

O Registro de Contêiner do Azure armazena imagens de contêiner privado que podem ser executadas no cluster AKS. O AKS autentica-se com o Registo de Contentores utilizando a sua identidade gerida pelo Microsoft Entra. Você também pode usar outros registros de contêiner, como o Docker Hub.

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

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

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

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

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

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

O provedor CSI do Azure Key Vault Secret Store, obtém segredos armazenados no Azure Key Vault e usa a interface do driver CSI do Secret Store 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 Fabrikam Drone Delivery Shipping App mostrado no diagrama anterior implementa os componentes arquitetônicos e as práticas discutidas neste artigo. Neste exemplo, a Fabrikam, Inc., uma empresa fictícia, gere uma frota de aviões drones. As empresas registam-se nos serviços e os utilizadores podem requisitar um drone que venha recolher os bens para entrega. Quando um cliente agenda uma recolha, o sistema de back-end atribui um drone e notifica o utilizador com um tempo de entrega estimado. Enquanto a entrega está em andamento, o cliente pode rastrear a localização do drone com uma ETA continuamente atualizada.

Potenciais casos de utilização

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

Recomendações

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

Controlador de Ingresso do Application Gateway (AGIC)

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 clientes para os serviços de back-end corretos fornece um único ponto de extremidade para os clientes e ajuda a separar os clientes dos serviços.

  • Agregando várias solicitações em uma única solicitação para reduzir a conversa entre o cliente e o back-end.
  • Descarregando funcionalidades como terminação SSL, autenticação, restrições de IP e limitação ou limitação de taxa de cliente dos serviços de back-end.

O estado do cluster AKS é traduzido para a configuração específica do Application Gateway e aplicado por meio do Azure Resource Manager.

Os controladores de entrada externos simplificam a ingestão de tráfego em clusters AKS, melhoram a segurança e o desempenho e economizam recursos. Essa arquitetura usa o Azure Application Gateway Ingress Controller (AGIC) para controle de entrada. Usar o Application Gateway 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 Application Gateway, o número de saltos necessários é reduzido, o que resulta em melhor desempenho.

O Application Gateway tem recursos internos de dimensionamento automático, ao contrário dos controladores de entrada em cluster que devem ser dimensionados se consumirem uma quantidade indesejada de recursos de computação. O Application Gateway pode executar roteamento de camada 7 e terminação SSL e tem TLS (Transport Layer Security) de ponta a ponta integrado com um firewall de aplicativo da Web (WAF) integrado.

Para a opção de entrada AGIC, você deve habilitar a rede CNI ao configurar o cluster AKS porque o Application Gateway é implantado em uma sub-rede da rede virtual AKS. Cargas de trabalho multilocatário, ou um único cluster que ofereça 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 AKS podem se comunicar entre si e com outros pontos de extremidade de rede. Por padrão, todo o tráfego de entrada e saída é permitido de e para pods. Ao projetar como seus microsserviços se comunicam entre si e com outros endpoints, 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 negue todo o tráfego de entrada e saída para todos os pods dentro do namespace de destino. O exemplo a seguir mostra uma 'deny all policy' que se aplicaria a todos os pods localizados no namespace backend-dev.

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

Quando uma política restritiva estiver em vigor, comece a definir regras de rede específicas para permitir o tráfego de entrada e saída de cada pod no microsserviço. No exemplo a seguir, a diretiva de rede é aplicada a qualquer pod no namespace backend-dev com um rótulo que corresponde a app.kubernetes.io/component: backend. A política nega qualquer tráfego, a menos que seja proveniente 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, consulte Políticas de rede na documentação do Kubernetes.

Quotas de recursos

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

  • Recursos de computação, como CPU e memória, ou GPUs.
  • Recursos de armazenamento, incluindo o número de volumes ou a quantidade de espaço em disco para uma determinada classe de armazenamento.
  • Contagem de objetos, como o número máximo de segredos, serviços ou trabalhos que podem ser criados.

Depois que o total acumulado de solicitações ou limites de recursos ultrapassar a cota atribuída, nenhuma outra implantação 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 privar os serviços de back-end de recursos ou vice-versa.

Quando você define 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 será 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:

Dimensionamento automático

O Kubernetes suporta 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 feedback autônomo 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 altas cargas. Uma estratégia de dimensionamento automático deve levar em conta pods e nós.

Dimensionamento automático de cluster

O autoscaler (CA) do cluster dimensiona o número de nós. Suponha que os pods não podem ser agendados devido a restrições de recursos; O AutoScaler do cluster provisiona mais nós. Você define um número mínimo de nós para manter o cluster AKS e suas cargas de trabalho operacionais e um número máximo de nós para tráfego pesado. A autoridade de certificação verifica a cada poucos segundos se há pods pendentes ou nós vazios e dimensiona o cluster AKS adequadamente.

O exemplo a seguir mostra a configuração da autoridade de certificação do modelo 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 ARM definem exemplos de nós mínimos e máximos para a autoridade de certificação:

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

Dimensionamento automático de pods

O Horizontal Pod Autoscaler (HPA) 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 seus serviços para determinar esses números.

A CA e a HPA funcionam bem juntas, portanto, habilite ambas as opções de escalonamento automático em seu cluster AKS. A HPA dimensiona o aplicativo, enquanto a CA dimensiona a infraestrutura.

O exemplo a seguir define métricas de recursos para 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

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

Sondas do estado de funcionamento

O Kubernetes equilibra a carga do tráfego para pods que correspondem a um seletor de rótulo para um serviço. Apenas os pods que começaram com sucesso e estão saudáveis recebem tráfego. Se um contêiner falhar, o Kubernetes removerá o pod e agendará uma substituição.

No Kubernetes, um pod pode expor dois tipos de sonda de integridade:

  • A sonda liveness informa ao Kubernetes se um pod começou com sucesso e está saudável.
  • O teste de prontidão informa ao Kubernetes se um pod está pronto para aceitar solicitações.

As sondas de vivacidade lidam com cápsulas que ainda estão funcionando, mas não são saudáveis e devem ser recicladas. Por exemplo, se um contêiner que serve solicitações HTTP travar, o contêiner não falhará, mas deixará de atender solicitações. O teste HTTP liveness 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 o pod tenha sido iniciado com êxito. Por exemplo, o aplicativo em execução no contêiner pode estar executando tarefas de inicialização. A sonda de prontidã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 as sondas de integridade, com atraso e tempo limite adaptados especificamente às verificações que executam. A fórmula HPA desliga quase exclusivamente a fase Ready em um pod, por isso é fundamental que as sondas de saúde existam e sejam precisas.

Monitorização

Em um aplicativo de microsserviços, o monitoramento do Application Performance Management (APM) é essencial para detetar anomalias, diagnosticar problemas e entender rapidamente as dependências entre serviços. O Application Insights, que faz parte do Azure Monitor, fornece monitoramento de APM para aplicativos ao vivo 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 um ID de operação em rastreamentos, para que você possa corresponder todos os rastreamentos de uma operação específica.
  • Muitas vezes inclui informações contextuais adicionais em rastreamentos.

Para contextualizar a telemetria de serviços com o mundo 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 for Kubernetes enriquecerá 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 que o Application Insights gera para um rastreamento de telemetria de microsserviços AKS:

Example of an Application Insights dependency map for an AKS microservices application.

Para obter mais informações sobre opções de instrumentação de linguagens comuns para integração de insights de aplicativos, consulte Monitoramento de aplicativos para Kubernetes.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar 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 dimensionamento automático e gerenciamento imperativo ou declarativo do número de réplicas. Os usuários e um autoscaler 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 de pods é que os pods podem ser criados ou removidos com frequência, à medida que eventos de scale-out e scale-in acontecem. Para atenuar estes efeitos:

    • Use testes de preparação para informar ao Kubernetes quando um novo pod estiver pronto para aceitar tráfego.
    • Use orçamentos de interrupção de pods para limitar quantos pods podem ser removidos de um serviço de cada vez.

  • Não é possível alterar o tamanho da VM depois de criar um cluster, portanto, faça o planejamento da capacidade inicial para escolher um tamanho de VM apropriado para os nós do agente ao criar o cluster.

  • Cargas de trabalho multilocatárias 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, consulte 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 gestão

Considere os seguintes pontos ao planejar a capacidade de gerenciamento.

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

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

  • Considere seu fluxo de trabalho como um mecanismo a ser implantado 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âmetros e entrada.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

Considere os seguintes pontos ao planejar a segurança.

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

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

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

  • Nos casos em que um componente de aplicativo requer acesso à API do Kubernetes, certifique-se de que os pods de aplicativo estejam configurados para usar uma conta de serviço com acesso à API com escopo apropriado. Para obter mais informações sobre como configurar e gerenciar a conta de serviço do Kubernetes, consulte Gerenciando contas de serviço do Kubernetes.

  • Nem todos os serviços do Azure oferecem suporte à autenticação de plano de dados usando a ID do Microsoft Entra. Para armazenar credenciais ou segredos de aplicativo para esses serviços, para serviços de terceiros ou para chaves de API, use o Cofre de Chaves do Azure. O Azure Key Vault fornece gerenciamento centralizado, controle de acesso, criptografia em repouso e auditoria de todas as chaves e segredos.

  • No AKS, você pode montar um ou mais segredos do Cofre da Chave como um volume. O pod pode então ler os segredos do Key Vault como um volume normal. Para obter mais informações, consulte o projeto secrets-store-csi-driver-provider-azure no GitHub.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

  • A seção Custo no Microsoft Azure Well-Architected Framework descreve considerações de custo. Use a calculadora de preços do Azure para estimar custos para seu cenário específico.

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

  • Para estimar o custo dos recursos necessários, consulte a calculadora de Serviços de Contêiner.

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

Próximos passos