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:
- 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 de rede virtual do Azure onde os nós AKS são implantados. Este modelo permite uma escalabilidade mais simples e melhorada quando comparado com o modelo de rede plana.
- Modelo de rede simples: um modelo de rede simples no AKS atribui endereços IP a pods de uma sub-rede da mesma rede virtual do Azure que os nós AKS. Qualquer tráfego que saia de seus clusters não é SNAT'd, e o endereço IP do pod é diretamente exposto ao destino. Este modelo pode ser útil para cenários como a exposição de endereços IP pod a serviços externos.
Para obter mais informações sobre modelos de rede no AKS, consulte Rede CNI no AKS.
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: