Partilhar via

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

  • Artigo

Aplica-se a: 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 de ponto de extremidade do contêiner do Kubernetes para usar 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 pela Tigera.

Você pode utilizar várias sub-redes no HNS somente para drivers de rede l2bridge, l2tunnel e 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.

O HNS e o Host Compute Service (HCS) trabalham juntos para criar contêineres e anexar pontos de extremidade a uma rede. Você pode interagir com o HNS usando o módulo HNS Powershell Helper.

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 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 oferece 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, que permite vários casos de uso. Siga as diretrizes abaixo para diferentes casos de uso:

  • Use vários pools de disjunção para aumentar a capacidade.
  • Para redes l2bridge dentro de um rack, configure um pool de IP por rack em que os hosts dentro de um rack só possam alocar de um pool específico.
  • Use um pool de IP por camada de pilha em que os pods front-end obtêm IPs de um pool front-end (que pode ser público), mas os pods back-end (potencialmente no mesmo host) recebem IPs de um intervalo diferente. Isso permite que o Calico se encaixe em requisitos agressivos de particionamento de rede (como pode ser necessário para trabalhar com firewalls herdados).
  • Use micropools 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 determinada). 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 emprestará um IP de qualquer bloco em um pool permitido que tenha espaço livre disponível, mesmo que esse bloco esteja afim a outro host.

O Calico depende do roteamento de correspondência de prefixo mais longo para oferecer suporte à 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 a /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á endereço de rede ou 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 receptor estarem ou não co-localizados no mesmo host e se eles acessam um ao outro diretamente ou pelo IP do cluster de serviço:
    • As políticas de saída e entrada da lista de controle de acesso (ACL) devem ser aplicadas.
    • A política de saída do pod de envio e a política de entrada do pod de recebimento devem permitir o tráfego.
    • Todas as regras de ACL programadas pelo Calico devem ser capazes de visualizar IPs de pod.
  • Os hosts e os pods devem ser capazes de alcançar uns aos outros e alcançar pods em outros hosts por meio de rotas aprendidas pelo BGP (Border Gateway Protocol).

Vários blocos IP por requisitos de host

Para oferecer 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 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. Fazer isso é altamente recomendável.
  • Outros blocos da mesma piscina podem estar presentes em outros anfitriões.
  • O prefixo comum dos vários blocos pode se sobrepor ao endereço IP do próprio host.

Requisitos para suportar a contracção de empréstimos de PI

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 oferecem suporte a esse mecanismo de empréstimo. Eles não pegarão IPs emprestados, mesmo que o pool de IPs esteja cheio, e marcarão seus blocos para que os nós do Linux também não peguem emprestado deles.

Requisitos para oferecer suporte a micropools

Para usar micropools, o requisito de reservar quatro IPs por bloco é removido. No caso de uso de micropool, pools muito pequenos e blocos muito pequenos são usados, então quatro IPs por bloco desperdiçam 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 de camada 2 suspensas (por exemplo, não deve haver suporte para transmissão e nem 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 a partir da galeria do PowerShell do HNS.

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

  1. Para criar uma rede l2bridge com uma sub-rede 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 as sub-redes IP, use as seguintes 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}