Conceitos de rede para implementar nós do AKS

Artigo
07/12/2023

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

Pode escolher entre dois modelos de atribuição de endereços IP para a sua arquitetura de rede para o AKS ativado pelo Azure Arc. O AKS suporta várias opções de implementação para Azure Kubernetes Service (AKS).

Rede IP estática: a rede virtual aloca endereços IP estáticos ao servidor de API do cluster do Kubernetes, aos nós do Kubernetes, às VMs subjacentes, aos balanceadores de carga e a todos os serviços do Kubernetes que são executados sobre o cluster.
Rede DHCP: a rede virtual aloca endereços IP dinâmicos aos nós do Kubernetes, VMs subjacentes e balanceadores de carga com um servidor DHCP. O servidor de API de cluster do Kubernetes e todos os serviços do Kubernetes que executar sobre o cluster continuam a ser endereços IP estáticos alocados.

Nota

A arquitetura de rede virtual definida aqui para o AKS Arc pode ser diferente da arquitetura de rede física subjacente num datacenter.

Conjunto de IP virtual

Um conjunto de IP Virtual (VIP) é um conjunto de endereços IP obrigatórios para qualquer implementação no AKS Arc. O conjunto VIP é um intervalo de endereços IP reservados utilizado para alocar endereços IP ao servidor de API de cluster do Kubernetes. Garante que as suas aplicações nos serviços do Kubernetes estão sempre acessíveis. Tenha em atenção que, independentemente do modelo de rede virtual e do modelo de atribuição de endereços que escolher, tem de fornecer um conjunto VIP para a implementação do anfitrião do AKS.

O número de endereços IP no conjunto VIP depende do número de clusters de cargas de trabalho e serviços do Kubernetes planeados para a implementação.

Consoante o modelo de rede, a definição do conjunto VIP difere das seguintes formas:

IP estático: se estiver a utilizar o IP estático, certifique-se de que os endereços IP virtuais são da mesma sub-rede fornecida.
DHCP: se a sua rede estiver configurada com DHCP, trabalhe com o administrador de rede para excluir o intervalo de IP do conjunto VIP do âmbito DHCP utilizado para a implementação do AKS no Azure Stack HCI.

Conjunto IP da VM do nó do Kubernetes

Os nós do Kubernetes são implementados como máquinas virtuais especializadas no AKS Arc. O AKS atribui endereços IP a estas máquinas virtuais para permitir a comunicação entre nós do Kubernetes.

IP estático: tem de especificar um intervalo do conjunto de IP da VM do nó do Kubernetes. O número de endereços IP neste intervalo depende do número total de nós do Kubernetes que planeia utilizar para implementar nos clusters do Kubernetes do anfitrião do AKS e da carga de trabalho. Tenha em atenção que as atualizações consomem um a três endereços IP adicionais durante a atualização.
DHCP: não precisa de especificar um conjunto de VMs de nó do Kubernetes, uma vez que os endereços IP para os nós do Kubernetes são alocados dinamicamente pelo servidor DHCP na sua rede.

Rede virtual com rede IP estática (recomendado)

Este modelo de rede cria uma rede virtual que aloca endereços IP de um conjunto de endereços estaticamente definido a todos os objetos na sua implementação. Uma vantagem adicional da utilização de redes IP estáticas é o facto de as implementações de longa duração e as cargas de trabalho das aplicações estarem sempre acessíveis.

Especifique os seguintes parâmetros ao definir uma rede virtual com configurações de IP estático:

Importante

Esta versão do AKS não permite alterações na configuração de rede depois de o anfitrião do AKS ou o cluster de cargas de trabalho serem implementados. Para alterar as definições de rede, tem de começar de novo removendo os clusters de carga de trabalho e desinstalando o AKS.

Nome: o nome da sua rede virtual.
Prefixo de endereço: o prefixo de endereço IP a utilizar para a sua sub-rede.
Gateway: o endereço IP do gateway predefinido para a sub-rede.
Servidor DNS: uma matriz de endereços IP que apontam para os servidores DNS a serem utilizados para a sub-rede. Pode ser fornecido um mínimo de um e um máximo de três servidores.
Conjunto de VMs de nó do Kubernetes: um intervalo contínuo de endereços IP a utilizar para as VMs do nó do Kubernetes.
Conjunto de IP virtual: um intervalo contínuo de endereços IP a utilizar para o servidor de API de cluster do Kubernetes e os serviços do Kubernetes.

Nota

O conjunto VIP tem de fazer parte da mesma sub-rede que o conjunto de VMs do nó do Kubernetes.
ID da vLAN: o ID da vLAN para a rede virtual. Se for omitida, a rede virtual não está etiquetada.

Rede virtual com redes DHCP

Este modelo de rede cria uma rede virtual que aloca endereços IP com DHCP a todos os objetos na implementação.

Tem de especificar os seguintes parâmetros ao definir uma rede virtual com configurações de IP estático:

Importante

Nesta versão do AKS, não é possível alterar a configuração de rede assim que o anfitrião do AKS ou o cluster de cargas de trabalho forem implementados. A única forma de alterar as definições de rede é começar de novo ao remover os clusters de cargas de trabalho e desinstalar o AKS.

Nome: o nome da sua rede virtual.
Conjunto de IP virtual: o intervalo contínuo de endereços IP a utilizar para o servidor de API do cluster do Kubernetes e os serviços do Kubernetes.

Nota

Os endereços do conjunto VIP têm de estar na mesma sub-rede que o âmbito DHCP e têm de ser excluídos do âmbito DHCP para evitar conflitos de endereços.
ID da vLAN: o ID da vLAN para a rede virtual. Se for omitida, a rede virtual não está etiquetada.

Serviço Cloud no Local da Microsoft

O Microsoft On-premises Cloud (MOC) é a pilha de gestão que permite que as máquinas virtuais no Azure Stack HCI e no SDDC baseado no Windows Server sejam geridas na cloud. O MOC consiste em:

Uma única instância de um serviço de elevada disponibilidade cloud agent implementado no cluster. Este agente é executado em qualquer nó no cluster do Azure Stack HCI ou do Windows Server e está configurado para efetuar a ativação pós-falha para outro nó.
Uma node agent execução em todos os nós físicos do Azure Stack HCI.

Para ativar a comunicação com o MOC, tem de fornecer o CIDR do endereço IP a ser utilizado para o serviço. O -cloudserviceCIDR é um parâmetro no Set-AksHciConfig comando que é utilizado para atribuir o endereço IP ao serviço do agente cloud e ativar a elevada disponibilidade do serviço do agente cloud.

A escolha de um endereço IP para o serviço MOC depende do modelo de rede subjacente utilizado pela implementação do cluster no Azure Stack HCI ou no Windows Server.

Nota

A alocação de endereços IP para o serviço MOC é independente do modelo de rede virtual do Kubernetes. A alocação de endereços IP depende da rede física subjacente e dos endereços IP configurados para os nós de cluster do Azure Stack HCI ou do Windows Server no seu datacenter.

Nós de cluster do Azure Stack HCI e Windows Server com um modo de alocação de endereços IP baseado em DHCP: se os nós do Azure Stack HCI tiverem um endereço IP de um servidor DHCP presente na rede física, não terá de fornecer explicitamente um endereço IP ao serviço MOC, uma vez que o serviço MOC também recebe um endereço IP do servidor DHCP.
Nós de cluster do Azure Stack HCI e do Windows Server com um modelo de alocação de IP estático: se os nós de cluster tiverem endereços IP estáticos atribuídos, tem de fornecer explicitamente um endereço IP para o serviço cloud do MOC. O endereço IP do serviço MOC tem de estar na mesma sub-rede que os endereços IP dos nós de cluster do Azure Stack HCI e do Windows Server. Para atribuir explicitamente um endereço IP para o serviço MOC, utilize o -cloudserviceCIDR parâmetro no Set-AksHciConfig comando . Certifique-se de que introduz um endereço IP no formato CIDR, por exemplo: "10.11.23.45/16".

Comparar modelos de rede

Tanto o DHCP como o IP Estático fornecem conectividade de rede no AKS na implementação do Azure Stack HCI e do Windows Server. No entanto, existem vantagens e desvantagens para cada uma. A um nível elevado, aplicam-se as seguintes considerações:

DHCP – não garante endereços IP de longa duração para alguns tipos de recursos numa implementação do AKS. - Suporta a expansão de endereços IP DHCP reservados se a implementação for maior do que o inicialmente previsto.

IP estático – garante endereços IP de longa duração para todos os recursos numa implementação do AKS. - Uma vez que a expansão automática do conjunto IP de nós do Kubernetes não é suportada, poderá não conseguir criar novos clusters se tiver esgotado o conjunto IP do nó do Kubernetes.

A tabela seguinte compara a alocação de endereços IP para recursos entre o IP estático e os modelos de rede DHCP:

Funcionalidade	IP estático	DHCP
Servidor de API de cluster do Kubernetes	Atribuído estaticamente com o conjunto VIP.	Atribuído estaticamente com o conjunto VIP.
Nós do Kubernetes (em máquinas virtuais)	Atribuído com o conjunto IP de nós do Kubernetes.	Atribuído dinamicamente.
Serviços do Kubernetes	Atribuído estaticamente com o conjunto VIP.	Atribuído estaticamente com o conjunto VIP.
VM do balanceador de carga HAProxy	Atribuído com o conjunto IP de nós do Kubernetes.	Atribuído dinamicamente.
Serviço Cloud no Local da Microsoft	Depende da configuração de rede física para nós de cluster do Azure Stack HCI e do Windows Server.	Depende da configuração de rede física para nós de cluster do Azure Stack HCI e do Windows Server.
Conjunto VIP	Obrigatório	Obrigatório
Conjunto DE IP da VM do nó do Kubernetes	Obrigatório	Não suportado

Reservas mínimas de endereços IP para uma implementação do AKS

Independentemente do modelo de implementação, o número de endereços IP reservados permanece o mesmo. Esta secção descreve o número de endereços IP que precisa de reservar com base no modelo de implementação do AKS Arc.

Reserva mínima de endereços IP

No mínimo, deve reservar o seguinte número de endereços IP para a sua implementação:

Tipo de cluster	Nó do plano de controlo	Nó de trabalho	Para operações de atualização	Balanceador de carga
Anfitrião do AKS	Um IP	ND	Dois IP	ND
Cluster de cargas de trabalho	Um IP por nó	Um IP por nó	5 IP	Um IP

Além disso, deve reservar o seguinte número de endereços IP para o conjunto VIP:

Tipo de recurso	Número de endereços IP
Servidor de API de Cluster	1 por cluster
Serviços do Kubernetes	1 por serviço
Serviços de aplicações	1 por serviço planeado

Como pode ver, o número de endereços IP necessários é variável consoante a arquitetura da implementação do AKS e o número de serviços executados no cluster do Kubernetes. Recomendamos reservar um mínimo de 256 endereços IP (/24 sub-rede) para a sua implementação.

Percorrer uma implementação de exemplo

A Joana é administradora de TI a começar com o AKS ativado pelo Azure Arc. Quer implementar dois clusters do Kubernetes: o cluster A do Kubernetes e o cluster B do Kubernetes no cluster do Azure Stack HCI. Ela também quer executar um pedido de votação em cima do seu cluster. Esta aplicação tem três instâncias da IU de front-end em execução nos dois clusters e uma instância da base de dados de back-end.

O cluster do Kubernetes A tem 3 nós de plano de controlo e 5 nós de trabalho.
O cluster B do Kubernetes tem 1 nó de plano de controlo e 3 nós de trabalho.
3 instâncias da IU de front-end (porta 443).
1 instância da base de dados de back-end (porta 80).

Com base na tabela anterior, tem de reservar:

3 endereços IP para o anfitrião do AKS (um IP para o nó do plano de controlo e dois IPs para executar operações de atualização).
3 endereços IP para os nós do plano de controlo no cluster A (um IP por nó do plano de controlo).
5 endereços IP para os nós de trabalho no cluster A (um IP por nó de trabalho).
6 endereços IP adicionalmente para o cluster A (cinco IPs para executar operações de atualização e 1 IP para balanceador de carga).
1 endereços IP para os nós do plano de controlo no cluster B (um IP por nó do plano de controlo).
3 endereços IP para os nós de trabalho no cluster B (um IP por nó de trabalho).
6 endereços IP adicionalmente para o cluster B (cinco IPs para executar operações de atualização e 1 IP para balanceador de carga).
2 endereços IP para os servidores de API do cluster do Kubernetes (um IP por cluster do Kubernetes).
3 endereços IP para o serviço Kubernetes (um endereço IP por instância da IU de front-end, uma vez que todos utilizam a mesma porta. A base de dados de back-end pode utilizar qualquer um dos três endereços IP, desde que utilize uma porta diferente).

Conforme explicado anteriormente, a Joana necessita de um total de 32 endereços IP para implementar o cluster. Por conseguinte, a Jane deve reservar uma sub-rede /26 para a sua rede virtual.

Dividir endereços IP reservados com base num modelo de rede IP estático

Embora o número total de endereços IP reservados permaneça o mesmo, o modelo de implementação determina como estes endereços IP são divididos entre grupos IP. O modelo de rede IP estático tem dois conjuntos IP:

Conjunto IP da VM do nó do Kubernetes: para VMs de nó do Kubernetes e VM do balanceador de carga. Este conjunto IP também inclui o endereço IP necessário para executar operações de atualização.
Conjunto de IP virtual: para o servidor da API do Kubernetes e os serviços do Kubernetes.

Ao trabalhar com este exemplo, a Joana tem de dividir ainda mais estes endereços IP entre conjuntos VIP e conjuntos IP de nós do Kubernetes:

5 (dois para o servidor de API de cluster do Kubernetes e três para serviços kubernetes) dos 32 endereços IP do conjunto VIP.
27 (todos os endereços IP para os nós do Kubernetes e VMs subjacentes, as VMs do balanceador de carga e as operações de atualização) para o conjunto IP do nó do Kubernetes.

Dividir endereços IP reservados com base num modelo de rede DHCP

Embora o número total de endereços IP reservados permaneça o mesmo, o modelo de implementação determina como estes endereços IP são divididos entre os grupos IP. Conforme abordado na secção anterior, o modelo de rede DHCP tem um âmbito IP:

Conjunto de IP virtual: para o servidor da API do Kubernetes e os serviços do Kubernetes

Trabalhar com o exemplo anterior:

A Joana tem de reservar um total de 32 endereços IP ou uma sub-rede /26 no servidor DHCP.
Tem de excluir 5 (dois para o servidor de API de cluster do Kubernetes e três para os serviços do Kubernetes) do âmbito DHCP de 32 endereços IP para o conjunto VIP.

Controladores de entrada

Durante a implementação de um cluster de destino, é criado um HAProxyrecurso de balanceador de carga baseado em . O balanceador de carga está configurado para distribuir o tráfego para os pods no seu serviço numa determinada porta. O balanceador de carga só funciona na camada 4, o que indica que o serviço desconhece a aplicação real; Ou seja, não pode fazer considerações de encaminhamento adicionais.

Os controladores de entrada funcionam na camada 7 e são capazes de utilizar regras mais inteligentes para distribuir o tráfego da aplicação. Uma utilização comum de um controlador de entrada é encaminhar o tráfego HTTP para diferentes aplicações com base no URL de entrada.

Passos seguintes

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

Partilhar via