Netzwerkkonzepte für die Bereitstellung von AKS-Knoten

Artikel
11/23/2024

Gilt für: AKS auf Azure Stack HCI 22H2, AKS unter Windows Server

Sie können zwischen zwei IP-Adresszuweisungsmodellen für Ihre Netzwerkarchitektur für von Arc aktivierte AKS wählen. AKS unterstützt mehrere Bereitstellungsoptionen für Azure Kubernetes Service (AKS):

Statisches IP-Netzwerk: Das virtuelle Netzwerk weist statische IP-Adressen dem Kubernetes-Cluster-API-Server, Kubernetes-Knoten, zugrunde liegenden VMs, Lastenausgleichsdiensten und allen Kubernetes-Diensten zu, die über dem Cluster ausgeführt werden.
DHCP-Netzwerk: Das virtuelle Netzwerk weist dynamische IP-Adressen den Kubernetes-Knoten, zugrunde liegenden VMs und Lastenausgleichsmodulen mithilfe eines DHCP-Servers zu. Dem API-Server des Kubernetes-Clusters und allen Kubernetes-Diensten, die Sie auf der Grundlage Ihres Clusters ausführen, werden immer noch statische IP-Adressen zugeordnet.

Hinweis

Die hier für AKS Arc definierte virtuelle Netzwerkarchitektur unterscheidet sich möglicherweise von der zugrunde liegenden physischen Netzwerkarchitektur in einem Rechenzentrum.

Pool virtueller IP-Adressen

Ein VIP-Pool (Virtual IP) ist ein Satz von IP-Adressen, die für jede Bereitstellung in AKS Arc obligatorisch sind. Der VIP-Pool ist ein Bereich reservierter IP-Adressen, die zum Zuordnen von IP-Adressen zum Kubernetes-Cluster-API-Server verwendet werden. Dadurch wird sichergestellt, dass Ihre Anwendungen in Kubernetes-Diensten immer erreichbar sind. Beachten Sie, dass unabhängig vom Modell für virtuelle Netzwerke und dem von Ihnen gewählten Adresszuweisungsmodell ein VIP-Pool für Ihre AKS-Hostbereitstellung angegeben werden muss.

Die Anzahl der IP-Adressen im VIP-Pool hängt von der Anzahl der Workloadcluster und Kubernetes-Dienste ab, die für Ihre Bereitstellung geplant sind.

Je nach Netzwerkmodell unterscheidet sich die VIP-Pooldefinition wie folgt:

Statische IP: Wenn Sie statische IP verwenden, stellen Sie sicher, dass Ihre virtuellen IP-Adressen aus demselben Subnetz stammen.
DHCP: Wenn Ihr Netzwerk mit DHCP konfiguriert ist, arbeiten Sie mit Ihrem Netzwerkadministrator zusammen, um den VIP-Pool-IP-Bereich aus dem DHCP-Bereich auszuschließen, der für die AKS in der lokalen Azure-Bereitstellung verwendet wird.

Kubernetes-Knoten-VM-IP-Pool

Kubernetes-Knoten werden als spezielle virtuelle Computer in AKS Arc bereitgestellt. AKS weist diesen virtuellen Computern IP-Adressen zu, um die Kommunikation zwischen Kubernetes-Knoten zu ermöglichen.

Statische IP: Sie müssen einen Kubernetes-Knoten-VM-IP-Poolbereich angeben. Die Anzahl der IP-Adressen in diesem Bereich hängt von der Gesamtzahl der Kubernetes-Knoten ab, die Sie auf Ihrem AKS-Host und den Kubernetes-Workloadclustern bereitstellen möchten. Beachten Sie, dass Updates während des Updates eine bis drei zusätzliche IP-Adressen verbrauchen.
DHCP: Sie müssen keinen Kubernetes-Knoten-VM-Pool angeben, da ip-Adressen für die Kubernetes-Knoten dynamisch vom DHCP-Server in Ihrem Netzwerk zugewiesen werden.

Virtuelles Netzwerk mit statischem IP-Netzwerk (empfohlen)

Dieses Netzwerkmodell erstellt ein virtuelles Netzwerk, das allen Objekten in der Bereitstellung IP-Adressen aus einem statisch definierten Adresspool zuordnet. Ein zusätzlicher Vorteil der Verwendung statischer IP-Netzwerke besteht darin, dass langlebige Bereitstellungen und Anwendungsworkloads garantiert immer erreichbar sind.

Geben Sie beim Definieren eines virtuellen Netzwerks mit statischen IP-Konfigurationen die folgenden Parameter an:

Wichtig

Diese Version von AKS lässt keine Netzwerkkonfigurationsänderungen zu, sobald der AKS-Host oder der Workloadcluster bereitgestellt wurde. Um die Netzwerkeinstellungen zu ändern, müssen Sie neu beginnen, indem Sie die Workloadcluster entfernen und AKS deinstallieren.

Name: Der Name Ihres virtuellen Netzwerks.
Adresspräfix: Das IP-Adresspräfix, das für Ihr Subnetz verwendet werden soll.
Gateway: Die IP-Adresse des Standardgateways für das Subnetz.
DNS-Server: Ein Array von IP-Adressen, die auf die DNS-Server verweisen, die für das Subnetz verwendet werden sollen. Mindestens ein und maximal drei Server können bereitgestellt werden.
VM-Pool des Kubernetes-Knotens: Ein fortlaufender Bereich von IP-Adressen, die für VMs des Kubernetes-Knotens verwendet werden sollen.
Pool virtueller IP-Adressen: Ein fortlaufender Bereich von IP-Adressen, die für den API-Server des Kubernetes-Clusters und die Kubernetes-Dienste verwendet werden.

Hinweis

Der VIP-Pool muss Teil desselben Subnetzes sein, zu dem auch der Kubernetes-Knoten-VM-Pool gehört.
vLAN-ID: Die vLAN-ID für das virtuelle Netzwerk. Wenn er ausgelassen wird, wird das virtuelle Netzwerk nicht markiert.

Virtuelles Netzwerk mit DHCP-Netzwerk

Dieses Netzwerkmodell erstellt ein virtuelles Netzwerk, das allen Objekten in der Bereitstellung mit DHCP IP-Adressen zuordnet.

Beim Definieren eines virtuellen Netzwerks mit statischen IP-Konfigurationen müssen Sie die folgenden Parameter angeben:

Name: Der Name Ihres virtuellen Netzwerks.
Pool virtueller IP-Adressen: Der fortlaufende Bereich von IP-Adressen, die für den API-Server des Kubernetes-Clusters und die Kubernetes-Dienste verwendet werden.

Hinweis

Die VIP-Pooladressen müssen sich im selben Subnetz wie der DHCP-Bereich befinden und müssen aus dem DHCP-Bereich ausgeschlossen werden, um Adresskonflikte zu vermeiden.
vLAN-ID: Die vLAN-ID für das virtuelle Netzwerk. Wenn sie weggelassen wird, wird das virtuelle Netzwerk nicht markiert.

Microsoft On-Premise Cloud-Dienst

Microsoft On-premises Cloud (MOC) ist der Verwaltungsstapel, der es den virtuellen Computern auf azure Local und Windows Server-basierten SDDC ermöglicht, in der Cloud verwaltet zu werden. MOC umfasst Folgendes:

Eine einzelne Instanz eines hochverfügbaren, im Cluster bereitgestellten cloud agent-Diensts. Dieser Agent wird auf einem beliebigen Knoten im lokalen Azure- oder Windows Server-Cluster ausgeführt und ist so konfiguriert, dass ein Failover auf einen anderen Knoten erfolgt.
A node agent running on every Azure Local physical node.

Um die Kommunikation mit MOC zu ermöglichen, müssen Sie die FÜR den Dienst zu verwendende IP-Adresse CIDR angeben. Die -cloudserviceCIDR ist ein Parameter im Set-AksHciConfig-Befehl, mit dem die IP-Adresse dem Cloud-Agent-Dienst zugewiesen und die Hochverfügbarkeit des Cloud-Agent-Diensts ermöglicht wird.

Die Wahl einer IP-Adresse für den MOC-Dienst hängt vom zugrunde liegenden Netzwerkmodell ab, das von Ihrer Clusterbereitstellung auf Azure Local oder Windows Server verwendet wird.

Hinweis

Die IP-Adresszuordnung für den MOC-Dienst ist unabhängig von Ihrem Kubernetes-Modell für virtuelle Netzwerke. Die IP-Adresszuweisung ist von dem zugrunde liegenden physischen Netzwerk abhängig, und die IP-Adressen, die für die lokalen Azure- oder Windows Server-Clusterknoten in Ihrem Rechenzentrum konfiguriert sind.

Azure Local and Windows Server cluster nodes with a DHCP-based IP address allocation mode: If your Azure Local nodes are assigned an IP address from a DHCP server present on the physical network, then you don't need to explicitly provide an the MOC service, as the MOC service also receives an IP address from the DHCP server.
Azure Local and Windows Server cluster nodes with a static IP allocation model: If your cluster nodes are assigned static IP addresses, then you must explicitly provide an IP address for the MOC cloud service. Die IP-Adresse für den MOC-Dienst muss sich im gleichen Subnetz wie die IP-Adressen von Azure Local- und Windows Server-Clusterknoten befinden. Verwenden Sie zum expliziten Zuweisen einer IP-Adresse für den MOC-Dienst den Parameter -cloudserviceCIDR im Befehl Set-AksHciConfig. Stellen Sie sicher, dass Sie eine IP-Adresse im CIDR-Format eingeben, z. B. „10.11.23.45/16“.

Vergleich der Netzwerkmodelle

Sowohl DHCP als auch statische IP bieten Netzwerkkonnektivität in Ihrer AKS auf der lokalen Azure- und Windows Server-Bereitstellung. Es gibt jedoch jeweils Vor- und Nachteile. Ganz allgemein gelten die folgenden Überlegungen:

DHCP – Garantiert keine langlebigen IP-Adressen für einige Ressourcentypen in einer AKS-Bereitstellung. – Unterstützt die Erweiterung reservierter DHCP-IP-Adressen, wenn die Bereitstellung größer als die ursprünglich erwartete wird.

Statische IP : Garantiert langlebige IP-Adressen für alle Ressourcen in einer AKS-Bereitstellung. – Da die automatische Erweiterung des IP-Pools des Kubernetes-Knotens nicht unterstützt wird, können Sie möglicherweise keine neuen Cluster erstellen, wenn Sie den IP-Pool des Kubernetes-Knotens ausgeschöpft haben.

In der folgenden Tabelle wird die IP-Adresszuordnung für Ressourcen zwischen statischen IP- und DHCP-Netzwerkmodellen verglichen:

Funktion	Statische IP	DHCP
API-Server des Kubernetes-Clusters	Die Zuweisung erfolgt statisch mithilfe des VIP-Pools.	Die Zuweisung erfolgt statisch mithilfe des VIP-Pools.
Kubernetes-Knoten (auf virtuellen Computern)	Zugewiesen mit Kubernetes-Knoten-IP-Pool.	Dynamisch zugewiesen.
Kubernetes-Dienste	Die Zuweisung erfolgt statisch mithilfe des VIP-Pools.	Die Zuweisung erfolgt statisch mithilfe des VIP-Pools.
VM für HAProxy-Lastenausgleich	Zugewiesen mit Kubernetes-Knoten-IP-Pool.	Dynamisch zugewiesen.
Microsoft On-Premises Cloud Service	Hängt von der physischen Netzwerkkonfiguration für Lokale Azure- und Windows Server-Clusterknoten ab.	Hängt von der physischen Netzwerkkonfiguration für Lokale Azure- und Windows Server-Clusterknoten ab.
VIP-Pool	Obligatorisch.	Obligatorisch.
Kubernetes-Knoten-VM-IP-Pool	Obligatorisch.	Nicht unterstützt

Minimale IP-Adressreservierungen für eine AKS-Bereitstellung

Unabhängig von Ihrem Bereitstellungsmodell bleibt die Anzahl der reservierten IP-Adressen gleich. In diesem Abschnitt wird die Anzahl der IP-Adressen beschrieben, die Sie basierend auf Ihrem AKS Arc-Bereitstellungsmodell reservieren müssen.

Mindestens zu reservierende IP-Adressen

Sie sollten mindestens die folgende Anzahl von IP-Adressen für Ihre Bereitstellung reservieren:

Clustertyp	Knoten der Steuerungsebene	Workerknoten	Für Aktualisierungsvorgänge	Load Balancer
AKS-Host	Eine IP	Nicht verfügbar	Zwei IP-Adressen	Nicht verfügbar
Workloadcluster	Eine IP pro Knoten	Eine IP pro Knoten	5 IP-Adressen	Eine IP

Zusätzlich sollten Sie die folgende Anzahl von IP-Adressen für Ihren VIP-Pool reservieren:

Ressourcentyp	Anzahl von IP-Adressen
Cluster-API-Server	1 pro Cluster
Kubernetes-Dienste	1 pro Dienst
Anwendungsdienste	1 pro Dienst geplant

Wie Sie sehen können, ist die Anzahl der erforderlichen IP-Adressen abhängig von der Architektur Ihrer AKS-Bereitstellung und der Anzahl der Dienste, die Sie auf Ihrem Kubernetes-Cluster ausführen, variabel. Sie sollten für Ihre Bereitstellung insgesamt 256 IP-Adressen (/24-Subnetz) reservieren.

Exemplarische Vorgehensweise anhand einer Beispielbereitstellung

Jane ist ein IT-Administrator, der gerade mit AKS beginnt, die von Azure Arc aktiviert sind. Sie möchte zwei Kubernetes-Cluster bereitstellen: Kubernetes-Cluster A und Kubernetes Cluster B auf ihrem lokalen Azure-Cluster. Sie möchte auch eine Abstimmungsanwendung auf der Grundlage Ihres Clusters ausführen. Diese Anwendung verfügt über drei Instanzen der Front-End-Benutzeroberfläche, die über die beiden Cluster und eine Instanz der Back-End-Datenbank ausgeführt werden.

Kubernetes-Cluster A verfügt über 3 Steuerebenenknoten und 5 Arbeitsknoten.
Kubernetes-Cluster B verfügt über 1 Steuerebenenknoten und 3 Arbeitsknoten.
3 Instanzen der Front-End-Benutzeroberfläche (Port 443).
1 Instanz der Back-End-Datenbank (Port 80).

Basierend auf der vorherigen Tabelle muss sie Folgendes reservieren:

3 IP-Adressen für den AKS-Host (eine IP für Steuerebenenknoten und zwei IPs für die Ausführung von Updatevorgängen).
3 IP-Adressen für die Steuerebenenknoten im Cluster A (eine IP pro Steuerebenenknoten).
5 IP-Adressen für die Workerknoten im Cluster A (eine IP pro Arbeitsknoten).
6 IP-Adressen zusätzlich für Cluster A (fünf IPs für die Ausführung von Updatevorgängen und 1 IP für lastenausgleich).
1 IP-Adressen für die Steuerebenenknoten im Cluster B (eine IP pro Steuerebenenknoten).
3 IP-Adressen für die Workerknoten im Cluster B (eine IP pro Arbeitsknoten).
6 IP-Adressen zusätzlich für Cluster B (fünf IPs für die Ausführung von Updatevorgängen und 1 IP für lastenausgleich).
2 IP-Adressen für die Kubernetes-Cluster-API-Server (eine IP pro Kubernetes-Cluster).
3 IP-Adressen für den Kubernetes-Dienst (eine IP-Adresse pro Instanz der Front-End-UI, da sie alle denselben Port verwenden. Die Back-End-Datenbank kann eine der drei IP-Adressen verwenden, solange ein anderer Port verwendet wird).

Wie zuvor erläutert, erfordert Jane insgesamt 32 IP-Adressen, um den Cluster bereitzustellen. Jane sollte daher ein /26-Subnetz für ihr virtuelles Netzwerk reservieren.

Aufteilen reservierter IP-Adressen basierend auf einem statischen IP-Netzwerkmodell

Während die Gesamtzahl der reservierten IP-Adressen gleich bleibt, bestimmt das Bereitstellungsmodell, wie diese IP-Adressen auf IP-Gruppen aufgeteilt werden. Das statische IP-Netzwerkmodell verfügt über zwei IP-Pools:

Kubernetes-Knoten-VM-IP-Pool: für Kubernetes-Knoten-VMs und die VM des Lastenausgleichs. Dieser IP-Pool enthält auch die IP-Adresse, die zum Ausführen von Aktualisierungsvorgängen erforderlich ist.
Virtueller IP-Pool: für den Kubernetes-API-Server und Kubernetes-Dienste.

In diesem Beispiel muss Jane diese IP-Adressen weiter in VIP-Pools und Kubernetes-Knoten-IP-Pools unterteilen:

Fünf (zwei für den Kubernetes-Cluster-API-Server und drei für Kubernetes-Dienste) der 32 IP-Adressen für ihren VIP-Pool.
27 (alle IP-Adressen für ihre Kubernetes-Knoten und zugrunde liegenden VMs, Lastenausgleichs-VMs und Aktualisierungsvorgänge) für ihren IP-Pool des Kubernetes-Knotens.

Aufteilen reservierter IP-Adressen basierend auf einem statischen DHCP-Netzwerkmodell

Während die Gesamtzahl der reservierten IP-Adressen gleich bleibt, bestimmt das Bereitstellungsmodell, wie diese IP-Adressen auf IP-Gruppe(n) aufgeteilt werden. Wie im vorherigen Abschnitt erläutert, verfügt das DHCP-Netzwerkmodell über einen IP-Bereich:

Virtueller IP-Pool: für den Kubernetes-API-Server und Kubernetes-Dienste

Arbeiten mit dem vorherigen Beispiel:

Jane muss insgesamt 32 IP-Adressen oder ein /26-Subnetz auf dem DHCP-Server reservieren.
Sie muss fünf (zwei für den Kubernetes-Cluster-API-Server und drei für Kubernetes-Dienste) aus dem DHCP-Bereich der 32 IP-Adressen für ihren VIP-Pool ausschließen.

Eingangscontroller

Während der Bereitstellung eines Zielclusters wird eine Lastenausgleichsressource auf HAProxy-Basis erstellt. Der Lastenausgleich wird zum Verteilen von Datenverkehr auf die Pods in Ihrem Dienst über einen bestimmten Port konfiguriert. Der Lastenausgleich funktioniert nur auf Ebene 4, was darauf hinweist, dass der Dienst der tatsächlichen Anwendung nicht bewusst ist; Das heißt, es kann keine zusätzlichen Routingüberlegungen treffen.

Eingangscontroller arbeiten auf Schicht 7, sodass intelligentere Regeln zum Verteilen des Anwendungsdatenverkehrs verwendet werden können. Eine häufige Verwendung eines Eingangscontrollers besteht darin, HTTP-Datenverkehr basierend auf der eingehenden URL an verschiedene Anwendungen weiterzuleiten.

Nächste Schritte

In diesem Artikel werden einige der Netzwerkkonzepte für die Bereitstellung von AKS-Knoten in Azure Local behandelt. Weitere Informationen finden Sie in den folgenden Artikeln:

Freigeben über