Supporto di più subnet nel servizio di rete host

  • Articolo

Si applica a Windows Server 2022

L'uso di più subnet per rete è ora supportato in Host Networking Service (HNS) per i contenitori Windows. In precedenza, le configurazioni dell'endpoint del contenitore Kubernetes con restrizioni HNS usano solo la lunghezza del prefisso della subnet sottostante. HNS è stato migliorato in modo da poter usare subnet più restrittive, ad esempio subnet con una lunghezza più lunga del prefisso, nonché più subnet per ogni nodo di lavoro di Windows. Il primo CNI (Container Networking Interface) che può usare questa funzionalità è Calico per Windows. Calico Network Policies è una soluzione di rete e sicurezza di rete open source fondata da Tigera.

È possibile usare più subnet in HNS solo per i driver di rete l2bridge, l2tunnel e overlay . Questi driver di rete possono esporre più subnet e quindi consentire a ogni endpoint di eseguire l'associazione a una di queste subnet.

HNS e host Compute Service (HCS) interagiscono per creare contenitori e collegare endpoint a una rete. È possibile interagire con HNS usando il modulo Helper di PowerShell HNS.

Requisiti calico

Il supporto di più subnet per Calico CNI richiede la suddivisione della subnet in blocchi IP più piccoli. Tutti i blocchi IP devono condividere lo stesso gateway, ma ogni blocco IP può avere un proprio dominio di trasmissione separato. Per ottimizzare l'allocazione IPV4 in modo che sia il più efficiente possibile, Calico richiede la creazione di blocchi IP molto piccoli (il più piccolo di un blocco = quattro indirizzi IP), oltre a impostare prefissi molto piccoli negli endpoint del contenitore (come minimo /32).

Un'implementazione completa di Calico Gestione indirizzi IP (Gestione indirizzi IP) funziona come segue:

La funzione Gestione indirizzi IP di Calico è progettata per allocare indirizzi IP ai carichi di lavoro su richiesta. Calico supporta anche più pool IP per il raggruppamento amministrativo. Quando si configura un'allocazione per un determinato carico di lavoro, il set di pool consentiti può essere limitato dalla configurazione, che consente diversi casi d'uso. Seguire le linee guida seguenti per i diversi casi d'uso:

  • Usare più pool non contigui per aumentare la capacità.
  • Per le reti l2bridge all'interno di un rack, configurare un pool IP per rack in cui gli host all'interno di un rack possono allocare solo da un determinato pool.
  • Usare un pool IP per livello stack in cui i pod front-end ottengono indirizzi IP da un pool front-end (che potrebbe essere pubblico), ma i pod back-end (potenzialmente nello stesso host) ricevono indirizzi IP da un intervallo diverso. Ciò consente a Calico di adattarsi a requisiti di partizionamento di rete aggressivi (come potrebbe essere necessario per lavorare con i firewall legacy).
  • Usare micro pool molto piccoli, uno per ogni livello di uno stack. Poiché questi pool sono così piccoli, richiedono a ogni host di supportare i carichi di lavoro di più pool.

Gli indirizzi IP vengono sempre allocati da blocchi e questi blocchi possono essere affine a un host specifico. Un host tenterà sempre di assegnare indirizzi IP da uno dei propri blocchi affine se è presente spazio (e solo se il blocco proviene da un pool consentito per il carico di lavoro specificato). Se nessuno dei blocchi esistenti dell'host ha spazio, l'host tenterà di richiedere un nuovo blocco da un pool consentito. Se non sono disponibili blocchi vuoti, l'host prende in prestito un indirizzo IP da qualsiasi blocco in un pool consentito con spazio disponibile, anche se tale blocco è affine a un altro host.

Calico si basa sul routing delle corrispondenze di prefisso più lungo per supportare l'aggregazione. Ogni host annuncia le route per tutti i blocchi affine e annuncia le route /32 per tutti gli INDIRIZZI IP che ha preso in prestito. Poiché una route /32 è più specifica, gli host remoti che devono inoltrare al /32 useranno la route /32 anziché la route /26 più ampia per l'host con il blocco affine.

Poiché Calico è una rete L3 indirizzata, vale la pena notare che le route /26 non sono destinate a subnet. Ad esempio, non esiste alcun indirizzo di rete o broadcast; e gli indirizzi "0" e "255" di un blocco vengono usati come indirizzi IP normali.

Requisiti del piano dati Calico HNS

Esistono diversi requisiti di connettività e criteri Calico per abilitare più subnet in HNS:

  • Tutti i carichi di lavoro nello stesso host devono avere connettività tra loro e ai pod remoti.
  • Tutti i percorsi di pacchetti tra i pod devono avere il seguente valore indipendentemente dal fatto che il mittente e il destinatario si trovino nello stesso host e se accedono direttamente o tramite l'INDIRIZZO IP del cluster del servizio:
    • I criteri di uscita e ingresso dell'elenco di controllo di accesso (ACL) devono essere applicati.
    • Sia i criteri in uscita del pod di invio che i criteri di ingresso del pod ricevente devono consentire il traffico.
    • Tutte le regole ACL programmate da Calico devono essere in grado di visualizzare gli indirizzi IP dei pod.
  • Gli host e i pod devono essere in grado di raggiungere l'un l'altro e di raggiungere i pod in altri host sulle route apprese tramite Il protocollo BGP (Border Gateway Protocol).

Più blocchi IP per ogni requisito dell'host

Per supportare più blocchi IP per host, esaminare i requisiti seguenti:

  • Per un determinato pool IP, il piano dati deve consentire l'aggiunta di pod con indirizzi IP da blocchi IP diversi e non contigui. Ad esempio, il pool IP può essere 10.0.0.0/16, ma un host può richiedere una coppia di blocchi casuali: 10.0.123.0/26 e 10.0.200.0/26.
  • Il pool e le dimensioni dei blocchi non devono essere noti prima della prima allocazione. Questa opzione è altamente consigliata.
  • Altri blocchi dello stesso pool possono essere presenti in altri host.
  • Il prefisso comune dei vari blocchi può sovrapporsi al proprio indirizzo IP dell'host.

Requisiti per supportare il prestito IP

Calico Gestione indirizzi IP alloca gli indirizzi IP all'host in blocchi a scopo di aggregazione. Se il pool IP è pieno, i nodi possono anche prendere in prestito gli INDIRIZZI IP dal blocco di un altro nodo. In termini BGP, il prestito annuncia quindi una route /32 più specifica per l'IP preso in prestito e quindi il traffico per tale IP viene instradato all'host di prestito.

I nodi Windows non supportano questo meccanismo di prestito. Non prenderanno in prestito indirizzi IP anche se il pool IP è pieno e contrassegnano i blocchi in modo che anche i nodi Linux non vengano presi in prestito da essi.

Requisiti per supportare i micropool

Per usare i micropool, viene rimosso il requisito di riservare quattro indirizzi IP per blocco. Nel caso d'uso del micropooling, vengono usati pool molto piccoli e blocchi molto piccoli, quindi quattro INDIRIZZI IP per blocco sprecano la maggior parte degli INDIRIZZI IP. È possibile richiedere un numero ridotto di indirizzi IP riservati per host o per pool. Una procedura consigliata consiste nell'avere tutte le restrizioni di supporto di livello 2 rimosse (ad esempio, non dovrebbe esserci alcun supporto per la trasmissione e nessun IP riservato).

Creare una subnet e una subnet IP con PowerShell

Prima di continuare, assicurarsi di avere installato il modulo HNS.V2.psm1 dalla raccolta di PowerShell HNS.

La procedura seguente illustra come creare una subnet e una subnet IP usando esempi.

  1. Per creare una rete am l2bridge con una subnet IP 192.168.0.0/16 che contiene una subnet IP 192.168.1.0/24 e una subnet IP 192.168.2.0/24, eseguire il comando seguente:

    $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. Per aggiungere una nuova subnet 172.16.0.0/16 contenente una subnet IP 172.16.1.0/16 alla rete l2bridge , eseguire il comando seguente:

    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. Per aggiungere una nuova subnet IP 172.16.2.0/24 alla subnet 172.16.0.0/16, eseguire il comando seguente:

    New-HnsIPSubnet -NetworkID $net1.ID -SubnetID $net2.Subnets[1].ID -IPSubnets @{"IpAddressPrefix"="172.16.2.0/24";"Flags"=0}

Per rimuovere le subnet IP, seguire questa procedura:

  1. Per rimuovere la subnet IP 172.16.2.0/24, eseguire il comando seguente:

       $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. Per rimuovere la subnet 172.16.0.0/16, eseguire il comando seguente:

    Remove-HnsSubnet -NetworkID $net1.ID -Subnets @{"ID"=$net2.Subnets[1].ID}