Conceitos de rede para aplicações no Azure Kubernetes Service (AKS)

Em uma abordagem de microsserviços baseada em contêiner para o desenvolvimento de aplicativos, os componentes do aplicativo trabalham juntos para processar suas tarefas. O Kubernetes fornece vários recursos que permitem essa cooperação:

  • Você pode se conectar e expor aplicativos interna ou externamente.
  • Você pode criar aplicativos altamente disponíveis balanceando a carga de seus aplicativos.
  • Você pode restringir o fluxo de tráfego de rede para dentro ou entre os pods e os nós para melhorar a segurança.
  • Você pode configurar o tráfego de Ingress para terminação SSL/TLS ou encaminhamento de vários componentes para as suas aplicações mais complexas.

Este artigo apresenta os principais conceitos que fornecem rede para seus aplicativos no AKS:

Noções básicas de rede do Kubernetes

O Kubernetes emprega uma camada de rede virtual para gerenciar o acesso dentro e entre seus aplicativos ou seus componentes:

  • Nós do Kubernetes e rede virtual: os nós do Kubernetes estão conectados a uma rede virtual. Essa configuração permite que pods (unidades básicas de implantação no Kubernetes) tenham conectividade de entrada e saída.

  • Componente de encaminhamento de serviços: Dependendo do plano de dados da rede, os nós utilizam kube-proxy ou Cilium para o encaminhamento de Serviços do Kubernetes. Os clusters do AKS que utilizam o Azure CNI com tecnologia Cilium não utilizam kube-proxy.

Em relação às funcionalidades específicas do Kubernetes:

  • Balanceador de carga: Você pode usar um balanceador de carga para distribuir o tráfego de rede uniformemente entre vários recursos.
  • Controladores de ingresso: facilitam o roteamento da Camada 7, que é essencial para direcionar o tráfego do aplicativo.
  • Controle de tráfego de saída: o Kubernetes permite gerenciar e controlar o tráfego de saída dos nós do cluster.
  • Políticas de rede: essas políticas permitem medidas de segurança e filtragem para o tráfego de rede em pods.

No contexto da plataforma Azure:

  • Azure simplifica redes virtuais para clusters AKS (Azure Kubernetes Service).
  • Criar um balanceador de carga Kubernetes no Azure configura simultaneamente o recurso correspondente do balanceador de carga do Azure.
  • Quando cria um Serviço KubernetesLoadBalancer, o Azure configura as regras necessárias do grupo de segurança de rede para o tráfego de serviços em recursos geridos pelo AKS.
  • O Azure também pode gerir configurações DNS externas para o encaminhamento de aplicações HTTP à medida que novas rotas de entrada são estabelecidas.

Redes virtuais Azure

No AKS, você pode implantar um cluster que usa um dos seguintes modelos de rede:

  • Modelo de rede de sobreposição: a rede de sobreposição é o modelo de rede mais comum usado no Kubernetes. Os pods recebem um endereço IP de um CIDR privado e logicamente separado da sub-rede virtual do Azure onde são implantados os nós AKS. Este modelo permite uma escalabilidade mais simples e melhorada quando comparado com o modelo de rede plana.
  • Modelo de rede plana: Um modelo de rede plana no AKS atribui endereços IP aos pods a partir de uma sub-rede na mesma rede virtual do Azure que os nós do AKS. Para o tráfego de rede privada, o endereço IP de origem que o destino vê depende da opção de gestão de endereços IP (IPAM). A subrede Azure CNI Pod preserva o endereço IP do pod através de redes virtuais conectadas. Com a sub-rede de nós do Azure CNI, os destinos na rede virtual do cluster veem o endereço IP do pod, mas os destinos fora da rede virtual do cluster veem o endereço IP do nó. Para a saída para a Internet, o método de saída configurado determina o endereço IP público de origem que os destinos na Internet veem.

Para obter mais informações sobre modelos de rede no AKS, consulte Rede CNI no AKS.

Controlar o tráfego de saída (egressão)

Os clusters AKS são implantados em uma rede virtual e têm dependências de saída em serviços fora dessa rede virtual, que são quase inteiramente definidos com FQDNs (nomes de domínio totalmente qualificados). O AKS fornece várias opções de configuração de saída que permitem personalizar a maneira como esses recursos externos são acessados.

Importante

A partir de 31 de março de 2026, Azure Kubernetes Service (AKS) já não suporta acesso de saída por defeito para máquinas virtuais (VMs). Novos clusters AKS que utilizam a opção de rede virtual gerida por AKS irão colocar sub-redes de cluster em sub-redes privadas por defeito (defaultOutboundAccess = false). Esta configuração não afeta o tráfego de cluster gerido pelo AKS, que utiliza caminhos de saída explicitamente configurados. Pode afetar cenários não suportados, como a implementação de outros recursos na mesma sub-rede. Clusters que usam BYO VNets não são afetados por esta alteração. Nas configurações suportadas, nenhuma ação é necessária. Para mais informações sobre esta descontinuação, consulte o anúncio de descontinuação de Azure Updates. Para se manter informado sobre anúncios e atualizações, siga as notas de lançamento AKS.

Opções de configuração de saída

Para mais informações sobre os tipos de configuração de saída do cluster AKS suportados, veja Personalizar a saída do cluster com tipos de saída em Azure Kubernetes Service (AKS).

Por padrão, os clusters AKS têm acesso irrestrito à Internet de saída (saída), o que permite que os nós e serviços executados acessem recursos externos conforme necessário. Se desejar, você pode restringir o tráfego de saída.

