Conceitos de rede de contêiner
Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server
Os componentes do aplicativo devem trabalhar juntos para processar suas tarefas em uma abordagem de microsserviços baseada em contêiner. O Kubernetes fornece recursos que permitem a comunicação de aplicativos e permitem que você se conecte e exponha aplicativos interna ou externamente. Você pode balancear a carga de seus aplicativos para criar aplicativos altamente disponíveis.
Aplicativos mais complexos podem exigir a configuração do tráfego de entrada para terminação SSL/TLS ou roteamento de vários componentes. Você também pode precisar restringir o fluxo de tráfego de rede para ou entre pods e nós para segurança.
Este artigo apresenta os principais conceitos que fornecem rede para seus aplicativos no AKS habilitados pelo Arc:
- Serviços de Kubernetes
- Controlador de entrada
- Políticas de rede
Serviços de Kubernetes
Para simplificar a configuração de rede para cargas de trabalho de aplicativos, o Kubernetes usa serviços para agrupar logicamente um conjunto de pods e fornecer conectividade de rede. Os seguintes tipos de serviço estão disponíveis:
IP do cluster: cria um endereço IP interno para uso no cluster do Kubernetes. Use o IP do cluster para aplicativos somente internos que dão suporte a outras cargas de trabalho dentro do cluster.
NodePort: cria um mapeamento de porta no nó subjacente que permite que o aplicativo seja acessado diretamente com o endereço IP e a porta do nó.
LoadBalancer: cria um recurso do balanceador de carga do Azure, configura um endereço IP externo e conecta os pods solicitados ao pool de back-end do balanceador de carga. Para permitir que o tráfego de clientes alcance o aplicativo, as regras de balanceamento de carga são criadas nas portas desejadas.
Para outro controle e roteamento do tráfego de entrada, você pode usar um controlador de entrada.
Observação
Quando você implanta um cluster de destino que compartilha uma rede com outro cluster de destino, há a possibilidade de um conflito de endereço IP do balanceador de carga.
Isso pode acontecer se você implantar duas cargas de trabalho que usam portas diferentes em clusters de destino que compartilham o mesmo AksHciClusterNetwork objeto. Devido à maneira como os endereços IP e os mapeamentos de porta são alocados dentro do Proxy HA, isso pode levar a uma atribuição de endereço IP duplicada. Se isso ocorrer, uma ou ambas as cargas de trabalho poderão encontrar problemas aleatórios de conectividade de rede até que você reimplante suas cargas de trabalho. Ao reimplantar suas cargas de trabalho, você pode usar a mesma porta que faz com que cada carga de trabalho receba um endereço IP de serviço separado ou pode reimplantar suas cargas de trabalho em clusters de destino que usam objetos diferentes AksHciClusterNetwork .
ExternalName: cria uma entrada DNS específica para facilitar o acesso ao aplicativo. Os endereços IP para balanceadores de carga e serviços podem ser endereços internos ou externos, dependendo da configuração geral da rede, e podem ser atribuídos dinamicamente. Ou você pode especificar um endereço IP estático existente a ser usado. Um endereço IP estático existente geralmente está vinculado a uma entrada DNS. Balanceadores de carga internos só são atribuídos a um endereço IP privado, portanto, não podem ser acessados da Internet.
Noções básicas de rede do Kubernetes no Azure Local
Para permitir o acesso aos seus aplicativos, ou para os componentes do aplicativo se comunicarem uns com os outros, o Kubernetes fornece uma camada de abstração para a rede virtual. Os nós do Kubernetes são conectados à rede virtual e podem fornecer conectividade de entrada e saída para pods. O componente kube-proxy em execução em cada nó fornece esses recursos de rede.
No Kubernetes, os serviços agrupam logicamente os pods para permitir:
- Acesso direto por meio de um único endereço IP ou nome DNS e uma porta específica.
- Distribua o tráfego usando um balanceador de carga entre vários pods que hospedam o mesmo serviço ou aplicativo.
A plataforma local do Azure também ajuda a simplificar a rede virtual para o AKS em clusters locais do Azure, fornecendo a rede "subjacente" de maneira altamente disponível.
Quando você cria um cluster do AKS, também criamos e configuramos um recurso de balanceador de carga subjacente HAProxy . À medida que você implanta aplicativos em um cluster do Kubernetes, os endereços IP são configurados para seus pods e serviços do Kubernetes como endpoints nesse balanceador de carga.
Recursos de endereço IP
Para simplificar a configuração de rede para cargas de trabalho de aplicativo, o AKS Arc atribui endereços IP aos seguintes objetos em uma implantação:
- Servidor de API de cluster do Kubernetes: o servidor de API é um componente do plano de controle do Kubernetes que expõe a API do Kubernetes. O servidor de API é o front-end do painel de controle do Kubernetes. Os endereços IP estáticos são sempre alocados para servidores de API, independentemente do modelo de rede subjacente.
- Nós do Kubernetes (máquinas virtuais): um cluster do Kubernetes consiste em um conjunto de máquinas de trabalho, chamadas de nós, e os nós hospedam aplicativos em contêineres. Além dos nós do plano de controle, cada cluster tem pelo menos um nó de trabalho. Para um cluster do AKS, os nós do Kubernetes são configurados como máquinas virtuais. Essas máquinas virtuais são criadas como máquinas virtuais altamente disponíveis no Azure Local, para obter mais informações, consulte Conceitos de rede de nó.
- Serviços do Kubernetes: no Kubernetes, os serviços agrupam logicamente os endereços IP do pod para permitir o acesso direto por meio de um único endereço IP ou nome DNS em uma porta específica. Os serviços também podem distribuir o tráfego usando um balanceador de carga. Os endereços IP estáticos são sempre alocados aos serviços do Kubernetes, independentemente do modelo de rede subjacente.
- Balanceadores de carga HAProxy: O HAProxy é um balanceador de carga TCP/HTTP e servidor proxy que distribui as solicitações recebidas em vários endpoints. Cada cluster de carga de trabalho em uma implantação local do AKS no Azure tem um balanceador de carga HAProxy implantado e configurado como uma máquina virtual especializada.
- Serviço de Nuvem Local da Microsoft: esse é o provedor de nuvem local do Azure que permite a criação e o gerenciamento do ambiente virtualizado que hospeda o Kubernetes em um cluster local do Azure Local ou cluster do Windows Server. O modelo de rede seguido pelo cluster local do Azure ou do Windows Server determina o método de alocação de endereço IP usado pelo Serviço de Nuvem Local da Microsoft. Para saber mais sobre os conceitos de rede implementados pelo Serviço de Nuvem Local da Microsoft, consulte Conceitos de rede de nó.
Redes do Kubernetes
No AKS no Azure Local, você pode implantar um cluster que usa um dos seguintes modelos de rede:
- Rede de sobreposição de flanela - Os recursos de rede normalmente são criados e configurados à medida que o cluster é implantado.
- Rede do Project Calico - Este modelo oferece recursos de rede adicionais, como políticas de rede e controle de fluxo.
Ambas as implementações de rede usam um modelo de configuração de rede de sobreposição, que fornece uma atribuição de endereço IP desconectada do restante da rede do data center.
Para saber mais sobre a rede de sobreposição, consulte Introdução: Rede de sobreposição do Kubernetes para Windows.
Para obter mais informações sobre o plug-in e as políticas do Calico Network, confira introdução à política de rede do Calico.
Comparando modelos de rede
Flanela
Observação
A Flannel CNI foi aposentada em dezembro de 2023.
Flannel é uma camada de rede virtual projetada especificamente para contêineres. O Flannel cria uma rede simples que se sobrepõe à rede do host. Todos os contêineres/pods recebem um endereço IP nessa rede de sobreposição e se comunicam diretamente conectando-se ao endereço IP uns dos outros.
Calico
O Calico é uma solução de rede e segurança de rede de código aberto para contêineres, máquinas virtuais e cargas de trabalho nativas baseadas em host. O Calico oferece suporte a vários planos de dados, incluindo: um plano de dados eBPF do Linux, um plano de dados de rede do Linux e um plano de dados do Windows HNS.
Funcionalidades
| Funcionalidade | Flanela | Calico |
|---|---|---|
| Políticas de Rede | Não | Sim |
| IPv6 | Não | Sim |
| Camadas usadas | L2 (VxLAN) | L2 (VxLAN) |
| Implantar cluster em uma rede virtual nova ou existente | Sim | Sim |
| Suporte do Windows | Sim | Sim |
| Conexão Pod-Pod | Sim | Sim |
| Conexão pod-VM, VM na mesma rede | Não | Sim |
| Conexão pod-VM, VM em rede diferente | Sim | Sim |
| Serviços Kubernetes | Sim | Sim |
| Expor por meio do balanceador de carga | Sim | Sim |
| Redes | Muitas redes no mesmo cluster com vários daemon | Muitas redes no mesmo cluster |
| Implantação | Linux: DaemonSet | Linux: DaemonSet |
| Windows: Serviço | Windows: Serviço | |
| Linha de comando | nenhum | Calicoctl |
Importante
Atualmente, a seleção padrão é usar o Calico em um modo de rede de sobreposição. Para habilitar o Flannel, use o -primaryNetworkPlugin parâmetro do New-AksHciCluster comando do PowerShell e especifique flannel como o valor. Esse valor não pode ser alterado após a implantação do cluster e se aplica aos nós de cluster do Windows e do Linux.
Por exemplo:
New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'
Próximas etapas
Este artigo aborda conceitos de rede para contêineres em nós do AKS no Azure Local. Para obter mais informações sobre os conceitos do AKS no Azure Local, consulte os seguintes artigos: