Suporte a várias sub-redes no Serviço de Rede Host
Aplica-se a: Windows Server 2025, Windows Server 2022
O uso de várias sub-redes por rede agora é suportado no Host Networking Service (HNS) para contêineres do Windows. Anteriormente, o HNS restringia as configurações dos endpoints dos contentores em Kubernetes para utilizar apenas o comprimento do prefixo da sub-rede subjacente. O HNS foi aprimorado para que você possa usar sub-redes mais restritivas, como sub-redes com um comprimento de prefixo maior, bem como várias sub-redes por nó de trabalho do Windows. O primeiro Container Networking Interface (CNI) que pode essa funcionalidade é o Calico para Windows. Calico Network Policies é uma solução de segurança de rede e rede de código aberto fundada por Tigera.
Você pode utilizar várias sub-redes no HNS apenas para drivers de rede de l2bridge, l2tunnele overlay. Esses drivers de rede podem expor várias sub-redes e, em seguida, permitir que cada ponto de extremidade se associe a uma dessas sub-redes.
HNS e o Host Compute Service (HCS) trabalham juntos para criar contentores e anexar endpoints a uma rede. Você pode interagir com o HNS usando o módulo auxiliar do HNS Powershell.
Requisitos do Calico
O suporte a várias sub-redes para o Calico CNI requer a subdivisão da sub-rede em blocos IP menores. Todos os blocos IP devem compartilhar o mesmo gateway, mas cada bloco IP pode ter seu próprio domínio de difusão separado. Para maximizar a alocação de IPV4 para ser o mais eficiente possível, o Calico requer a criação de blocos IP muito pequenos (tão pequenos quanto um bloco = quatro endereços IP), além de definir prefixos muito pequenos em pontos finais de contêiner (tão pequenos quanto /32).
Uma implementação completa do Calico IP Address Management (IPAM) funciona da seguinte forma:
A função IPAM do Calico foi projetada para alocar endereços IP para cargas de trabalho sob demanda. O Calico também suporta vários pools IP para agrupamento administrativo. Ao configurar uma alocação para uma carga de trabalho específica, o conjunto de pools permitidos pode ser limitado pela configuração, que permite vários casos de uso. Siga as diretrizes abaixo para diferentes casos de uso:
- Use várias piscinas separadas para aumentar a capacidade.
- Para redes l2bridge dentro de um rack, configure um pool IP por rack onde os hosts no rack só podem alocar de um pool específico.
- Use um pool de endereços IP por nível de stack em que os pods de front-end obtêm IPs de um pool de front-end (que pode ser público), mas os pods de back-end (potencialmente no mesmo host) recebem IPs de um intervalo diferente. Isso permite que o Calico se adapte aos requisitos agressivos de particionamento de rede (como pode ser necessário para trabalhar com firewalls legados).
- Utilize micropoços muito pequenos, um para cada camada de uma pilha. Como esses pools são tão pequenos, eles exigem que cada host ofereça suporte a cargas de trabalho de vários pools.
IPs são sempre alocados a partir de blocos, e esses blocos podem ser afins a um host específico. Um host sempre tentará atribuir IPs de um de seus próprios blocos afins se houver espaço (e somente se o bloco for de um pool permitido para a carga de trabalho dada). Se nenhum dos blocos existentes do host tiver espaço, o host tentará obter um novo bloco de um pool permitido. Se nenhum bloco vazio estiver disponível, o host usará um IP de qualquer bloco em um pool autorizado que tenha espaço livre disponível, mesmo que esse bloco esteja associado a outro host.
O Calico conta com o de roteamento de correspondência de prefixo mais longo para suportar a agregação. Cada host anuncia rotas para todos os seus blocos afins e anuncia rotas /32 para quaisquer IPs que tenha emprestado. Como uma rota /32 é mais específica, os hosts remotos que precisam encaminhar para o /32 usarão a rota /32 em vez da rota /26 mais ampla para o host com o bloco afim.
Como o Calico é uma rede L3 roteada, vale a pena notar que as rotas /26 não se destinam a ser sub-redes. Por exemplo, não há rede ou endereço de transmissão; e os endereços "0" e "255" de um bloco são usados como IPs normais.
Requisitos do plano de dados Calico HNS
Há vários requisitos de conectividade e política do Calico para habilitar várias sub-redes no HNS:
- Todas as cargas de trabalho no mesmo host devem ter conectividade entre si e com pods remotos.
- Todos os caminhos de pacotes entre pods devem ter o seguinte, independentemente de o remetente e o recetor estarem ou não colocalizados no mesmo host e se eles se acessarem diretamente ou pelo IP do cluster de serviços:
- As políticas de saída e entrada da lista de controle de acesso (ACL) devem ser aplicadas.
- Tanto a política de saída do pod de envio quanto a política de entrada do pod de recebimento devem permitir o tráfego.
- Todas as regras de ACL programadas pelo Calico devem conseguir aceder aos IPs de pod.
- Hosts e pods devem ser capazes de alcançar uns aos outros e alcançar pods em outros hosts em rotas aprendidas através do Border Gateway Protocol (BGP).
Vários blocos IP por requisitos de cada anfitrião
Para oferecer suporte a vários blocos IP por host, revise os seguintes requisitos:
- Para um determinado pool de IP único, o plano de dados deve permitir que pods sejam adicionados com IPs de blocos IP diferentes e separados. Por exemplo, o pool de IP pode ser 10.0.0.0/16, mas um host pode reivindicar um par de blocos aleatórios: 10.0.123.0/26 e 10.0.200.0/26.
- A piscina e o tamanho dos blocos não precisam ser conhecidos antes da primeira alocação. Isto é altamente recomendado.
- Outros blocos do mesmo conjunto podem estar presentes noutros servidores.
- O prefixo comum dos vários blocos pode sobrepor-se ao próprio endereço IP do anfitrião.
Requisitos para apoiar o empréstimo de propriedade intelectual
O Calico IPAM aloca IPs para hospedar em blocos para fins de agregação. Se o pool de IP estiver cheio, os nós também poderão emprestar IPs do bloco de outro nó. Em termos de BGP, o mutuário então anuncia uma rota /32 mais específica para o IP emprestado e, em seguida, o tráfego para esse IP é roteado para o host mutuário.
Os nós do Windows não suportam esse mecanismo de empréstimo. Eles não cedem IPs, mesmo que o pool de IPs esteja cheio, e marcam os seus blocos para que os nós Linux também não cedam deles.
Requisitos para dar suporte a micropools
Para usar micropools, o requisito de reservar quatro IPs por bloco é removido. No caso de uso do micropool, utilizam-se piscinas muito pequenas e blocos muito pequenos, então quatro endereços IP por bloco desperdiçam a maioria dos endereços IP. Você pode exigir um pequeno número de IPs reservados por host ou por pool. Uma boa prática é remover todas as restrições de suporte de camada 2 (por exemplo, não deve haver suporte para broadcast e não devem existir IPs reservados).
Criar uma sub-rede e uma sub-rede IP usando o PowerShell
Antes de continuar, certifique-se de ter o módulo HNS.V2.psm1 instalado a partir da galeria HNS PowerShell.
As etapas a seguir explicam como criar uma sub-rede e uma sub-rede IP usando exemplos.
Para criar uma rede l2bridge com uma sub-rede 192.168.0.0/16 que contenha uma sub-rede IP 192.168.1.0/24 e uma sub-rede IP 192.168.2.0/24, execute o seguinte comando:
$net1 = New-HnsNetwork -Type L2Bridge -Name Test1 -AddressPrefix "192.168.0.0/16" -Gateway "192.168.0.1" -Verbose -IPSubnets @(@{"IpAddressPrefix"="192.168.1.0/24";"Flags"=0},@{"IpAddressPrefix"="192.168.2.0/24";"Flags"=[IPSubnetFlags]::EnableBroadcast})Para adicionar uma nova sub-rede 172.16.0.0/16 que contenha uma sub-rede IP 172.16.1.0/16 à rede l2bridge, execute o seguinte comando:
New-HnsSubnet -NetworkID $net1.ID -Subnets @{ "IpAddressPrefix"="172.16.0.0/16"; "Routes"=@(@{"NextHop"="172.16.0.1";"DestinationPrefix"="0.0.0.0"}); "IpSubnets"=@(@{"IpAddressPrefix"="172.16.1.0/24"})Para adicionar uma nova sub-rede IP 172.16.2.0/24 à sub-rede 172.16.0.0/16, execute o seguinte comando:
New-HnsIPSubnet -NetworkID $net1.ID -SubnetID $net2.Subnets[1].ID -IPSubnets @{"IpAddressPrefix"="172.16.2.0/24";"Flags"=0}
Para remover as sub-redes IP, use as seguintes etapas:
Para remover a sub-rede IP 172.16.2.0/24, execute o seguinte comando:
$net2 = Get-HnsNetwork -ID $net1.ID Remove-HnsIpSubnet -NetworkID $net1.ID -SubnetID $net2.Subnets[1].ID -IPSubnets @{"ID"=$net2.Subnets[1].IPSubnets[1].ID}Para remover a sub-rede 172.16.0.0/16, execute o seguinte comando:
Remove-HnsSubnet -NetworkID $net1.ID -Subnets @{"ID"=$net2.Subnets[1].ID}