Arquitetura da Rede de Aplicativos do Kubernetes do Azure (versão prévia)

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

A arquitetura da Rede de Aplicativos do Kubernetes do Azure é organizada em três camadas: um plano de gerenciamento, um plano de controle e um plano de dados. Cada camada tem responsabilidades distintas que, juntas, fornecem uma solução de rede de serviço totalmente gerenciada e baseada em ambiente para o AKS (Serviço de Kubernetes do Azure). Essa arquitetura permite uma comunicação segura e orientada por políticas entre serviços sem a necessidade de sidecars ou alterações em seus aplicativos.

Este artigo fornece uma visão geral das camadas arquitetônicas da Rede de Aplicativos kubernetes do Azure, como elas interagem e o modelo de descoberta de serviço multi cluster que permite a comunicação escalonável entre clusters. Para obter mais informações sobre a Rede de Aplicativos kubernetes do Azure, consulte a visão geral da Rede de Aplicativos kubernetes do Azure para AKS.

Visão geral das camadas de arquitetura da Rede de Aplicativos

As camadas de arquitetura gerenciam as seguintes responsabilidades:

  • Plano de gerenciamento: lida com operações de recursos do Azure, como criar, atualizar e excluir recursos da Rede de Aplicativos e gerenciar a associação de cluster.
  • Plano de controle: gerencia a configuração de malha, o ciclo de vida do certificado e a descoberta de serviço para cada cluster membro.
  • Plano de dados: protege o tráfego de serviço para serviço diretamente no cluster membro usando o modo ambiente, que não requer sidecars ou alterações nos seus aplicativos.

Para implantações de vários clusters, a Rede de Aplicativos sincroniza informações de descoberta de serviço em clusters membros para que os serviços possam se comunicar de forma transparente entre os limites do cluster.

O diagrama a seguir ilustra as camadas arquitetônicas da Rede de Aplicativos kubernetes do Azure e como elas interagem entre si e com seus clusters do AKS:

Captura de tela de um diagrama ilustrando as camadas arquitetônicas da Rede de Aplicativos kubernetes do Azure e como elas interagem entre si e com clusters do AKS.

Plano de gerenciamento

O plano de gerenciamento é o provedor de recursos do Azure que manipula todas as operações de recurso da Rede de Aplicativos. Quando você cria um recurso de Rede de Aplicativos ou ingressa em um cluster membro, o plano de gerenciamento valida a solicitação, provisiona recursos de suporte do Azure, como o Azure Key Vault para armazenamento de certificados, e orquestra a criação de um plano de controle regional para o membro.

Você interage com o plano de gerenciamento por meio da CLI do Azure (az appnet) ou da API do ARM. O plano de gerenciamento coordena todo o provisionamento downstream para que os componentes do plano de controle e do plano de dados sejam implantados sem intervenção manual.

Painel de controle

O plano de controle é uma infraestrutura totalmente gerenciada que é executada fora do cluster do AKS. Quando um cluster membro ingressa em uma Rede de Aplicativos, um plano de controle dedicado é provisionado na mesma região do Azure que o cluster membro, mantendo a latência entre os componentes de plano de dados e controle baixos.

Observação

Membros em regiões diferentes do Azure têm planos de controle implantados em suas respectivas regiões.

O plano de controle inclui os seguintes componentes:

  • Istiod: conecta-se ao servidor de API kubernetes do cluster membro para descobrir serviços e observar as alterações de configuração. Transmite a configuração xDS para os proxies ztunnel e de ponto de passagem no plano de dados. Em implantações de vários clusters, o Istiod também se conecta aos servidores de API do Kubernetes de outros clusters membros para obter informações de descoberta de serviço, permitindo a descoberta de serviço entre clusters.
  • Gerenciamento de certificados: provisiona e roda certificados CA com suporte do Azure Key Vault. Uma AC raiz estabelece um limite de confiança compartilhada em todos os clusters membros e cada membro recebe uma AC intermediária que emite certificados de carga de trabalho de curta duração. Para obter mais informações, consulte a visão geral da segurança da Rede de Aplicativos do Kubernetes do Azure.
  • Gerenciamento do ciclo de vida: implanta e atualiza todos os componentes do plano de dados no cluster membro, incluindo ztunnel, CNI do Istio, proxies de ponto de passagem e CRDs (definições de recursos personalizados). Para obter mais informações, consulte Configurar atualizações para membros da Rede de Aplicativos do Kubernetes do Azure.

Plano de dados

O plano de dados consiste em componentes implantados no namespace de um cluster membro applink-system. A rede de aplicativo usa o modo ambiente Istio, portanto, não há sidecars injetados em suas cargas de trabalho.

O plano de dados inclui os seguintes componentes:

  • Ztunnel: um proxy L4 no nível do nó implantado como um DaemonSet. O Ztunnel intercepta o tráfego serviço a serviço no nó, estabelece conexões mTLS de forma transparente e impõe políticas de autorização L4.
  • Proxies de ponto de passagem: proxies L7 opcionais por namespace que fornecem roteamento HTTP, mudança de tráfego, injeção de falhas e autorização L7. Os proxies do Waypoint são implantados somente quando as políticas L7 são configuradas para um namespace.
  • Gateway leste-oeste: manipula o tráfego entre clusters em implantações de vários clusters. Você é responsável por fornecer conectividade de rede entre gateways leste-oeste em cada cluster membro. Para obter mais informações, consulte descoberta de serviços multicluster.
  • CNI Istio: um DaemonSet que configura a rede de pods para interceptação de tráfego de malha ambiente.
  • CRDs: definições de recursos personalizados do Kubernetes para configurar políticas de segurança e gerenciamento de tráfego.

Quando uma solicitação é feita entre serviços, o ztunnel intercepta o tráfego, estabelece uma conexão mTLS com o ztunnel do destino e entrega a solicitação para a carga de trabalho de destino. Se as políticas L7 estiverem configuradas, o tráfego será roteado por meio de um proxy de ponto de passagem antes de chegar ao seu destino. Para o tráfego entre clusters, o ztunnel percorre o gateway leste-oeste para alcançar cargas de trabalho em clusters membros remotos.

Descoberta de serviço de vários clusters

A Rede de Aplicativos dá suporte à conexão de vários clusters do AKS em uma malha de serviço unificada. Os serviços em um cluster membro podem se comunicar com serviços em outros clusters membros, com mTLS aplicado de ponta a ponta entre os limites do cluster.

Em implantações de Istio multi-cluster de código aberto, os planos de controle normalmente se conectam aos servidores de API do Kubernetes de outros clusters para descobrir serviços e mudanças de configuração. A Rede de Aplicativos segue um modelo de descoberta de serviço semelhante, em que os planos de controle obtêm informações de serviço de clusters membros para que os serviços possam ser descobertos entre os limites do cluster. Essa abordagem permite que cargas de trabalho em um cluster membro resolvam e se comuniquem com serviços em execução em outros clusters sem a necessidade de alterações de aplicativo. A adição de um novo membro ao cluster expande a associação de malha, de modo que os serviços no novo cluster se tornem descobertos por outros membros.

O tráfego entre clusters flui por gateways leste-oeste implantados em cada cluster membro. Você é responsável por fornecer alcance de rede entre os gateways leste-oeste dos clusters membros, por exemplo, por meio de emparelhamento VNet, VPN ou outras soluções de conectividade. Todo o tráfego entre clusters é criptografado com mTLS.

Como os componentes interagem

O plano de controle se conecta ao servidor de API Kubernetes do cluster membro, monitora alterações nos serviços e configurações, e envia atualizações do xDS para os proxies ztunnel e waypoint. Quando há vários membros, cada plano de controle também troca informações de serviço por meio de mensagens gerenciadas para que cada membro tenha uma exibição consistente de todos os serviços em toda a malha.

O gerenciamento de certificados provisiona uma CA raiz quando o recurso Rede de Aplicativo é criado e emite CAs intermediárias para cada cluster membro. Os certificados de carga de trabalho são emitidos com um período de validade de 24 horas e girados automaticamente a cada 12 horas. Todo o ciclo de vida do certificado, desde a CA raiz até os certificados intermediários e de carga de trabalho, é gerenciado sem intervenção manual.

Para obter a hierarquia de certificados completa e o agendamento de rotação, consulte a visão geral da segurança da Rede de Aplicativos do Kubernetes do Azure.

Conteúdo relacionado

Para obter mais informações sobre a Rede de Aplicativos kubernetes do Azure, consulte os seguintes artigos:

  • Última atualização em