Netzwerkkonzepte für die Bereitstellung von AKS-Knoten

Artikel
02/17/2024

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

Sie können zwischen zwei IP-Adresszuweisungsmodellen für Ihre Netzwerkarchitektur für AKS wählen, die von Azure Arc aktiviert ist. 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, Lastenausgleichsmodulen und allen Kubernetes-Diensten zu, die auf dem Cluster ausgeführt werden.
DHCP-Netzwerk: Das virtuelle Netzwerk ordnet 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 Architektur des virtuellen Netzwerks unterscheidet sich möglicherweise von der zugrunde liegenden physischen Netzwerkarchitektur in einem Rechenzentrum.

Pool virtueller IP-Adressen

Ein Virtueller IP-Pool (VIP) ist ein Satz von IP-Adressen, die für jede Bereitstellung in AKS Arc obligatorisch sind. Der VIP-Pool ist ein Bereich von reservierten IP-Adressen, die zum Zuweisen 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.

Abhängig von Ihrem Netzwerkmodell unterscheidet sich die Definition des VIP-Pools auf folgende Weise:

Statische IP-Adresse: Wenn Sie statische IP-Adressen 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 IP-Bereich des VIP-Pools aus dem DHCP-Bereich auszuschließen, der für die AKS in Azure Stack HCI-Bereitstellung verwendet wird.

Kubernetes-Knoten-VM-IP-Pool

Kubernetes-Knoten werden als spezialisierte 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-Adresse: Sie müssen einen VM-IP-Poolbereich des Kubernetes-Knotens 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 ein bis drei zusätzliche IP-Adressen benötigen.
DHCP: Sie müssen keinen Kubernetes-Knoten-VM-Pool angeben, da ip-Adressen zu den Kubernetes-Knoten vom DHCP-Server in Ihrem Netzwerk dynamisch 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 Änderungen der Netzwerkkonfiguration zu, wenn 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 es nicht angegeben 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:

Wichtig

In dieser Version von AKS ist es nicht möglich, die Netzwerkkonfiguration zu ändern, sobald der AKS-Host oder der Workloadcluster bereitgestellt wurde. Die einzige Möglichkeit zum Ändern der Netzwerkeinstellungen besteht darin, neu zu beginnen, indem Sie die Workloadcluster entfernen und AKS deinstallieren.

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 es nicht angegeben wird, wird das virtuelle Netzwerk nicht markiert.

Microsoft On-Premise Cloud-Dienst

Microsoft On-Premise Cloud (MOC) ist der Verwaltungsstapel, mit dem virtuelle Computer in Azure Stack HCI und im auf Windows Server basierenden SDDC in der Cloud verwaltet werden können. MOC umfasst Folgendes:

Eine einzelne Instanz eines hochverfügbaren, im Cluster bereitgestellten cloud agent-Diensts. Dieser Agent wird auf jedem Knoten im Azure Stack HCI- oder Windows Server-Cluster ausgeführt und ist für ein Failover zu einem anderen Knoten konfiguriert.
Einen node agent, der auf jedem physischen Azure Stack HCI-Knoten ausgeführt wird.

Um die Kommunikation mit MOC zu ermöglichen, müssen Sie die IP-Adresse CIDR angeben, die für den Dienst verwendet werden soll. 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 in Azure Stack HCI 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-Adresszuordnung hängt vom zugrunde liegenden physischen Netzwerk und den IP-Adressen ab, die für die Azure Stack HCI- oder Windows Server-Clusterknoten in Ihrem Rechenzentrum konfiguriert sind.