Para obter mais informações sobre como restringir o tráfego de saída do cluster, consulte Controlar o tráfego de saída para nós de cluster no AKS.

Grupos de segurança de rede

Um grupo de segurança de rede filtra o tráfego para VMs como os nós AKS. À medida que crias Serviços, como um LoadBalancer, a plataforma Azure configura automaticamente as regras necessárias do grupo de segurança de rede para o tráfego de serviços em recursos geridos pelo AKS.

O AKS não aplica grupos de segurança de rede à sua sub-rede nem modifica grupos de segurança de rede que associa a uma sub-rede fornecida pelo cliente. Se associar um grupo de segurança de rede a uma sub-rede personalizada, tem de garantir que as respetivas regras permitem o tráfego necessário dos nós e dos pods. Para mais informações, consulte os pré-requisitos de redes AKS CNI.

Também pode utilizar políticas de rede para aplicar automaticamente as regras do filtro de tráfego aos pods.

Para obter mais informações, consulte Como os grupos de segurança de rede filtram o tráfego de rede.

Requisitos de rede virtual personalizados

Quando usa uma rede virtual personalizada com clusters AKS, se adicionar regras de grupo de segurança de rede para restringir o tráfego entre sub-redes, certifique-se de que as regras permitem o tráfego exigido pela configuração do seu cluster.

A integração do VNet do API Server está pré-configurada no AKS Automatic. No AKS Standard, a funcionalidade é opcional e tens de a ativar explicitamente. Quando o seu cluster utiliza API Server VNet Integration, permita o seguinte tráfego:

Destino Fonte Protocolo Port Utilização
APIServer Sub-Rede CIDR Sub-rede do cluster TCP 443 e 4443 Necessário para habilitar a comunicação entre nós e o servidor de API.
APIServer Sub-Rede CIDR Balanceador de Carga do Azure TCP 9988 Necessário para permitir a comunicação entre o Balanceador de Carga do Azure e o servidor API. Também pode ativar toda a comunicação entre o Balanceador de Carga do Azure e o API Server Subnet CIDR.

Para obter mais informações, consulte API Server VNet Integration.

Para comunicação entre nós e pods, permita o seguinte tráfego quando as regras do grupo de segurança de rede restringem os intervalos CIDR correspondentes:

Destino Fonte Protocolo Port Utilização
Nó CIDR Nó CIDR Todos os Protocolos Todos os Portos Necessário para permitir a comunicação entre nós.
Pod CIDR Nó CIDR Todos os Protocolos Todos os Portos Necessário para roteamento de tráfego de serviço.
Pod CIDR Pod CIDR Todos os Protocolos Todos os Portos Necessário para o tráfego de Pod to Pod e Pod to Service, incluindo DNS.

Os intervalos CIDR aplicáveis aos nós e pods dependem do modelo de rede do seu cluster. Para mais informações, consulte os pré-requisitos de redes AKS CNI.

Resolução de DNS

A resolução DNS é essencial para a descoberta de serviços e comunicação no AKS. Por padrão, o AKS utiliza CoreDNS para fornecer resolução interna de nomes para pods e serviços.

Para melhorar o desempenho e a fiabilidade do DNS, o AKS oferece o LocalDNS, que implementa um proxy DNS em cada nó. O LocalDNS resolve consultas localmente, reduzindo a latência e eliminando conntrack a pressão das tabelas do tráfego DNS. Pode configurar o LocalDNS para fornecer respostas em cache durante interrupções do DNS a montante, mas o armazenamento em cache de respostas desatualizadas funciona numa base de melhor esforço. O LocalDNS é particularmente benéfico em grandes clusters ou ambientes com elevados volumes de consulta DNS.

O LocalDNS está pré-configurado no AKS Automatic. No AKS Standard, o LocalDNS é opcional e configurado por pool de nós. Antes de o ativar no AKS Standard, verifica os pré-requisitos da versão do Kubernetes, do sistema operativo do nó e do SKU da VM. Ativar o LocalDNS num conjunto de nós existente recria a imagem dos respetivos nós. Para pré-requisitos e planeamento de implementação, veja Configurar LocalDNS.

Políticas de rede

Por padrão, todos os pods em um cluster AKS podem enviar e receber tráfego sem limitações. Para maior segurança, defina regras que controlem o fluxo de tráfego, como:

  • Os aplicativos back-end são expostos apenas aos serviços front-end necessários.
  • Os componentes de banco de dados só são acessíveis às camadas de aplicativo que se conectam a eles.

A política de rede é um recurso do Kubernetes disponível no AKS que permite controlar o fluxo de tráfego entre pods. Você pode permitir ou negar tráfego para o pod com base em configurações como rótulos atribuídos, namespace ou porta de tráfego. Embora os grupos de segurança de rede sejam melhores para nós do AKS, as políticas de rede são uma forma mais adequada e nativa da cloud para controlar o fluxo de tráfego dos pods. Como os pods são criados dinamicamente em um cluster AKS, as políticas de rede necessárias podem ser aplicadas automaticamente.

Para mais informações, consulte Tráfego seguro entre pods usando políticas de rede em Azure Kubernetes Service (AKS).

Próximos passos

Para começar com redes AKS, crie e configure um cluster AKS com os seus próprios intervalos de endereços IP usando Azure CNI Overlay ou Azure CNI.

Para obter as melhores práticas associadas, consulte Práticas recomendadas para conectividade de rede e segurança no AKS.

Para obter mais informações sobre os principais conceitos de Kubernetes e AKS, consulte os seguintes artigos:

  • Last updated on