evento
17/03, 21 - 21/03, 10
Junte-se à série meetup para criar soluções de IA escaláveis com base em casos de uso do mundo real com outros desenvolvedores e especialistas.
Registe-se agoraConceitos de rede de contêiner
Aplica-se a: AKS no Azure Local 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 comunicações com 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. Também pode ser necessário restringir o fluxo de tráfego de rede para ou entre pods e nós por segurança.
Este artigo apresenta os principais conceitos que fornecem rede para seus aplicativos no AKS habilitado pelo Arc:
- Serviços do Kubernetes
- Controlador de entradas
- Políticas de rede
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 dentro do cluster Kubernetes. Use o IP do cluster para aplicativos somente internos que oferecem 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 de 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 dos clientes chegue ao aplicativo, 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.
Nota
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 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 podem 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 para usar. Um endereço IP estático existente é frequentemente associado a uma entrada DNS. Os balanceadores de carga internos recebem apenas um endereço IP privado, portanto, não podem ser acessados pela Internet.
Para permitir o acesso aos seus aplicativos ou para que os componentes do aplicativo se comuniquem entre si, 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 através 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 Azure Local também ajuda a simplificar a rede virtual para AKS em clusters do Azure Local, fornecendo a rede "underlay" de uma forma altamente disponível.
Quando você cria um cluster AKS, também criamos e configuramos um recurso de balanceador de carga subjacente HAProxy . À medida que você implanta aplicativos em um cluster Kubernetes, os endereços IP são configurados para seus pods e serviços Kubernetes como pontos de extremidade nesse balanceador de carga.
Para simplificar a configuração de rede para cargas de trabalho de aplicativos, 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 para o plano de controle do Kubernetes. Os endereços IP estáticos são sempre alocados para servidores API, independentemente do modelo de rede subjacente.
- Nós do Kubernetes (máquinas virtuais): um cluster Kubernetes consiste em um conjunto de máquinas de trabalho, chamadas 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 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 Kubernetes: no Kubernetes, os Serviços agrupam logicamente endereços IP pod para permitir o acesso direto através 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.
- HAProxy load balancers: HAProxy é um balanceador de carga TCP/HTTP e servidor proxy que espalha solicitações de entrada em vários endpoints. Cada cluster de carga de trabalho em uma implantação AKS no Azure Local tem um balanceador de carga HAProxy implantado e configurado como uma máquina virtual especializada.
- Serviço de Nuvem Local da Microsoft: Este é 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 do Azure Local 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ó.
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 são normalmente criados e configurados à medida que o cluster é implantado.
- Projeto Calico networking - Este modelo oferece recursos adicionais de rede, 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 da Calico Network, confira Introdução à política de rede Calico.
Nota
Flannel CNI foi aposentado em dezembro de 2023.
Flannel é uma camada de rede virtual projetada especificamente para contêineres. Flannel cria uma rede plana que sobrepõe a rede 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.
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 suporta vários planos de dados, incluindo: um plano de dados Linux eBPF, um plano de dados de rede Linux e um plano de dados HNS do Windows.
| Funcionalidade | Flanela | Calico |
|---|---|---|
| Políticas de Rede | Não | Sim |
| IPv6 | Não | Sim |
| Camadas utilizadas | L2 (VxLAN) | L2 (VxLAN) |
| Implantar cluster em 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 do Kubernetes | Sim | Sim |
| Expor via Load balancer | Sim | Sim |
| Redes | Muitas redes no mesmo cluster com vários daemon | Muitas redes no mesmo cluster |
| Implementação | Linux: DaemonSet | Linux: DaemonSet |
| Windows: Serviço | Windows: Serviço | |
| Linha de comandos | nenhum | Calicoctl |
Importante
Atualmente, a seleção padrão é usar o Calico em um modo de rede de sobreposição. Para habilitar Flannel, use o -primaryNetworkPluginNew-AksHciCluster parâmetro do comando 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'
Este artigo aborda conceitos de rede para contêineres em nós AKS no Azure Local. Para obter mais informações sobre o AKS nos conceitos do Azure Local, consulte os seguintes artigos: