Conceitos de rede de contentores

Artigo
04/19/2024

Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server

Os componentes da aplicação têm de trabalhar em conjunto para processar as suas tarefas numa abordagem de microsserviços baseada em contentores. O Kubernetes fornece recursos que permitem comunicações de aplicações e permitem-lhe ligar-se e expor aplicações interna ou externamente. Pode fazer o balanceamento de carga das aplicações para criar aplicações de elevada disponibilidade.

As aplicações mais complexas podem exigir a configuração do tráfego de entrada para terminação SSL/TLS ou encaminhamento de vários componentes. Também poderá ter de 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 às suas aplicações no AKS ativado pelo Arc:

Serviços do Kubernetes
Controlador de entradas
Políticas de rede

Serviços do Kubernetes

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. Estão disponíveis os seguintes tipos de serviço:

IP do cluster: cria um endereço IP interno para utilização no cluster do Kubernetes. Utilize o IP do Cluster para aplicações apenas internas que suportem outras cargas de trabalho no cluster.

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: 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 outro controlo e encaminhamento do tráfego de entrada, pode utilizar um controlador de entrada.

Nota

Quando implementa um cluster de destino que partilha uma rede com outro cluster de destino, existe a possibilidade de um conflito de endereços IP do balanceador de carga. Isto pode acontecer se implementar duas cargas de trabalho que utilizam portas diferentes em clusters de destino que partilham o mesmo AksHciClusterNetwork objeto. Devido à forma como os endereços IP e os mapeamentos de portas são alocados dentro do Proxy ha, isto pode levar a uma atribuição de endereços IP duplicados. Se isto ocorrer, uma ou ambas as cargas de trabalho podem encontrar problemas de conectividade de rede aleatórios até voltar a implementar as cargas de trabalho. Quando implementar novamente as cargas de trabalho, pode utilizar a mesma porta que faz com que cada carga de trabalho receba um endereço IP de serviço separado ou pode voltar a implementar as cargas de trabalho em clusters de destino que utilizam objetos diferentes AksHciClusterNetwork .

ExternalName: cria uma entrada DNS específica para facilitar o acesso à aplicação. Os endereços IP para balanceadores de carga e serviços podem ser endereços internos ou externos consoante a configuração geral da rede e podem ser atribuídos dinamicamente. Em alternativa, pode especificar um endereço IP estático existente a utilizar. Um endereço IP estático existente está frequentemente associado a uma entrada DNS. Os balanceadores de carga internos só recebem um endereço IP privado, pelo que não podem ser acedidos a partir da Internet.

Noções básicas sobre redes do Kubernetes no Azure Stack HCI

Para permitir o acesso às suas aplicações ou para que os componentes da aplicação comuniquem entre si, o Kubernetes fornece uma camada de abstração para redes virtuais. Os nós do Kubernetes estão ligados à rede virtual e podem fornecer conectividade de entrada e saída para pods. O componente kube-proxy em execução em cada nó fornece estas funcionalidades de rede.

No Kubernetes, os Serviços agrupam logicamente pods para permitir:

Acesso direto através de um único endereço IP ou nome DNS e de uma porta específica.
Distribua o tráfego através de um balanceador de carga entre vários pods que alojam o mesmo serviço ou aplicação.

A plataforma Azure Stack HCI também ajuda a simplificar as redes virtuais para o AKS em clusters do Azure Stack HCI ao fornecer a rede "underlay" de forma altamente disponível. Quando cria um cluster do AKS, também criamos e configuramos um recurso de balanceador de carga subjacente HAProxy . À medida que implementa aplicações num cluster do Kubernetes, os endereços IP são configurados para os seus pods e serviços do Kubernetes como pontos finais neste balanceador de carga.

Recursos de endereços IP

Para simplificar a configuração de rede para cargas de trabalho de aplicações, o AKS Arc atribui endereços IP aos seguintes objetos numa implementação:

Servidor de API de cluster do Kubernetes: o servidor de API é um componente do plano de controlo do Kubernetes que expõe a API do Kubernetes. O servidor de API é o front-end do plano de controlo do Kubernetes. Os endereços IP estáticos são sempre alocados aos servidores de API, independentemente do modelo de rede subjacente.
Nós do Kubernetes (máquinas virtuais): um cluster do Kubernetes consiste num conjunto de máquinas de trabalho, denominados nós, e os nós alojam aplicações em contentores. Além dos nós do plano de controlo, 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. Estas máquinas virtuais são criadas como máquinas virtuais de elevada disponibilidade no Azure Stack HCI. Para obter mais informações, veja Conceitos de rede de nós.
Serviços do Kubernetes: no Kubernetes, os Serviços agrupam logicamente endereços IP do pod para permitir o acesso direto através de um único endereço IP ou nome DNS numa porta específica. Os serviços também podem distribuir o tráfego através de 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 um servidor proxy que distribui pedidos recebidos por vários pontos finais. Cada cluster de cargas de trabalho numa implementação do AKS no Azure Stack HCI tem um balanceador de carga HAProxy implementado e configurado como uma máquina virtual especializada.
Serviço Cloud no Local da Microsoft: este é o fornecedor de cloud do Azure Stack HCI que permite a criação e gestão do ambiente virtualizado que aloja o Kubernetes num cluster do Azure Stack HCI no local ou cluster do Windows Server. O modelo de rede seguido do cluster do Azure Stack HCI ou do Windows Server determina o método de alocação de endereços IP utilizado pelo Serviço Cloud no Local da Microsoft. Para saber mais sobre os conceitos de rede implementados pelo Serviço Cloud no Local da Microsoft, veja Conceitos de rede de nós.

Redes do Kubernetes

No AKS no Azure Stack HCI, pode implementar um cluster que utiliza 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 é implementado.
Redes do Project Calico – este modelo oferece funcionalidades de rede adicionais, como políticas de rede e controlo de fluxo.

Ambas as implementações de rede utilizam um modelo de configuração de rede de sobreposição, que fornece uma atribuição de endereço IP que está desligada do resto da rede do datacenter.

Para saber mais sobre a sobreposição de redes, veja Introducing: Kubernetes Overlay Networking for Windows (Introdução: Rede de Sobreposição do Kubernetes para Windows).

Para obter mais informações sobre o plug-in e as políticas da Rede Calico, consulte Introdução à política de rede do Calico.

Comparar modelos de rede

Flanela

Flanela é uma camada de rede virtual concebida especificamente para contentores. O Flannel cria uma rede plana que sobrepõe a rede anfitriã. Todos os contentores/pods recebem um endereço IP nesta rede de sobreposição e comunicam diretamente ao ligarem-se ao endereço IP uns dos outros.

Calico

O Calico é uma solução de rede open source e de segurança de rede para contentores, máquinas virtuais e cargas de trabalho nativas baseadas em anfitriões. O Calico suporta vários planos de dados, incluindo: um plano de dados linux eBPF, um plano de dados de rede do Linux e um plano de dados HNS do Windows.

Capacidades

Funcionalidade	Flanela	Calico
Políticas de Rede	No	Yes
IPv6	No	Yes
Camadas utilizadas	L2 (VxLAN)	L2 (VxLAN)
Implementar um cluster numa rede virtual existente ou nova	Yes	Yes
Suporte do Windows	Yes	Yes
Pod-Pod ligação	Yes	Yes
Ligação pod-VM, VM na mesma rede	No	Yes
Ligação pod-VM, VM em rede diferente	Yes	Yes
Serviços do Kubernetes	Yes	Yes
Expor através do Balanceador de carga	Yes	Yes
Redes	Muitas redes no mesmo cluster com vários daemons	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 predefinida é utilizar o Calico num modo de rede de sobreposição. Para ativar o Flannel, utilize o -primaryNetworkPlugin parâmetro do comando do New-AksHciCluster PowerShell e especifique flannel como o valor. Este valor não pode ser alterado depois de implementar o cluster e aplica-se aos nós de cluster do Windows e do Linux.

Eis um exemplo:

New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'

Passos seguintes

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

Share via