Arquitetura da Rede de Aplicações Azure Kubernetes (pré-visualização)

Importante

Os recursos de pré-visualização do AKS estão disponíveis numa base de autosserviço e adesão voluntária. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões de teste do AKS são parcialmente cobertas pelo suporte ao cliente numa base de melhor esforço. Assim sendo, estas funcionalidades não se destinam ao uso em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

A arquitetura da Rede de Aplicações Azure Kubernetes está organizada em três camadas: um plano de gestão, um plano de controlo e um plano de dados. Cada camada tem responsabilidades distintas que, em conjunto, fornecem uma solução de rede de serviços totalmente gerida e baseada em Ambiente para o Azure Kubernetes Service (AKS). Esta arquitetura permite uma comunicação segura, regida por políticas, entre serviços sem a necessidade de sidecars ou de alterações nas suas aplicações.

Este artigo apresenta uma visão geral das camadas arquitetónicas da Azure Kubernetes Application Network, como interagem e o modelo de descoberta de serviços multi-cluster que permite uma comunicação escalável entre clusters. Para mais informações sobre a Azure Kubernetes Application Network, consulte a Visão Geral da Azure Kubernetes Application Network para AKS.

Visão geral das camadas arquitetónicas de Rede de Aplicações

As camadas arquitetónicas gerem as seguintes responsabilidades:

  • Plano de gestão: Gere operações de recursos Azure, como criar, atualizar e eliminar recursos da Rede de Aplicações e gerir a pertença a um cluster.
  • Plano de controlo: Gere a configuração da malha, o ciclo de vida dos certificados e a descoberta de serviços para cada cluster membro.
  • Plano de dados: Protege o tráfego entre serviços diretamente no cluster membro, usando o modo ambiental, que não requer sidecars nem alterações nas aplicações.

Para implementações multi-cluster, a Rede de Aplicações sincroniza a informação de descoberta de serviços entre clusters membros, para que os serviços possam comunicar de forma transparente através dos limites do cluster.

O diagrama seguinte ilustra as camadas arquitetónicas da Azure Kubernetes Application Network e como interagem entre si e com os seus clusters AKS:

Captura de ecrã de um diagrama que ilustra as camadas arquitetónicas da Azure Kubernetes Application Network e como interagem entre si e com clusters AKS.

Plano de gestão

O plano de gestão é o fornecedor de recursos do Azure responsável por gerir todas as operações dos recursos da Rede de Aplicações. Quando cria um recurso de Rede de Aplicações ou se junta a um cluster de membros, o plano de gestão valida o pedido, fornece suporte a recursos Azure como o Azure Key Vault para armazenamento de certificados e orquestra a criação de um plano de controlo regional para o membro.

Interages com o plano de gestão através da Azure CLI (az appnet) ou da API ARM. O plano de gestão coordena todo o provisionamento a jusante para que os componentes do plano de controlo e do plano de dados sejam implantados sem intervenção manual.

Plano de controlo

O plano de controlo é uma infraestrutura totalmente gerida que corre fora do seu cluster AKS. Quando um cluster membro se junta a uma Rede de Aplicações, um plano de controlo dedicado é provisionado na mesma região Azure que o cluster membro, mantendo baixa a latência entre os componentes do plano de controlo e do plano de dados.

Observação

Os membros em diferentes regiões Azure têm planos de controlo implantados nas respetivas regiões.

O plano de controlo inclui os seguintes componentes:

  • Istiod: Liga-se ao servidor API Kubernetes do cluster membro para descobrir serviços e observar alterações na configuração. Envia a configuração do xDS para os proxies ztunnel e waypoint no plano de dados. Em implementações multi-cluster, o Istiod também liga-se aos servidores API Kubernetes de outros clusters membros para obter informação de descoberta de serviços, permitindo a descoberta de serviços entre clusters.
  • Gestão de certificados: Provisiona e roda certificados de CA suportados pelo Azure Key Vault. Uma CA raiz estabelece uma fronteira de confiança partilhada entre todos os clusters membros, e cada membro recebe uma CA intermédia que emite certificados de carga de trabalho de curta duração. Para mais informações, consulte a Visão Geral da Segurança de Redes de Aplicações Azure Kubernetes.
  • Gestão do ciclo de vida: Implementa e atualiza todos os componentes do plano de dados no cluster membro, incluindo ztunnel, Istio CNI, proxies de waypoint e definições personalizadas de recursos (CRDs). Para mais informações, consulte Configurar atualizações para membros da Azure Kubernetes Application Network.

Plano de dados

O plano de dados consiste em componentes desdobrados no namespace do cluster membro applink-system. A Rede de Aplicações utiliza o modo ambiente do Istio, por isso não há sidecars injetados nos seus workloads.

O plano de dados inclui os seguintes componentes:

  • Ztunnel: Um proxy L4 a nível de nó implementado como DaemonSet. Ztunnel interceta o tráfego de serviço para serviço no nó, estabelece ligações mTLS de forma transparente e aplica as políticas de autorização L4.
  • Waypoint proxies: Proxies L7 opcionais por namespace que fornecem encaminhamento HTTP, gestão de tráfego, injeção de falhas e autorização L7. Proxies de waypoint só são implementados quando as políticas L7 são configuradas para um namespace.
  • Gateway este-oeste: Gerir o tráfego entre clusters em implementações multi-cluster. És responsável por fornecer conectividade de rede entre gateways este-oeste em cada cluster membro. Para mais informações, veja descoberta de serviços multi-cluster.
  • Istio CNI: Um DaemonSet que configura a rede de pods para interceção de tráfego em malha ambiente.
  • CRDs: Definições personalizadas de recursos Kubernetes para configurar políticas de gestão de tráfego e segurança.

Quando um pedido é feito entre serviços, o ztunnel interceta o tráfego, estabelece uma ligação mTLS com o ztunnel do destino e entrega o pedido à carga de trabalho do destino. Se as políticas L7 estiverem configuradas, o tráfego passa por um proxy de waypoint antes de chegar ao destino. Para tráfego entre clusters, o ztunnel roteia através do gateway este-oeste para alcançar cargas de trabalho em clusters membros remotos.

Descoberta de serviços multi-cluster

A Rede de Aplicações suporta a ligação de múltiplos clusters AKS numa malha de serviço unificada. Os serviços num cluster membro podem comunicar com serviços de outros clusters membros, com o mTLS imposto de ponta a ponta através das fronteiras do cluster.

Nas implementações multi-cluster open source do Istio, os planos de controlo normalmente ligam-se aos servidores API Kubernetes de outros clusters para descobrir serviços e alterações de configuração. A Rede de Aplicações segue um modelo semelhante de descoberta de serviços, onde os planos de controlo obtêm informação de serviço dos clusters membros para que os serviços possam ser descobertos através das fronteiras do cluster. Esta abordagem permite que cargas de trabalho num cluster membro resolvam e comuniquem com serviços em execução noutros clusters sem necessidade de alterações na aplicação. Adicionar um novo cluster de membros expande a pertença à malha para que os serviços do novo cluster se tornem detetáveis por outros membros.

O tráfego entre clusters flui através de portais este-oeste implantados em cada cluster membro. É responsável por garantir a acessibilidade da rede entre os gateways este-oeste dos seus clusters membros — por exemplo, através de peering VNet, VPN ou outras soluções de conectividade. Todo o tráfego cross-cluster é encriptado com mTLS.

Como os componentes interagem

O plano de controlo liga-se ao servidor API Kubernetes do cluster membro, observa alterações de serviço e configuração, e envia atualizações xDS para proxies ztunnel e waypoint. Quando existem múltiplos membros, cada plano de controlo também troca informações de serviço através de mensagens geridas, para que cada membro tenha uma visão consistente de todos os serviços na malha.

A gestão de certificados prevê uma CA raiz quando o recurso da Rede de Aplicações é criado e emite CAs intermédias para cada cluster membro. Os certificados de carga de trabalho são emitidos com um período de validade de 24 horas e rotacionados automaticamente a cada 12 horas. Todo o ciclo de vida dos certificados, desde a CA root até aos certificados intermédios e de carga de trabalho, é gerido sem intervenção manual.

Para a hierarquia completa dos certificados e o calendário de rotação, consulte a Visão Geral da Segurança da Rede de Aplicações Azure Kubernetes.

Conteúdo relacionado

Para mais informações sobre a Azure Kubernetes Application Network, consulte os seguintes artigos:

  • Última atualização a