Azure Stack HCI- und Windows Server-Clusterknoten mit einem DHCP-basierten IP-Adresszuweisungsmodus: Wenn Ihren Azure Stack HCI-Knoten eine IP-Adresse von einem DHCP-Server zugewiesen wird, der im physischen Netzwerk vorhanden ist, müssen Sie keine explizite IP-Adresse für den MOC-Dienst angeben, da der MOC-Dienst auch eine IP-Adresse vom DHCP-Server empfängt.
Azure Stack HCI- und Windows Server-Clusterknoten mit einem Modell zur Zuordnung statischer IP-Adressen: Wenn Ihren Clusterknoten statische IP-Adressen zugewiesen werden, müssen Sie explizit eine IP-Adresse für den MOC-Clouddienst angeben. Die IP-Adresse für den MOC-Dienst muss sich im selben Subnetz wie die IP-Adressen der Azure Stack HCI- 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-Adressen bieten Netzwerkkonnektivität für Ihre AKS in Azure Stack HCI- 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-Adresse : 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	Statisch zugewiesen mithilfe des VIP-Pools.	Statisch zugewiesen mithilfe des VIP-Pools.
Kubernetes-Knoten (auf virtuellen Computern)	Zugewiesen mithilfe des IP-Pools des Kubernetes-Knotens.	Dynamisch zugewiesen.
Kubernetes-Dienste	Statisch zugewiesen mithilfe des VIP-Pools.	Statisch zugewiesen mithilfe des VIP-Pools.
VM für HAProxy-Lastenausgleich	Zugewiesen mithilfe des IP-Pools des Kubernetes-Knotens.	Dynamisch zugewiesen.
Microsoft On-Premises Cloud Service	Hängt von der physischen Netzwerkkonfiguration für Azure Stack HCI- und Windows Server-Clusterknoten ab.	Hängt von der physischen Netzwerkkonfiguration für Azure Stack HCI- und Windows Server-Clusterknoten ab.
VIP-Pool	Obligatorisch.	Obligatorisch.
Kubernetes-Knoten-VM-IP-Pool	Obligatorisch.	Nicht unterstützt

Mindestreservierungen für IP-Adressen 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-Adresse	Nicht verfügbar	Zwei IP-Adressen	Nicht verfügbar
Workloadcluster	Eine IP-Adresse pro Knoten	Eine IP-Adresse pro Knoten	5 IP-Adressen	Eine IP-Adresse

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 in 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 IT-Administratorin, die gerade mit AKS beginnt, die von Azure Arc aktiviert wurde. Sie möchte zwei Kubernetes-Cluster bereitstellen: Kubernetes-Cluster A und Kubernetes-Cluster B in ihrem Azure Stack HCI-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 Knoten auf Steuerungsebene und 5 Workerknoten.
Kubernetes-Cluster B verfügt über 1 Steuerungsebenenknoten und 3 Workerknoten.
3 Instanzen der Front-End-Benutzeroberfläche (Port 443).
1 instance 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-Adresse für den Knoten der Steuerungsebene und zwei IP-Adressen für die Ausführung von Updatevorgängen).
3 IP-Adressen für die Knoten der Steuerungsebene in Cluster A (eine IP-Adresse pro Steuerungsebenenknoten).
5 IP-Adressen für die Workerknoten in Cluster A (eine IP-Adresse pro Workerknoten).
6 IP-Adressen zusätzlich für Cluster A (fünf IP-Adressen zum Ausführen von Updatevorgängen und 1 IP für Lastenausgleich).
1 IP-Adressen für die Knoten der Steuerungsebene in Cluster B (eine IP-Adresse pro Steuerungsebenenknoten).
3 IP-Adressen für die Workerknoten in Cluster B (eine IP-Adresse pro Workerknoten).
6 IP-Adressen zusätzlich für Cluster B (fünf IP-Adressen zum Ausführen von Updatevorgängen und 1 IP für Load Balancer).
2 IP-Adressen für die Kubernetes-Cluster-API-Server (eine IP-Adresse pro Kubernetes-Cluster).
3 IP-Adressen für den Kubernetes-Dienst (eine IP-Adresse pro instance der Front-End-Benutzeroberfläche, da alle denselben Port verwenden. Die Back-End-Datenbank kann eine der drei IP-Adressen verwenden, solange sie einen anderen Port verwendet.

Wie bereits erläutert, benötigt 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:

VM-IP-Pool für Kubernetes-Knoten: Für Kubernetes-Knoten-VMs und die Lastenausgleichs-VM. 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 auf 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.

Eingangsdatencontroller

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 angibt, dass der Dienst die tatsächliche Anwendung nicht kann. Das heißt, es können keine zusätzlichen Routingüberlegungen vorgenommen werden.

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 auf Azure Stack HCI behandelt. Weitere Informationen finden Sie in den folgenden Artikeln: