Conceitos de rede de contêiner

Artigo
04/27/2023

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 comunicações de aplicativos e permitem que você se conecte e exponha aplicativos internamente ou externamente. Você pode balancear a carga de seus aplicativos para criar aplicativos altamente disponíveis.

Aplicativos mais complexos podem exigir configuração de tráfego de ingresso para terminação SSL / TLS ou roteamento de múltiplos componentes. Talvez você também precise restringir o fluxo de tráfego de rede em ou entre pods e nós para segurança.

Este artigo apresenta os principais conceitos que fornecem rede para seus aplicativos no AKS habilitado 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 aplicativo, 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 compartilhando o mesmo AksHciClusterNetwork objeto. Devido à maneira como os endereços IP e os mapeamentos de porta são alocados dentro do Proxy de 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ê implante novamente suas cargas de trabalho. Ao implantar novamente 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 implantar novamente 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 Stack HCI

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 estã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 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 Azure Stack HCI também ajuda a simplificar a rede virtual para AKS em clusters do Azure Stack HCI fornecendo a rede "underlay" de maneira altamente disponível. Ao criar um cluster do AKS, também criamos e configuramos um recurso de HAProxy balanceador de carga subjacente. À 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 pontos de extremidade neste 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 painel de controle do Kubernetes que expõe a API do Kubernetes. O servidor de API é o front-end do plano 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 computadores de trabalho, chamados nós, e os nós hospedam aplicativos em contêineres. Além dos nós do painel 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 Stack HCI, para obter mais informações, confira Conceitos de rede de nó.
Serviços do Kubernetes: no Kubernetes, os Serviços agrupam logicamente endereços IP de 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 para os serviços do Kubernetes, independentemente do modelo de rede subjacente.
Balanceadores de carga HAProxy: HAProxy é um balanceador de carga TCP/HTTP e um servidor proxy que espalha solicitações de entrada em vários pontos de extremidade. Cada cluster de carga de trabalho em uma implantação do AKS no Azure Stack HCI 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 do Azure Stack HCI que permite a criação e o gerenciamento do ambiente virtualizado que hospeda o Kubernetes em um cluster local do Azure Stack HCI ou no cluster do Windows Server. O modelo de rede seguido pelo cluster do Azure Stack HCI 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, confira Conceitos de rede do Nó.

Redes kubernetes

No AKS no Azure Stack HCI, você pode implantar um cluster que usa um dos seguintes modelos de rede:

Rede de Sobreposição de Flannel – os recursos de rede normalmente são criados e configurados à medida que o cluster é implantado.
Rede do Project Calico – esse 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 da Calico Network, marcar começar a usar a política de rede do Calico.

Comparando modelos de rede

Flanela

Flannel é uma camada de rede virtual projetada especificamente para contêineres. O Flannel cria uma rede plana que sobrepõe a rede de 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 um do outro.

Calico

O Calico é uma solução de segurança de rede e rede de software livre para contêineres, máquinas virtuais e cargas de trabalho nativas baseadas em host. O Calico dá suporte a vários planos de dados, incluindo: um plano de dados eBPF do Linux, um plano de dados de rede linux e um plano de dados HNS do Windows.

Capacidades

Capacidade	Flanela	Calico
Políticas de Rede	No	Yes
IPv6	No	Yes
Camadas usadas	L2 (VxLAN)	L2 (VxLAN)
Implantar cluster em uma rede virtual nova ou existente	Yes	Yes
Suporte do Windows	Yes	Yes
conexão Pod-Pod	Yes	Yes
Conexão Pod-VM, VM na mesma rede	No	Yes
Conexão Pod-VM, VM em rede diferente	Yes	Yes
Serviços Kubernetes	Yes	Yes
Expor por meio do balanceador de carga	Yes	Yes
Redes	Muitas redes no mesmo cluster com vários daemons	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 comando do New-AksHciCluster PowerShell e especifique flannel como o valor. Esse valor não pode ser alterado depois de implantar o cluster e ele se aplica aos nós de cluster do Windows e do Linux.

Aqui está um exemplo:

New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'

Próximas etapas

Este artigo aborda os conceitos de rede para contêineres em nós do AKS no Azure Stack HCI. Para obter mais informações sobre os conceitos do AKS no Azure Stack HCI, consulte os seguintes artigos: