Conceitos de rede para aplicações no Azure Kubernetes Service (AKS)
Numa abordagem de microsserviços baseada em contentores para o desenvolvimento de aplicações, os componentes da aplicação trabalham em conjunto para processar as suas tarefas. O Kubernetes fornece vários recursos que permitem esta cooperação:
- Pode ligar e expor aplicações interna ou externamente.
- Pode criar aplicações de elevada disponibilidade ao balancear a carga das suas aplicações.
- Pode restringir o fluxo de tráfego de rede para ou entre pods e nós para melhorar a segurança.
- Pode configurar o tráfego de Entrada 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 às suas aplicações no AKS:
Noções básicas do Kubernetes
Para permitir o acesso às suas aplicações ou entre componentes da aplicação, o Kubernetes fornece uma camada de abstração para redes virtuais. Os nós do Kubernetes ligam-se a uma rede virtual, fornecendo conectividade de entrada e saída para pods. O componente kube-proxy é executado em cada nó para fornecer estas funcionalidades de rede.
No Kubernetes:
- Os serviços agrupam logicamente pods para permitir o acesso direto numa porta específica através de um endereço IP ou nome DNS.
- Os ServiceTypes permitem-lhe especificar o tipo de Serviço que pretende.
- Pode distribuir o tráfego através de um balanceador de carga.
- O encaminhamento de camada 7 do tráfego da aplicação também pode ser alcançado com controladores de entrada.
- Pode controlar o tráfego de saída (saída) para nós de cluster.
- A segurança e a filtragem do tráfego de rede para pods é possível com as políticas de rede.
A plataforma do Azure também simplifica as redes virtuais para clusters do AKS. Quando cria um balanceador de carga do Kubernetes, também cria e configura o recurso do balanceador de carga subjacente do Azure. À medida que abre portas de rede para pods, as regras do grupo de segurança de rede do Azure correspondentes são configuradas. Para o encaminhamento de aplicações HTTP, o Azure também pode configurar o DNS externo à medida que são configuradas novas rotas de entrada.
Serviços
Para simplificar a configuração de rede para cargas de trabalho de aplicações, o Kubernetes utiliza Serviços para agrupar logicamente um conjunto de pods e fornecer conectividade de rede. Pode especificar um ServiceType do Kubernetes para especificar o tipo de Serviço que pretende, por exemplo, se quiser expor um Serviço num endereço IP externo que esteja fora do cluster. Para obter mais informações, veja a documentação do Kubernetes para Serviços de Publicação (ServiceTypes).
Estão disponíveis os seguintes ServiceTypes:
ClusterIP
O ClusterIP cria um endereço IP interno para utilização no cluster do AKS. Este Serviço é bom para aplicações apenas internas que suportam outras cargas de trabalho no cluster. Esta é a predefinição utilizada se não especificar explicitamente um tipo para um Serviço.
NodePort
O NodePort cria um mapeamento de porta no nó subjacente que permite que a aplicação seja acedida diretamente com o endereço IP e a porta do nó.
LoadBalancer
O LoadBalancer cria um recurso de balanceador de carga do Azure, configura um endereço IP externo e liga os pods pedidos ao conjunto de back-end do balanceador de carga. Para permitir que o tráfego dos clientes chegue à aplicação, são criadas regras de balanceamento de carga nas portas pretendidas.
Para o balanceamento de carga HTTP do tráfego de entrada, outra opção é utilizar um controlador de Entrada.
ExternalName
Cria uma entrada DNS específica para facilitar o acesso à aplicação.
Os balanceadores de carga e o endereço IP dos serviços podem ser atribuídos dinamicamente ou pode especificar um endereço IP estático existente. Pode atribuir endereços IP estáticos internos e externos. Os endereços IP estáticos existentes estão frequentemente associados a uma entrada DNS.
Pode criar balanceadores de carga internos e externos . Os balanceadores de carga internos só recebem um endereço IP privado, pelo que não podem ser acedidos a partir da Internet.
Saiba mais sobre os Serviços nos documentos do Kubernetes.
Redes virtuais do Azure
No AKS, pode implementar um cluster que utiliza um dos seguintes modelos de rede:
Rede do Kubenet
Normalmente, os recursos de rede são criados e configurados à medida que o cluster do AKS é implementado.
Rede do Azure Container Networking Interface (CNI)
o cluster do AKS está associado aos recursos e configurações existentes da rede virtual.
Rede do Kubenet (básico)
A opção de rede kubenet é a configuração predefinida para a criação de clusters do AKS. Com o kubenet:
- Os nós recebem um endereço IP da sub-rede da rede virtual do Azure.
- Os pods recebem um endereço IP de um espaço de endereços logicamente diferente da sub-rede da 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 é traduzido para o endereço IP principal do nó.
Os nós utilizam o plug-in kubenet Kubernetes. Pode permitir que a plataforma do Azure crie e configure as redes virtuais por si ou opte por implementar o cluster do AKS numa sub-rede de rede virtual existente.
Apenas os nós recebem um endereço IP encaminhável. Os pods utilizam NAT para comunicar com outros recursos fora do cluster do AKS. Esta abordagem reduz o número de endereços IP que precisa de reservar no espaço de rede para os pods utilizarem.
Nota
Embora o kubenet seja a opção de rede predefinida para um cluster do AKS criar uma rede virtual e uma sub-rede, não é recomendado para implementações de produção. Para a maioria das implementações de produção, deve planear e utilizar as redes CNI do Azure devido às suas características de desempenho e escalabilidade superiores.
Para obter mais informações, veja Configurar a rede kubenet para um cluster do AKS.
Redes CNI do Azure (avançadas)
Com o Azure CNI, cada pod obtém um endereço IP da sub-rede e pode ser acedido diretamente. Estes endereços IP têm de ser planeados com antecedência e exclusivos em todo o espaço de rede. Cada nó tem um parâmetro de configuração para o número máximo de pods suportado. O número equivalente de endereços IP por nó é, em seguida, reservado antecipadamente. Esta abordagem pode levar ao esgotamento do endereço IP ou à necessidade de reconstruir clusters numa sub-rede maior à medida que a sua aplicação exige um crescimento, pelo que é importante planear corretamente. Para evitar estes desafios de planeamento, é possível ativar a funcionalidade rede CNI do Azure para alocação dinâmica de IPs e suporte de sub-rede melhorado.
Ao contrário do kubenet, o tráfego para pontos finais na mesma rede virtual não é NAT'd 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 continua a ser NATs para o IP primário do nó.
Os nós utilizam o plug-in kubernetes do Azure CNI .
Para obter mais informações, veja Configurar o Azure CNI para um cluster do AKS.
Azure CNI overlay networking (Sobreposição de redes do Azure CNI)
A Sobreposição do Azure CNI representa uma evolução da CNI do Azure, abordando os desafios de escalabilidade e planeamento resultantes da atribuição de IPs de VNet a pods. Consegue-o ao atribuir IPs CIDR privados a pods, que são separados da VNet e podem ser reutilizados em vários clusters. Ao contrário do Kubenet, onde o plano de dados de tráfego é processado pela pilha de rede de kernel do Linux dos nós do Kubernetes, a Sobreposição do CNI do Azure delega esta responsabilidade à rede do Azure.
Azure CNI com Tecnologia Cilium
No Azure CNI Com tecnologia Cilium, o plano de dados para Pods é gerido pelo kernel do Linux dos nós do Kubernetes. Ao contrário do Kubenet, que enfrenta problemas de escalabilidade e desempenho com a pilha de rede de kernel do Linux, [Cilium][https://cilium.io/] ignora a pilha de rede de kernel do Linux e, em vez disso, tira partido dos programas eBPF no Kernel do Linux para acelerar o processamento de pacotes para um desempenho mais rápido.
Traga o seu próprio CNI
É possível instalar no AKS um CNI de terceiros através da funcionalidade Traga a sua própria CNI .
Comparar modelos de rede
Tanto o Kubenet como o Azure CNI fornecem conectividade de rede para os clusters do AKS. No entanto, existem vantagens e desvantagens para cada uma. A um nível elevado, aplicam-se as seguintes considerações:
kubenet
- Conserva o espaço de endereços IP.
- Utiliza balanceadores de carga internos ou externos do Kubernetes para aceder a pods de fora do cluster.
- Pode gerir e manter manualmente rotas definidas pelo utilizador (UDRs).
- Máximo de 400 nós por cluster.
Azure CNI
- Os pods obtêm conectividade de rede virtual completa e podem ser acedidos diretamente através do respetivo endereço IP privado a partir de redes ligadas.
- Requer mais espaço de endereços IP.
Existem as seguintes diferenças de comportamento entre o kubenet e o Azure CNI:
| Funcionalidade | Kubenet | Azure CNI | Sobreposição do Azure CNI | Azure CNI com Tecnologia Cilium |
|---|---|---|---|---|
| Implementar um cluster numa rede virtual existente ou nova | 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 de ambas as formas | Funciona quando iniciado por pod | Funciona quando iniciado por pod |
| Conectividade pod-VM; VM na rede virtual em modo de peering | Funciona quando iniciado por pod | Funciona de ambas as formas | Funciona quando iniciado por pod | Funciona quando iniciado por pod |
| Acesso no local com VPN ou Express Route | Funciona quando iniciado por pod | Funciona de ambas as formas | Funciona quando iniciado por pod | Funciona quando iniciado por pod |
| Expor os serviços do Kubernetes através de um serviço de balanceador de carga, gateway de aplicação ou controlador de entrada | Suportado | Suportado | Sem suporte do Controlador de Entrada do Gateway de Aplicação (AGIC) | As mesmas limitações ao utilizar o modo de Sobreposição |
| Suporte para conjuntos de nós do Windows | Não suportado | Suportado | Suportado | Disponível apenas para Linux e não para Windows. |
No que diz respeito ao DNS, com os plug-ins do Kubenet e do Azure CNI, o DNS é oferecido pelo CoreDNS, uma implementação em execução no AKS com o seu próprio dimensionador automático. Para obter mais informações sobre o CoreDNS no Kubernetes, veja Personalizar o Serviço DNS. Por predefinição, o CoreDNS está configurado para reencaminhar domínios desconhecidos para a funcionalidade DNS do Azure Rede Virtual onde o cluster do AKS é implementado. Assim, o DNS do Azure e as Zonas Privadas funcionarão para pods em execução no AKS.
Para obter mais informações sobre o Azure CNI e kubenet e para ajudar a determinar qual é a melhor opção para si, veja Configurar redes CNI do Azure no AKS e Utilizar redes kubenet no AKS.
Âmbito de suporte entre modelos de rede
Seja qual for o modelo de rede que utilizar, o kubenet e o Azure CNI podem ser implementados de uma das seguintes formas:
- A plataforma do Azure pode criar e configurar automaticamente os recursos de rede virtual quando cria um cluster do AKS.
- Pode criar e configurar manualmente os recursos de rede virtual e anexar a esses recursos quando criar o cluster do AKS.
Embora as capacidades, como pontos finais de serviço ou UDRs, sejam suportadas com o kubenet e o Azure CNI, as políticas de suporte para o AKS definem as alterações que pode fazer. Por exemplo:
- Se criar manualmente os recursos de rede virtual para um cluster do AKS, é suportado quando configurar os seus próprios UDRs ou pontos finais de serviço.
- Se a plataforma do Azure criar automaticamente os recursos de rede virtual para o cluster do AKS, não poderá alterar manualmente esses recursos geridos pelo AKS para configurar os seus próprios UDRs ou pontos finais de serviço.
Controladores de entrada
Quando cria um Serviço do tipo LoadBalancer, também cria um recurso de balanceador de carga do Azure subjacente. O balanceador de carga está configurado para distribuir o tráfego para os pods no seu Serviço numa determinada porta.
O LoadBalancer só funciona na camada 4. Na camada 4, o Serviço desconhece as aplicações reais e não pode fazer mais considerações de encaminhamento.
Os controladores de entrada funcionam na camada 7 e podem utilizar regras mais inteligentes para distribuir o tráfego da aplicação. Normalmente, os controladores de entrada encaminham o tráfego HTTP para diferentes aplicações com base no URL de entrada.
Criar um recurso de Entrada
No AKS, pode criar um recurso de Entrada com o NGINX, uma ferramenta semelhante ou a funcionalidade de encaminhamento de aplicações HTTP do AKS. Quando ativa o encaminhamento de aplicações HTTP para um cluster do AKS, a plataforma do Azure cria o controlador de entrada e um controlador External-DNS . À medida que são criados novos recursos de Entrada no Kubernetes, os registos DNS A necessários são criados numa zona DNS específica do cluster.
Para obter mais informações, veja Implementar o encaminhamento de aplicações HTTP.
Controlador de Entrada do Gateway de Aplicação (AGIC)
Com o suplemento controlador de entrada do Gateway de Aplicação (AGIC), pode utilizar o balanceador de carga de nível 7 de Gateway de Aplicação nativo do Azure para expor o software da cloud à Internet. O AGIC é executado como um pod no cluster do AKS. Consome Recursos de Entrada do Kubernetes e converte-os numa configuração de Gateway de Aplicação, o que permite que o gateway faça o balanceamento de carga do tráfego para os pods do Kubernetes.
Para saber mais sobre o suplemento AGIC para o AKS, veja O que é Gateway de Aplicação Controlador de Entradas?.
Terminação SSL/TLS
A terminação SSL/TLS é outra funcionalidade comum da Entrada. Em aplicações Web grandes acedidas através de HTTPS, o recurso de Entrada processa a terminação TLS em vez de dentro da própria aplicação. Para fornecer a geração e configuração automáticas de certificação TLS, pode configurar o recurso de Entrada para utilizar fornecedores como "Let's Encrypt".
Para obter mais informações sobre como configurar um controlador de entrada NGINX com Let's Encrypt, veja Ingress and TLS (Entrada e TLS).
Preservação do IP de origem do cliente
Configure o controlador de entrada para preservar o IP de origem do cliente nos pedidos para contentores no cluster do AKS. Quando o controlador de entrada encaminha o pedido de um cliente para um contentor no cluster do AKS, o IP de origem original desse pedido não está disponível para o contentor de destino. Quando ativa a preservação do IP de origem do cliente, o IP de origem do cliente está disponível no cabeçalho do pedido em X-Forwarded-For.
Se estiver a utilizar a preservação do IP de origem do cliente no controlador de entrada, não poderá utilizar a passagem do TLS. A preservação do IP de origem do cliente e o pass-through TLS podem ser utilizados com outros serviços, como o tipo LoadBalancer .
Para saber mais sobre a preservação do IP de origem do cliente, veja 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 do AKS são implementados numa rede virtual e têm dependências de saída em serviços fora dessa rede virtual. Estas dependências de saída são quase totalmente definidas com nomes de domínio completamente qualificados (FQDNs). Por predefinição, os clusters do AKS têm acesso à Internet de saída (saída) sem restrições, o que permite que os nós e serviços executados acedam a recursos externos conforme necessário. Se pretender, pode restringir o tráfego de saída.
Para obter mais informações, veja Controlar o tráfego de saída dos 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 cria Serviços, como um LoadBalancer, a plataforma do 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. Pode definir todas as portas necessárias e reencaminhar como parte dos seus manifestos do Kubernetes Service e permitir que a plataforma do Azure crie ou atualize as regras adequadas.
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, veja Como os grupos de segurança de rede filtram o tráfego de rede.
Políticas de rede
Por predefinição, todos os pods num cluster do AKS podem enviar e receber tráfego sem limitações. Para uma segurança melhorada, defina regras que controlam o fluxo de tráfego, como:
- As aplicações de back-end só são expostas a serviços front-end necessários.
- Os componentes da base de dados só estão acessíveis aos escalões de aplicação que se ligam aos mesmos.
A política de rede é uma funcionalidade do Kubernetes disponível no AKS que lhe permite controlar o fluxo de tráfego entre pods. Pode permitir ou negar o tráfego para o pod com base em definições como etiquetas atribuídas, espaço de nomes 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 de controlar o fluxo de tráfego dos pods. À medida que os pods são criados dinamicamente num cluster do AKS, as políticas de rede necessárias podem ser aplicadas automaticamente.
Para obter mais informações, veja Proteger o tráfego entre pods através de políticas de rede no Azure Kubernetes Service (AKS).
Passos seguintes
Para começar a utilizar a rede do AKS, crie e configure um cluster do AKS com os seus próprios intervalos de endereços IP com o kubenet ou a CNI do Azure.
Para obter as melhores práticas associadas, veja Melhores práticas para conectividade de rede e segurança no AKS.
Para obter mais informações sobre os principais conceitos do Kubernetes e do AKS, veja os seguintes artigos: