Compartilhar via


Suporte a várias sub-redes no Serviço de Rede de Host

Aplica-se a: Windows Server 2025, Windows Server 2022

Agora há suporte para o uso de várias sub-redes por rede no HNS (Serviço de Rede de Host) para contêineres do Windows. Antes, o HNS restringia as configurações de endpoint de contêiner do Kubernetes para usar exclusivamente o comprimento do prefixo da rede subjacente. O HNS foi aprimorado para que você possa usar sub-redes mais restritivas, como sub-redes com um comprimento de prefixo mais longo, bem como várias sub-redes por nó de trabalho do Windows. A primeira CNI (Interface de Rede de Contêiner) que pode essa funcionalidade é o Calico para Windows. A Calico Network Policies é uma solução de segurança de rede e rede de software livre fundada pelo Tigera.

Você pode utilizar várias sub-redes no HNS apenas para drivers de rede l2bridge, l2tunnel e overlay. Esses drivers de rede podem expor múltiplas sub-redes e permitir que cada ponto de extremidade se vincule a uma dessas sub-redes.

O HNS e o Serviço de Computação de Host (HCS) operam juntos para criar contêineres e anexar pontos de extremidade a uma rede. Você pode interagir com o HNS usando o módulo auxiliar 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 de extremidade de contêiner (tão pequenos quanto /32).

Uma implementação completa do IPAM (Gerenciamento de Endereço IP) do Calico funciona da seguinte maneira:

A função IPAM do Calico foi projetada para alocar endereços IP para cargas de trabalho sob demanda. O Calico também dá suporte a vários pools de 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, o que permite vários casos de uso. Siga as diretrizes abaixo para diferentes casos de uso:

  • Use vários pools independentes para aumentar a capacidade.
  • Para redes l2bridge dentro de um rack, configure um pool de IP por rack em que os hosts em um rack só podem alocar IPs de um pool específico.
  • Use um bloco de IPs por nível da pilha, em que os pods front-end obtêm IPs de um bloco 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 ajuste aos requisitos agressivos de particionamento de rede (como pode ser necessário para trabalhar com firewalls herdados).
  • Use piscinas microscópicas muito pequenas, uma para cada camada de uma pilha. Como esses pools são tão pequenos, eles exigem que cada host dê suporte a cargas de trabalho de vários pools.

Os IPs são sempre alocados a partir de blocos e esses blocos podem ser afim de 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 específica). Se nenhum dos blocos existentes do host tiver espaço, o host tentará reivindicar um novo bloco de um pool permitido. Se nenhum bloco vazio estiver disponível, o host tomará emprestado um IP de qualquer bloco em um pool permitido que tenha espaço livre disponível, mesmo que esse bloco seja atribuído a outro host.

O Calico depende do roteamento de correspondência de prefixo mais longo para dar suporte à agregação. Cada host anuncia rotas para todos os seus blocos afins e anuncia rotas /32 para todos os IPs que tenha tomado emprestado. Como uma rota /32 é mais específica, 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 observar que as rotas /26 não se destinam a ser sub-redes. Por exemplo, não há nenhum endereço de rede ou difusão; e os endereços "0" e "255" de um bloco são usados como IPs normais.

Requisitos do plano de dados do HNS do Calico

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 pacote entre pods devem ter o seguinte se o remetente e o receptor estão ou não localizados no mesmo host e se eles acessam um ao outro diretamente ou pelo IP do cluster de serviço:
    • As políticas de entrada e saída da ACL (lista de controle de acesso) devem ser aplicadas.
    • Tanto a política de saída do pod de envio quanto a política de entrada do pod receptor devem permitir o tráfego.
    • Todas as regras de ACL programadas pelo Calico devem ser capazes de exibir IPs de pod.
  • Hosts e pods devem conseguir se comunicar entre si e também com pods em outros hosts por meio de rotas aprendidas pelo Protocolo BGP (Border Gateway Protocol).

Vários blocos IP por requisitos de host

Para dar suporte a vários blocos IP por host, examine os seguintes requisitos:

  • Para um determinado pool de IP único, o plano de dados deve permitir que os pods sejam adicionados com IPs de blocos IP diferentes e desarticulados. 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. Isso é altamente recomendado.
  • Outros blocos do mesmo pool podem estar presentes em outros hosts.
  • O prefixo comum dos vários blocos pode se sobrepor ao endereço IP do próprio host.

Requisitos para suportar o empréstimo de IP

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 pegar emprestados IPs do bloco de outro nó. Em termos de BGP, o tomador anuncia uma rota /32 mais específica para o IP emprestado e, em seguida, o tráfego para esse IP é roteado para o host de empréstimo.

Os nós do Windows não dão suporte a esse mecanismo de empréstimo. Eles não pegarão IPs emprestados mesmo que o pool de IP esteja cheio, e seus blocos são marcados para que os nós do Linux também não pegue emprestado deles.

Requisitos para dar suporte a micropools

Para usar micropools, o requisito de reservar quatro IPs por bloco é removido. No caso de uso de micropool, são usados pools e blocos muito pequenos, portanto, quatro IPs por bloco gastam a maioria dos IPs. Você pode exigir um pequeno número de IPs reservados por host ou por pool. Uma prática recomendada é ter todas as restrições de suporte camada 2 suspensas (por exemplo, não deve haver suporte para difusão e nenhum IPs reservados).

Criar uma sub-rede e uma sub-rede IP usando o PowerShell

Antes de continuar, verifique se você tem o módulo HNS.V2.psm1 instalado na galeria do HNS PowerShell.

As etapas a seguir explicam como criar uma sub-rede e uma sub-rede IP usando exemplos.

  1. Para criar uma sub-rede l2bridge com uma sub-rede IP 192.168.0.0/16 que contém 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})
    
  2. Para adicionar uma nova sub-rede 172.16.0.0/16 que contém 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"})
    
  3. 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 sub-redes IP, siga estas etapas:

  1. 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}
    
  2. 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}