Conceitos de uso de rede para aplicativos no Serviço de Kubernetes do Azure (AKS)
Em uma abordagem de microsserviços baseada em contêiner para o desenvolvimento de aplicativos, os componentes de 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 internamente ou externamente.
- Para criar aplicativos altamente disponíveis, você pode balancear a carga de seus aplicativos.
- Você também pode precisar restringir o fluxo de tráfego de rede em pods e nós ou entre eles para melhorar a segurança.
- Aplicativos mais complexos podem exigir a configuração de tráfego de entrada para terminação SSL/TLS ou o roteamento de múltiplos componentes.
Este artigo apresenta os principais conceitos que fornecem rede para seus aplicativos no AKS:
Noções básicas de uso 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 os pods (unidades básicas de implantação no Kubernetes) tenham conectividade tanto de entrada quanto de saída.
Componente Kube-proxy: o Kube-proxy é executado em cada nó e é responsável por fornecer os recursos de rede necessários.
No que se refere a 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 Entrada: 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 que você gerencie e controle o tráfego de saída dos nós de um cluster.
- Políticas de rede: essas políticas habilitam medidas de segurança e filtragem para o tráfego de rede em pods.
No contexto da plataforma do Azure:
- O Azure simplifica a rede virtual para clusters do AKS (Serviço de Kubernetes do Azure).
- A criação de um balanceador de carga do Kubernetes no Azure configura simultaneamente o recurso de balanceador de carga do Azure correspondente.
- À medida que você abre portas de rede para os 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 modelos de rede a seguir:
Rede Kubenet
Os recursos de rede normalmente são criados e configurados enquanto o cluster AKS é implantado.
Rede da CNI (Interface de Rede de Contêiner do Azure)
o cluster do AKS está conectado a recursos e configurações de rede virtual existentes.
Rede Kubenet (básica)
A opção de rede kubenet é a configuração padrão para a criação do cluster AKS. Com o kubenet:
- Os nós recebem um endereço IP de uma sub-rede da rede virtual do Azure.
- Os pods recebem um endereço IP de um espaço de endereço logicamente diferente da sub-rede da rede virtual do Azure dos nós.
- A NAT (Conversão de Endereços de Rede) é configurada para que os pods possam alcançar recursos na rede virtual do Azure.
- O endereço IP de origem do tráfego é convertido no endereço IP primário do nó.
Os nós usam o plug-in kubenet do Kubernetes. Você pode permitir que a plataforma do Azure crie e configure as redes virtuais para você ou pode optar por implantar o cluster do AKS em uma sub-rede da rede virtual existente.
Apenas os nós recebem um endereço IP roteável. Os pods usam NAT para se comunicarem com outros recursos fora do cluster AKS. Essa abordagem reduz o número de endereços IP que você precisa reservar no espaço de rede para uso dos pods.
Observação
Embora o kubenet seja a opção de sistema de rede padrão para um cluster do AKS para criar uma rede e uma sub-rede virtuais, ele não é recomendado para implantações em produção. Para a maioria das implantações de produção, você deve planejar e usar o sistema de 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 da CNI do Azure (avançada)
Com a CNI do Azure, cada pod obtém um endereço IP da sub-rede e pode ser acessado diretamente. Esses endereços IP devem ser exclusivos em todo o seu espaço de rede e devem ser planejados com antecedência. Cada nó tem um parâmetro de configuração para o número máximo de pods aos quais ele dá suporte. O número equivalente de endereços IP por nó é então reservado antecipadamente. Essa abordagem pode levar à exaustão do endereço IP ou à necessidade de recriar os clusters em uma sub-rede maior, conforme as demandas de aplicativo aumentam, portanto, o planejamento é importante. Para evitar esses desafios de planejamento, é possível habilitar o recurso Rede CNI do Azure para alocação dinâmica de IPs e suporte aprimorado à sub-rede.
Observação
Devido às limitações do Kubernetes, o nome do Grupo de Recursos, o nome da Rede Virtual e o nome da sub-rede precisam ter 63 caracteres ou menos.
Ao contrário do Kubenet, o tráfego para pontos de extremidade na mesma rede virtual não é convertido (NAT) para o IP primário do nó. O endereço de origem para o tráfego dentro da rede virtual é o IP do pod. O tráfego externo à rede virtual ainda é de NATs para o IP primário do nó.
Os nós usam o plug-in Kubernetes da CNI do Azure.
Para obter mais informações, consulte Configurar a CNI do Azure para um cluster AKS.
Sistema de rede de Sobreposição da CNI do Azure
A Sobreposição de CNI do Azure representa uma evolução do CNI do Azure, abordando os desafios de escalabilidade e planejamento decorrentes da atribuição de IPs de VNet para pods. A Sobreposição de CNI do Azure atribui IPs CIDR privados aos pods. Os IPs privados são separados da rede virtual e podem ser reusados em vários clusters. A Sobreposição de CNI do Azure pode ser dimensionada além do limite de 400 nós imposto nos clusters do Kubenet. A Sobreposição da CNI do Azure é a opção recomendada para a maioria dos clusters.
CNI do Azure da plataforma Cilium
O CNI do Azure da plataforma Cilium utiliza o Cilium para fornecer sistema de rede de alto desempenho, observabilidade e imposição de políticas de rede. Ele se integra nativamente à Sobreposição de CNI do Azure para o gerenciamento escalonável de endereço de IP (IPAM).
Além disso, a Cilium impõe políticas de rede por padrão, sem exigir um mecanismo de política de rede separado. O CNI do Azure Alimentado pelo Cilium pode ser dimensionado além dos Limites do Gerenciador de Políticas de Rede do Azure de 250 nós/20 mil pods usando programas ePBF e uma estrutura de objeto de API mais eficiente.
A CNI do Azure da plataforma Cilium é a opção recomendada para clusters que exigem imposição de políticas de rede.
Traga seu próprio CNI
É possível instalar no AKS um CNI que não seja da Microsoft usando o recurso Traga sua própria CNI.
Comparar modelos de rede
O kubenet e o CNI do Azure fornecem conectividade de rede para seus clusters AKS. Há vantagens e desvantagens em cada método. Em um alto nível, as seguintes considerações se aplicam:
kubenet
- Conserva o espaço do endereço IP.
- Usa os balanceadores de carga internos ou externos do Kubernetes para alcançar pods fora do cluster.
- Você gerencia e mantém manualmente as UDRs (rotas definidas pelo usuário).
- Máximo de 400 nós por cluster.
CNI do Azure
- Os pods têm conectividade total da rede virtual e podem ser diretamente acessados por meio de seu endereço IP privado de redes conectadas.
- Requer mais espaço do endereço IP.
| Modelo de rede | Quando usar |
|---|---|
| Kubenet | • A conversa de espaço de endereço de 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. • O gerenciamento manual e manutenção de rotas definidas pelo usuário é aceitável. |
| CNI do Azure | • A conectividade de rede virtual completa é necessária para os pods. • Os recursos avançados do AKS (como nós virtuais) são necessários. • O espaço de endereço de IP suficiente está disponível. • O pod para pod e o pod para conectividade de máquina virtual é necessário. • Os recursos externos precisam acessar os pods diretamente. • As políticas de rede do AKS são necessárias. |
| Sobreposição de CNI do Azure | • A escassez de endereços de IP é uma preocupação. • O dimensionamento de até 1.000 nós e 250 pods por nó é suficiente. • O salto extra para conectividade de pod é aceitável. • Configuração de rede mais simples. • Os requisitos de saída do AKS podem ser atendidos. |
Existem as seguintes diferenças de comportamento entre kubenet e CNI do Azure:
| Funcionalidade | Kubenet | CNI do Azure | Sobreposição de CNI do Azure | CNI do Azure da plataforma Cilium |
|---|---|---|---|---|
| Implantar cluster em uma rede virtual nova ou existente | Com suporte - UDRs aplicadas manualmente | Com suporte | Compatível | Com suporte |
| Conectividade pod-pod | Com suporte | Compatível | Compatível | Com suporte |
| Conectividade pod-VM; VM na mesma rede virtual | Funciona quando iniciado pelo pod | Funciona das duas maneiras | Funciona quando iniciado pelo pod | Funciona quando iniciado pelo pod |
| Conectividade pod-VM; VM em rede virtual associada | Funciona quando iniciado pelo pod | Funciona das duas maneiras | Funciona quando iniciado pelo pod | Funciona quando iniciado pelo pod |
| Acesso local usando VPN ou Express Route | Funciona quando iniciado pelo pod | Funciona das duas maneiras | Funciona quando iniciado pelo pod | Funciona quando iniciado pelo pod |
| Acesso a recursos protegidos por pontos de extremidade do serviço | Com suporte | Compatível | Com suporte | |
| Expor serviços Kubernetes usando um serviço de balanceador de carga, um gateway de aplicativo ou um controlador de entrada | Com suporte | Compatível | Com suporte | As mesmas limitações ao utilizar o modo Sobreposição |
| Suporte para pools Windows nós | Sem suporte | Com suporte | Com suporte | Disponível apenas para Linux e não para Windows. |
| Zonas privadas e DNS do Azure padrão | Com suporte | Compatível | Com suporte |
Para obter mais informações sobre o CNI do Azure e kubenet e para ajudar a determinar qual opção é melhor 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
Independentemente do modelo de rede que você usa, tanto o kubenet quanto a CNI do Azure 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 da rede virtual e anexá-los a esses recursos ao criar o cluster AKS.
Embora haja suporte para recursos como pontos de extremidade de serviço ou UDRs com kubenet e CNI do Azure, 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 pontos de extremidade de serviço ou UDRs.
- Se a plataforma Azure criar automaticamente os recursos de rede virtual para o cluster AKS, não será possível alterar manualmente esses recursos gerenciados por AKS para que configurem suas próprias 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 de balanceador de carga subjacente do Azure. O balanceador de carga é configurado para distribuir o 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 nenhuma outra consideração de roteamento.
Os controladores de entrada funcionam na camada 7 e podem usar regras mais inteligentes para distribuir o tráfego de aplicativos. Os controladores de entrada costumam rotear 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 entrada:
| Recurso | Complemento de Roteamento de Aplicativos | Gateway de Aplicativo para contêineres | Malha de Serviço do Azure/malha de serviço baseada em Istio |
|---|---|---|---|
| Controlador de entrada/gateway | Controlador de entrada NGINX | Gateway de Aplicativo do Azure para contêineres | Gateway de entrada do Istio |
| API | API de Entrada | API de Entrada e API de Gateway | API do Gateway |
| Hosting | No cluster | Hospedado pelo Azure | No cluster |
| Dimensionamento | Dimensionamento automático | Dimensionamento automático | Dimensionamento automático |
| Balanceamento de carga | Interno/Externo | Externos | Interno/Externo |
| Terminação SSL | No cluster | Sim: Descarregamento e E2E SSL | No cluster |
| mTLS | N/D | Sim para back-end | N/D |
| Endereço IP Estático | N/D | FQDN | N/D |
| Certificados SSL armazenados do Azure Key Vault | Sim | Yes | N/D |
| Integração de DNS do Azure para gerenciamento de zona DNS | Sim | Yes | N/D |
A tabela a seguir lista os diferentes cenários em que você pode usar cada controlador de entrada:
| Opção de entrada | Quando usar |
|---|---|
| NGINX Gerenciado – complemento de Roteamento de Aplicativos | • Controladores de entrada NGINX hospedados no cluster, personalizáveis e escalonáveis. • Recursos básicos de balanceamento de carga e roteamento. • Configuração do balanceador de carga interno e externo. • Configuração de endereço IP estático. • Integração com o Azure Key Vault para gerenciamento de certificados. • Integração com as Zonas DNS do Azure para gerenciamento de DNS público e privado. • Dá suporte à API de Entrada. |
| Gateway de Aplicativos para Contêineres | • Gateway de entrada hospedado no Azure. • Estratégias de implantação flexíveis gerenciadas pelo controlador ou traga seu próprio Gateway de Aplicativos para Contêineres. • Recursos avançados de gerenciamento de tráfego, como repetições automáticas, resiliência de zona de disponibilidade, autenticação mútua (mTLS) para o destino de back-end, divisão de tráfego/round robin ponderado e dimensionamento automático. • Integração com o Azure Key Vault para gerenciamento de certificados. • Integração com as Zonas DNS do Azure para gerenciamento de DNS público e privado. • Dá suporte às APIs de Entrada e Gateway. |
| Gateway de Entrada do Istio | • Com base no Envoy, ao usar o Istio para uma malha de serviço. • Recursos avançados de gerenciamento de tráfego, como limitação de taxa e interrupção de circuito. • Suporte para mTLS • Dá suporte à API de Gateway. |
Criar um recurso de entrada
O complemento do roteamento de aplicativos é a maneira recomendada de configurar um controlador de entrada no AKS. O complemento do roteamento de aplicativos é um controlador de entrada totalmente gerenciado para o AKS (Serviço de Kubernetes do Azure) que fornece os seguintes recursos:
Configuração fácil de controladores de entrada NGINX gerenciados com base no controlador de entrada NGINX do Kubernetes.
Integração com o DNS do Azure para gerenciamento de zona pública e privada.
Terminação SSL com certificados armazenados no Azure Key Vault.
Para obter mais informações sobre o complemento de roteamento de aplicativos, consulte Entrada NGINX gerenciada com o complemento de roteamento de aplicativo.
Preservação de IP de origem do cliente
Configure o controlador de entrada para preservar o IP de origem do cliente em solicitações para contêineres no 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 dessa solicitação fica indisponível para o contêiner de destino. Quando você habilita a preservação de IP de origem do cliente, o IP de origem do cliente fica 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 passagem TLS. A preservação de IP de origem do cliente e a passagem de TLS podem ser usadas com outros serviços, como o tipo Balanceador de carga.
Para saber mais sobre a preservação do IP de origem do cliente, confira Como funciona a preservação do IP de origem do cliente para o LoadBalancer Services no AKS.
Controlar o tráfego de saída
Os clusters do 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 do AKS têm acesso irrestrito à Internet de saída (saída), o que permite que os nós e os serviços executados acessem recursos externos conforme necessário. Se desejado, você pode restringir o tráfego de saída.
Para obter mais informações, confira 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 do AKS. À medida que você cria Serviços, como um LoadBalancer, a plataforma do Azure configura automaticamente as regras do grupo de segurança de rede necessárias.
Você não precisa configurar manualmente as regras do grupo de segurança de rede para filtrar o tráfego de pods em um cluster do AKS. É possível definir as portas e o encaminhamento necessários como parte dos manifestos do Kubernetes Service e permita que a plataforma do Azure crie ou atualize as regras apropriadas.
Também é possível usar políticas de rede para aplicar automaticamente as regras de filtro de tráfego aos pods.
Para obter mais informações, consulte Como filtrar o tráfego de rede com grupos de segurança de rede.
Políticas de rede
Por padrão, todos os pods em um cluster do AKS podem enviar e receber tráfego sem limitações. Para melhorar a segurança,defina as regras que controlam o fluxo de tráfego, como:
- Os aplicativos de back-end são expostos apenas aos serviços de front-end necessários.
- Os componentes de banco de dados só são acessíveis para as camadas de aplicativo que se conectam a eles.
A política de rede é um recurso de Kubernetes disponível no AKS que permite controlar o fluxo de tráfego entre os pods. Você pode permitir ou negar o tráfego para o pod de acordo com as 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 maneira nativa de nuvem mais adequada para controlar o fluxo de tráfego para pods. Como os pods são criados dinamicamente em um cluster do AKS, as políticas de rede necessárias podem ser aplicadas automaticamente.
Para saber mais, confira Proteger o tráfego entre os pods usando as políticas de rede no AKS (Serviço de Kubernetes do Azure).
Próximas etapas
Para obter uma introdução à rede do AKS, crie e configure um cluster do AKS com seus próprios intervalos de endereços IP usando kubenet ou a CNI do Azure.
Para as melhores práticas associadas, consulte Melhores práticas conectividade e segurança da rede no AKS.
Para obter mais informações sobre os principais conceitos do Kubernetes e do AKS, confira os seguintes artigos: