Conceitos de rede para aplicativos no Serviço Kubernetes do Azure (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 ou entre pods e nós para melhorar a segurança.
- Você pode configurar o tráfego de entrada para terminação SSL/TLS ou roteamento de vários componentes para seus aplicativos mais complexos.
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 Kube-proxy: kube-proxy é executado em cada nó e é responsável por fornecer os recursos de rede necessários.
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:
- O Azure simplifica a rede virtual para clusters AKS (Serviço Kubernetes do Azure).
- Criar um balanceador de carga do Kubernetes no Azure configura simultaneamente o recurso correspondente do balanceador de carga do Azure.
- À medida que você abre portas de rede para pods, o Azure configura automaticamente as regras de grupo de segurança de rede necessárias.
- O Azure também pode gerenciar configurações de DNS externas para roteamento de aplicativos HTTP à medida que novas rotas de entrada são estabelecidas.
Redes virtuais do Azure
No AKS, você pode implantar um cluster que usa um dos seguintes modelos de rede:
Rede Kubenet
Os recursos de rede são normalmente criados e configurados à medida que o cluster AKS é implantado.
Rede CNI (Container Networking Interface) do Azure
o cluster do AKS está associado aos recursos e configurações existentes da rede virtual.
Rede Kubenet (básica)
A opção de rede kubenet é a configuração padrão para a criação de clusters AKS. Com kubenet:
- Os nós recebem um endereço IP da sub-rede de rede virtual do Azure.
- Os pods recebem um endereço IP de um espaço de endereço logicamente diferente da sub-rede de rede virtual do Azure dos nós.
- A tradução de endereços de rede (NAT) é configurada para que os pods possam chegar aos recursos na rede virtual do Azure.
- O endereço IP de origem do tráfego é convertido para o endereço IP primário do nó.
Os nós usam o plug-in kubenet Kubernetes. Você pode permitir que a plataforma Azure crie e configure as redes virtuais para você ou optar por implantar seu cluster AKS em uma sub-rede de rede virtual existente.
Somente os nós recebem um endereço IP roteável. Os pods usam NAT para se comunicar com outros recursos fora do cluster AKS. Essa abordagem reduz o número de endereços IP que você precisa reservar em seu espaço de rede para pods usarem.
Nota
Embora o kubenet seja a opção de rede padrão para um cluster AKS criar uma rede virtual e uma sub-rede, ele não é recomendado para implantações de produção. Para a maioria das implantações de produção, você deve planejar e usar a rede CNI do Azure devido às suas características superiores de escalabilidade e desempenho.
Para obter mais informações, consulte Configurar rede kubenet para um cluster AKS.
Rede CNI (avançada) do Azure
Com o Azure CNI, cada pod obtém um endereço IP da sub-rede e pode ser acedido diretamente. Esses endereços IP devem ser planejados com antecedência e exclusivos em todo o espaço da rede. Cada nó tem um parâmetro de configuração para o número máximo de pods suportados. O número equivalente de endereços IP por nó é então reservado antecipadamente. Essa abordagem pode levar ao esgotamento do endereço IP ou à necessidade de reconstruir clusters em uma sub-rede maior à medida que as demandas do seu aplicativo crescem, por isso é importante planejar corretamente. Para evitar esses desafios de planejamento, é possível habilitar o recurso de rede CNI do Azure para alocação dinâmica de IPs e suporte aprimorado a sub-redes.
Nota
Devido às limitações do Kubernetes, o nome do Grupo de Recursos, o nome da Rede Virtual e o nome da sub-rede devem ter 63 caracteres ou menos.
Ao contrário do kubenet, o tráfego para pontos de extremidade na mesma rede virtual não é traduzido (NAT) para o IP primário do nó. O endereço de origem do tráfego dentro da rede virtual é o IP do pod. O tráfego externo à rede virtual ainda é NATs para o IP principal do nó.
Os nós usam o plug-in do Kubernetes CNI do Azure.
Para obter mais informações, consulte Configurar o Azure CNI para um cluster AKS.
Rede de sobreposição CNI do Azure
O Azure CNI Overlay representa uma evolução do Azure CNI, abordando desafios de escalabilidade e planejamento decorrentes da atribuição de IPs de rede virtual a pods. O Azure CNI Overlay atribui IPs CIDR privados a pods. Os IPs privados são separados da rede virtual e podem ser reutilizados em vários clusters. A sobreposição CNI do Azure pode ser dimensionada além do limite de 400 nós imposto em clusters Kubenet. A Sobreposição CNI do Azure é a opção recomendada para a maioria dos clusters.
Azure CNI com Tecnologia Cilium
O Azure CNI Powered by Cilium usa o Cilium para fornecer rede, observabilidade e imposição de políticas de rede de alto desempenho. Ele se integra nativamente ao Azure CNI Overlay para gerenciamento escalável de endereços IP (IPAM).
Além disso, o Cilium impõe políticas de rede por padrão, sem exigir um mecanismo de diretiva de rede separado. O Azure CNI Powered by Cilium pode ser dimensionado além dos limites do Azure Network Policy Manager de 250 nós / pod de 20 K usando programas eBPF e uma estrutura de objeto de API mais eficiente.
O Azure CNI Powered by Cilium é a opção recomendada para clusters que exigem imposição de política de rede.
Traga o seu próprio CNI
É possível instalar no AKS uma CNI que não seja da Microsoft usando o recurso Bring your own CNI .
Comparar modelos de rede
Tanto o kubenet quanto o Azure CNI fornecem conectividade de rede para seus clusters AKS. No entanto, há vantagens e desvantagens para cada um. A um nível elevado, aplicam-se as seguintes considerações:
Kubenet
- Conserva o espaço de endereço IP.
- Usa balanceadores de carga internos ou externos do Kubernetes para alcançar pods de fora do cluster.
- Você gerencia e mantém manualmente rotas definidas pelo usuário (UDRs).
- Máximo de 400 nós por cluster.
Azure CNI
- Os pods obtêm conectividade de rede virtual completa e podem ser acessados diretamente através de seu endereço IP privado a partir de redes conectadas.
- Requer mais espaço de endereço IP.
| Modelo de rede | Quando utilizar o |
|---|---|
| Kubenet | • A conversação do espaço de endereço IP é uma prioridade. • Configuração simples. • Menos de 400 nós por cluster. • Os balanceadores de carga internos ou externos do Kubernetes são suficientes para alcançar pods de fora do cluster. • É aceitável gerir e manter manualmente as rotas definidas pelo utilizador. |
| Azure CNI | • Conectividade de rede virtual completa é necessária para pods. • Recursos avançados do AKS (como nós virtuais) são necessários. • Espaço de endereço IP suficiente está disponível. • É necessária conectividade de pod para pod e pod para máquina virtual. • Os recursos externos precisam chegar diretamente aos pods. • As políticas de rede AKS são necessárias. |
| Sobreposição do Azure CNI | • A escassez de endereços IP é uma preocupação. • Dimensionar até 1.000 nós e 250 pods por nó é suficiente. • Salto extra para conectividade de pod é aceitável. • Configuração de rede mais simples. • Os requisitos de saída do AKS podem ser cumpridos. |
As seguintes diferenças de comportamento existem entre kubenet e Azure CNI:
| Funcionalidade | Kubenet | Azure CNI | Sobreposição do Azure CNI | Azure CNI com Tecnologia Cilium |
|---|---|---|---|---|
| Implantar cluster em rede virtual nova ou existente | Suportado - UDRs aplicados manualmente | Suportado | Suportado | Suportado |
| Conectividade Pod-pod | Suportado | Suportado | Suportado | Suportado |
| Conectividade Pod-VM; VM na mesma rede virtual | Funciona quando iniciado por pod | Funciona nos dois sentidos | Funciona quando iniciado por pod | Funciona quando iniciado por pod |
| Conectividade Pod-VM; VM em rede virtual emparelhada | Funciona quando iniciado por pod | Funciona nos dois sentidos | Funciona quando iniciado por pod | Funciona quando iniciado por pod |
| Acesso local usando VPN ou Rota Expressa | Funciona quando iniciado por pod | Funciona nos dois sentidos | Funciona quando iniciado por pod | Funciona quando iniciado por pod |
| Acesso a recursos protegidos por pontos de extremidade de serviço | Suportado | Suportado | Suportado | |
| Expor serviços do Kubernetes usando um serviço de balanceador de carga, App Gateway ou controlador de entrada | Suportado | Suportado | Suportado | Mesmas limitações ao usar o modo de sobreposição |
| Suporte para pools de nós do Windows | Não suportado | Suportado | Suportado | Disponível apenas para Linux e não para Windows. |
| DNS padrão do Azure e zonas privadas | Suportado | Suportado | Suportado |
Para obter mais informações sobre o Azure CNI e kubenet e para ajudar a determinar qual é a melhor opção para você, consulte Configurar a rede CNI do Azure no AKS e Usar a rede kubenet no AKS.
Escopo de suporte entre modelos de rede
Seja qual for o modelo de rede usado, o kubenet e o Azure CNI podem ser implantados de uma das seguintes maneiras:
- A plataforma Azure pode criar e configurar automaticamente os recursos de rede virtual quando você cria um cluster AKS.
- Você pode criar e configurar manualmente os recursos de rede virtual e anexá-los a esses recursos ao criar seu cluster AKS.
Embora recursos como pontos de extremidade de serviço ou UDRs sejam suportados com kubenet e Azure CNI, as políticas de suporte para AKS definem quais alterações você pode fazer. Por exemplo:
- Se você criar manualmente os recursos de rede virtual para um cluster AKS, terá suporte ao configurar seus próprios UDRs ou pontos de extremidade de serviço.
- Se a plataforma Azure criar automaticamente os recursos de rede virtual para seu cluster AKS, você não poderá alterar manualmente esses recursos gerenciados pelo AKS para configurar seus próprios UDRs ou pontos de extremidade de serviço.
Controladores de entrada
Ao criar um serviço do tipo LoadBalancer, você também cria um recurso subjacente do balanceador de carga do Azure. O balanceador de carga está configurado para distribuir tráfego para os pods em seu Serviço em uma determinada porta.
O LoadBalancer só funciona na camada 4. Na camada 4, o Serviço não está ciente dos aplicativos reais e não pode fazer mais considerações de roteamento.
Os controladores de entrada funcionam na camada 7 e podem usar regras mais inteligentes para distribuir o tráfego do aplicativo. Os controladores de entrada normalmente roteiam o tráfego HTTP para diferentes aplicativos com base na URL de entrada.
Comparar opções de entrada
A tabela a seguir lista as diferenças de recursos entre as diferentes opções do controlador de ingresso:
| Caraterística | Complemento de roteamento de aplicativos | Gateway de Aplicação para Contentores | Malha de serviço baseada em Malha de Serviço do Azure/Istio |
|---|---|---|---|
| Controlador de Ingresso/Gateway | Controlador de entrada NGINX | Azure Application Gateway for Containers | Istio Ingress Gateway |
| API | API de ingresso | API de Ingresso e API de Gateway | Gateway API |
| Alojamento | No cluster | Azure hospedado | No cluster |
| Dimensionamento | Dimensionamento automático | Dimensionamento automático | Dimensionamento automático |
| Balanceamento de carga | Interna/Externa | Externa | Interna/Externa |
| Terminação SSL | No cluster | Sim: Descarregamento e E2E SSL | No cluster |
| mTLS | N/A | Sim ao back-end | N/A |
| Endereço IP estático | N/A | FQDN | N/A |
| Certificados SSL armazenados do Azure Key Vault | Sim | Sim | N/A |
| Integração do DNS do Azure para gerenciamento de zona DNS | Sim | Sim | N/A |
A tabela a seguir lista os diferentes cenários em que você pode usar cada controlador de entrada:
| Opção de ingresso | Quando utilizar o |
|---|---|
| NGINX gerenciado - complemento de roteamento de aplicativos | • Controladores de entrada NGINX hospedados, personalizáveis e escaláveis no cluster. • Recursos básicos de balanceamento de carga e roteamento. • Configuração de balanceador de carga interno e externo. • Configuração de endereço IP estático. • Integração com o Azure Key Vault para gestão de certificados. • Integração com Zonas DNS do Azure para gestão de DNS público e privado. • Suporta a API de Ingresso. |
| Gateway de aplicativo para contêineres | • Gateway de entrada hospedado no Azure. • Estratégias de implantação flexíveis gerenciadas pelo controlador ou traga seu próprio Application Gateway for Containers. • Recursos avançados de gerenciamento de tráfego, como tentativas automáticas, resiliência da zona de disponibilidade, autenticação mútua (mTLS) para o alvo de back-end, divisão de tráfego / round robin ponderado e dimensionamento automático. • Integração com o Azure Key Vault para gestão de certificados. • Integração com Zonas DNS do Azure para gestão de DNS público e privado. • Suporta as APIs de entrada e gateway. |
| Istio Ingress Gateway | • Com base no Envoy, ao usar com o Istio para uma malha de serviço. • Recursos avançados de gerenciamento de tráfego, como limitação de taxa e circuit breaking. • Suporte para mTLS • Suporta a API do Gateway. |
Criar um recurso de Ingresso
O complemento de roteamento de aplicativos é a maneira recomendada de configurar um controlador Ingress no AKS. O complemento de roteamento de aplicativo é um controlador de entrada totalmente gerenciado para o Serviço Kubernetes do Azure (AKS) que fornece os seguintes recursos:
Fácil configuração de controladores NGINX Ingress gerenciados baseados no controlador Kubernetes NGINX Ingress.
Integração com o DNS do Azure para gestão de zonas públicas e privadas.
Terminação SSL com certificados armazenados no Cofre da Chave do Azure.
Para obter mais informações sobre o complemento de roteamento de aplicativo, consulte Ingresso NGINX gerenciado com o complemento de roteamento de aplicativo.
Preservação do IP de origem do cliente
Configure seu controlador de entrada para preservar o IP de origem do cliente em solicitações para contêineres em seu cluster AKS. Quando o controlador de entrada roteia a solicitação de um cliente para um contêiner no cluster AKS, o IP de origem original dessa solicitação não está disponível para o contêiner de destino. Quando você habilita a preservação do IP de origem do cliente, o IP de origem do cliente está disponível no cabeçalho da solicitação em X-Forwarded-For.
Se você estiver usando a preservação de IP de origem do cliente em seu controlador de entrada, não poderá usar a passagem TLS. A preservação do IP de origem do cliente e a passagem TLS podem ser usadas com outros serviços, como o tipo LoadBalancer .
Para saber mais sobre a preservação do IP de origem do cliente, consulte Como funciona a preservação do IP de origem do cliente para os Serviços LoadBalancer no AKS.
Controlar o tráfego de saída (saída)
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. Essas dependências de saída são quase inteiramente definidas com FQDNs (nomes de domínio totalmente qualificados). 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, 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 você cria Serviços, como um LoadBalancer, a plataforma Azure configura automaticamente todas as regras de grupo de segurança de rede necessárias.
Não precisa de configurar manualmente as regras do grupo de segurança de rede para filtrar o tráfego para os pods num cluster do AKS. Você pode definir quaisquer portas e encaminhamento necessários como parte de seus manifestos do Serviço Kubernetes e permitir que a plataforma Azure crie ou atualize as regras apropriadas.
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.
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 AKS, as políticas de rede são uma maneira mais adequada e nativa da nuvem de controlar o fluxo de tráfego para pods. Como os pods são criados dinamicamente em um cluster AKS, as políticas de rede necessárias podem ser aplicadas automaticamente.
Para obter mais informações, consulte Proteger o tráfego entre pods usando políticas de rede no Serviço Kubernetes do Azure (AKS).
Próximos passos
Para começar a usar a rede AKS, crie e configure um cluster AKS com seus próprios intervalos de endereços IP usando kubenet 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: