Unterstützung mehrerer Subnetze im Hostnetzwerkdienst

  • Artikel

Gilt für: Windows Server 2022

Die Verwendung mehrerer Subnetze pro Netzwerk wird jetzt in Host Networking Service (HNS) für Windows-Container unterstützt. Zuvor wurden von HNS eingeschränkte Kubernetes-Containerendpunktkonfigurationen verwendet, um nur die Präfixlänge des zugrunde liegenden Subnetzes zu verwenden. HNS wurde verbessert, sodass Sie restriktivere Subnetze wie Subnetze mit einer längeren Präfixlänge sowie mehrere Subnetze pro Windows-Workerknoten verwenden können. Die erste Containernetzwerkschnittstelle (Container Networking Interface, CNI), die diese Funktionalität verwenden kann, ist Calico für Windows. Calico Network Policies ist eine Open-Source-Netzwerk- und Netzwerksicherheitslösung, die von Tigera gegründet wurde.

Sie können mehrere Subnetze in HNS nur für l2bridge-, l2tunnel- und Überlagerungsnetzwerktreiber verwenden. Diese Netzwerktreiber können mehrere Subnetze verfügbar machen und dann jedem Endpunkt erlauben, eine Bindung an eines dieser Subnetze durchzuführen.

HNS und der Host Compute Service (HCS) arbeiten zusammen, um Container zu erstellen und Endpunkte an ein Netzwerk anzufügen. Sie können mit HNS mithilfe des HNS Powershell-Hilfsmoduls interagieren.

Calico-Anforderungen

Für die Calico CNI-Unterstützung mehrerer Subnetze muss das Subnetz in kleinere IP-Blöcke unterteilt werden. Alle IP-Blöcke müssen dasselbe Gateway gemeinsam nutzen, aber jeder IP-Block kann über eine eigene separate Übertragung verfügen Standard. Um die IPV4-Zuordnung so effizient wie möglich zu maximieren, erfordert Calico das Erstellen sehr kleiner IP-Blöcke (so klein wie ein Block = vier IP-Adressen), zusätzlich zum Festlegen sehr kleiner Präfixe für Containerendpunkte (so klein wie /32).

Eine vollständige Implementierung von Calico IP-Adressverwaltung (IPAM) funktioniert wie folgt:

Calicos IPAM-Funktion wurde entwickelt, um IP-Adressen bei Bedarf Workloads zuzuweisen. Calico unterstützt auch mehrere IP-Pools für administrative Gruppierung. Bei der Konfiguration einer Zuordnung für eine bestimmte Workload kann die Gruppe zulässiger Pools durch die Konfiguration eingeschränkt werden, was verschiedene Anwendungsfälle ermöglicht. Befolgen Sie die folgenden Richtlinien für unterschiedliche Anwendungsfälle:

  • Verwenden Sie mehrere nicht zusammenhängende Pools, um die Kapazität zu erhöhen.
  • Konfigurieren Sie für l2bridge-Netzwerke innerhalb eines Racks einen IP-Pool pro Rack, in dem die Hosts innerhalb eines Racks nur von einem bestimmten Pool zuordnen können.
  • Verwenden Sie einen IP-Pool pro Stapelebene, in dem Front-End-Pods IPs aus einem Front-End-Pool (die öffentlich sein könnten), aber Back-End-Pods (möglicherweise auf demselben Host) empfangen IPs aus einem anderen Bereich. Dies ermöglicht Calico die Anpassung an aggressive Netzwerkpartitionierungsanforderungen (wie möglicherweise erforderlich, um mit älteren Firewalls zu arbeiten).
  • Verwenden Sie sehr kleine Mikropools, eine für jede Ebene eines Stapels. Da diese Pools so klein sind, benötigen sie jeden Host, um Workloads aus mehreren Pools zu unterstützen.

IPs werden immer aus Blöcken zugewiesen, und diese Blöcke können auf einen bestimmten Host affin sein. Ein Host versucht immer, IPs aus einem eigenen affinen Block zuzuweisen, wenn Platz vorhanden ist (und nur, wenn der Block aus einem zulässigen Pool für die angegebene Workload stammt). Wenn keiner der vorhandenen Blöcke des Hosts Platz hat, versucht der Host, einen neuen Block aus einem zulässigen Pool anzufordern. Wenn keine leeren Blöcke verfügbar sind, leiht der Host eine IP aus einem beliebigen Block in einem zulässigen Pool, der freien Speicherplatz zur Verfügung hat, auch wenn dieser Block auf einen anderen Host affine ist.

Calico basiert auf dem längsten Präfix-Übereinstimmungsrouting zur Unterstützung der Aggregation. Jeder Host kündigt Routen für alle affinen Blöcke an und kündigt /32 Routen für alle Ip-Adressen an, die es geliehen hat. Da eine /32-Route spezifischer ist, verwenden Remotehosts, die an die /32 weiterleiten müssen, die /32-Route anstelle der breiteren /26-Route zum Host mit dem affinen Block.

Da Calico ein routingfähiges L3-Netzwerk ist, ist es erwähnenswert, dass die /26-Routen nicht als Subnetze vorgesehen sind. Beispielsweise gibt es keine Netzwerk- oder Übertragungsadresse; und die Adressen "0" und "255" eines Blocks werden als normale IPs verwendet.

Calico HNS-Datenebenenanforderungen

Es gibt mehrere Calico-Konnektivitäts- und Richtlinienanforderungen, um mehrere Subnetze in HNS zu aktivieren:

  • Alle Workloads auf demselben Host müssen über eine Verbindung zueinander und mit Remote-Pods verfügen.
  • Alle Paketpfade zwischen Pods sollten folgendes aufweisen, unabhängig davon, ob sich der Absender und der Empfänger auf demselben Host befinden und ob sie entweder direkt oder über die Dienstcluster-IP auf einander zugreifen:
    • Zugriffssteuerungsliste (Access Control List, ACL)-Ausgangs- und Eingangsrichtlinien müssen angewendet werden.
    • Sowohl die Ausgangsrichtlinie des sendenden Pods als auch die Eingangsrichtlinie des empfangenden Pods müssen den Datenverkehr zulassen.
    • Alle Calico-programmierten ACL-Regeln sollten pod-IPs anzeigen können.
  • Hosts und Pods müssen in der Lage sein, sich gegenseitig zu erreichen und Pods auf anderen Hosts über Routen zu erreichen, die über das Border Gateway Protocol (BGP) gelernt wurden.

Mehrere IP-Blöcke pro Hostanforderungen

Um mehrere IP-Blöcke pro Host zu unterstützen, überprüfen Sie die folgenden Anforderungen:

  • Für einen bestimmten einzelnen IP-Pool muss die Datenebene zulassen, dass Pods mit IPs aus unterschiedlichen, nicht zusammenhängenden IP-Blöcken hinzugefügt werden. Beispielsweise kann der IP-Pool 10.0.0.0/16 sein, aber ein Host kann ein Paar zufälliger Blöcke beanspruchen: 10.0.123.0/26 und 10.0.200.0/26.
  • Der Pool und die Größe der Blöcke müssen nicht im Voraus der ersten Zuordnung bekannt sein. Dies wird dringend empfohlen.
  • Andere Blöcke aus demselben Pool können auf anderen Hosts vorhanden sein.
  • Das allgemeine Präfix der verschiedenen Blöcke kann sich mit der eigenen IP-Adresse des Hosts überlappen.

Anforderungen zur Unterstützung von IP-Krediten

Calico IPAM weist IPs zu Aggregationszwecken in Blöcken zu. Wenn der IP-Pool voll ist, können Knoten auch IPs aus dem Block eines anderen Knotens ausleihen . In BGP-Bedingungen kündigt der Darlehensnehmer dann eine spezifischere /32 Route für die geliehene IP an und dann datenverkehr für diese IP wird an den Kredithost weitergeleitet.

Windows-Knoten unterstützen diesen Kreditmechanismus nicht. Sie werden IPs nicht ausleihen, auch wenn der IP-Pool voll ist, und sie markieren ihre Blöcke, damit Linux-Knoten auch nicht von ihnen leihen.

Anforderungen zur Unterstützung von Mikropools

Um Mikropools zu verwenden, wird die Anforderung, vier IPs pro Block zu reservieren, entfernt. Im Mikropool-Anwendungsfall werden sehr kleine Pools und sehr kleine Blöcke verwendet, sodass vier IPs pro Block die meisten IPs verschwendet. Sie können eine kleine Anzahl reservierter IPs pro Host oder pro Pool anfordern. Es empfiehlt sich, alle Einschränkungen für die Unterstützung der Ebene 2 aufzuheben (z. B. sollte keine Unterstützung für Die Übertragung und keine reservierten IPs vorhanden sein).

Erstellen eines Subnetzes und eines IP-Subnetzes mithilfe von PowerShell

Bevor Sie fortfahren, stellen Sie sicher, dass das HNS.V2.psm1-Modul aus dem HNS PowerShell-Katalog installiert ist.

In den folgenden Schritten wird erläutert, wie Sie mithilfe von Beispielen ein Subnetz und ein IP-Subnetz erstellen.

  1. Um am l2bridge-Netzwerk mit einem Subnetz von 192.168.0.0/16 zu erstellen, das ein 192.168.1.0/24-IP-Subnetz und ein 192.168.2.0/24-IP-Subnetz enthält, führen Sie den folgenden Befehl aus:

    $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. Um ein neues Subnetz 172.16.0.0/16 hinzuzufügen, das ein IP-Subnetz 172.16.1.0/16 enthält, führen Sie den folgenden Befehl aus:

    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. Um ein neues 172.16.2.0/24-IP-Subnetz zum Subnetz 172.16.0.0/16 hinzuzufügen, führen Sie den folgenden Befehl aus:

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

Führen Sie die folgenden Schritte aus, um die IP-Subnetze zu entfernen:

  1. Führen Sie den folgenden Befehl aus, um das IP-Subnetz 172.16.2.0/24 zu entfernen:

       $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. Führen Sie den folgenden Befehl aus, um das Subnetz 172.16.0.0/16 zu entfernen:

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