Bereitstellen eines Kubernetes-Clusters in einem benutzerdefinierten virtuellen Netzwerk in Azure Stack Hub

Artikel
01/30/2025

Sie können einen Kubernetes-Cluster mithilfe der AKS-Engine (Azure Kubernetes Service) in einem benutzerdefinierten virtuellen Netzwerk bereitstellen. In diesem Artikel wird beschrieben, wie Sie die benötigten Informationen in Ihrem virtuellen Netzwerk finden. Der Artikel enthält Schritte zum Berechnen der ip-Adressen, die von Ihrem Cluster verwendet werden, das Festlegen der Werte im API-Modell und das Festlegen der Routentabelle und der Netzwerksicherheitsgruppe.

Der Kubernetes-Cluster im Azure Stack Hub mit dem AKS-Modul verwendet das Kubenet-Netzwerk-Plug-In. Das AKS-Modul auf Azure Stack Hub unterstützt auch das Azure CNI-Netzwerk-Plug-In.

Informationen zum kubenet-Netzwerk-Plug-In in Azure finden Sie unter Verwenden von kubenet-Netzwerken mit Ihren eigenen IP-Adressbereichen in Azure Kubernetes Service (AKS).
Informationen zum Azure CNI-Netzwerk-Plug-In in Azure finden Sie unter Konfigurieren von Azure CNI-Netzwerken in Azure Kubernetes Service (AKS).

Überlegungen beim Erstellen eines benutzerdefinierten virtuellen Netzwerks

Das benutzerdefinierte VNET muss sich im gleichen Abonnement befinden wie alle anderen Komponenten des Kubernetes-Clusters.
Der Knotenpool der Steuerungsebene und der Agent-Knotenpool müssen sich im selben virtuellen Netzwerk befinden. Sie können Ihre Knoten in unterschiedlichen Subnetzen innerhalb des gleichen virtuellen Netzwerks bereitstellen.
Das Kubernetes-Cluster-Subnetz muss einen IP-Bereich innerhalb des Raums des benutzerdefinierten virtuellen Netzwerk-IP-Bereichs verwenden. Weitere Informationen finden Sie unter Ermitteln des IP-Adressblocks.
Beachten Sie, dass die empfohlene Größe der Knotensubnetze vom Typ des verwendeten Netzwerk-Plug-Ins abhängt. Allgemein gilt, dass beim Azure CNI mehr IP-Adressen für das Subnetz für die Agent-Knotenpools benötigt werden als bei kubenet. Sehen Sie sich die folgenden beispiele kubenet und Azure CNI an.
Der 169.254.0.0/16 Adressraum kann nicht für benutzerdefinierte VNETs für Kubernetes-Cluster verwendet werden.

Erstellen des benutzerdefinierten virtuellen Netzwerks

Sie müssen in Ihrer Azure Stack Hub-Instanz über ein benutzerdefiniertes virtuelles Netzwerk verfügen. Weitere Informationen finden Sie unter Quickstart: Erstellen eines virtuellen Netzwerks im Azure-Portal.

Erstellen Sie in Ihrem virtuellen Netzwerk ein neues Subnetz. Sie müssen die Subnetz-Resource-ID und den IP-Adressbereich abrufen, die Sie beim Bereitstellen des Clusters im API-Modell verwenden.

Öffnen Sie in Ihrer Azure Stack Hub-Instanz das Azure Stack Hub-Benutzerportal.
Wählen Sie Alle Ressourcen.
Geben Sie den Namen Ihres virtuellen Netzwerks in das Suchfeld ein.
Wählen Sie Subnetze>+ Subnetze aus, um ein Subnetz hinzuzufügen.
Fügen Sie unter Name einen Namen und unter Adressbereich einen Adressbereich in CIDR-Notation hinzu. Wählen Sie OK aus.
Wählen Sie auf der Seite Virtuelle Netzwerke die Option Eigenschaften aus. Kopieren Sie den unter Ressourcen-ID angegebenen Wert, und fügen Sie /subnets/<nameofyoursubnect> hinzu. Sie verwenden diesen Wert als Wert für den vnetSubnetId Schlüssel im API-Modell für Ihren Cluster. Die Ressourcen-ID für das Subnetz verwendet das folgende Format: /subscriptions/SUB_ID/resourceGroups/RG_NAME/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME.
Wählen Sie auf der Seite Virtuelle Netzwerke die Option Subnetze aus. Wählen Sie den Namen des Subnetzes aus, z. B. control-plane-sn. Ordnen Sie das Subnetz keiner Netzwerksicherheitsgruppe (NSG) zu.
Notieren Sie sich den Adressbereich (CIDR-Block) auf dem Subnetzblatt für alle Subnetze.

Überlegungen zur Auswahl eines Adressraums

Wenn Sie ein benutzerdefiniertes virtuelles Netzwerk erstellen, geben Sie den IP-Adressraum Ihres Netzwerks und einen IP-Adressraum für jedes Subnetz an. Berücksichtigen Sie die folgenden Faktoren, wenn Sie die Adressräume und -bereiche auswählen, die in Ihrem Kubernetes-Cluster verwendet werden sollen:

Überlappende Adressräume können zu Konflikten von IP-Adressen oder Kommunikationsfehlern führen. Wählen Sie einen eindeutigen Adressraum für das neue virtuelle Netzwerk aus, um das Risiko der Überlappung von IP-Adressen zu verringern.
Adressräume in den Bereichen 10/8, 172.16/12 und 192.168/16 werden häufig für private Netzwerke verwendet und könnten bereits von Ihrer vorhandenen Rechenzentrumsinfrastruktur verwendet werden. Wenn Ihre Kubernetes-Anwendungen Ressourcen in Ihrem Rechenzentrum verwenden, verringern Sie das Risiko von Konflikten, indem Sie für Ihr benutzerdefiniertes virtuelles Netzwerk einen Adressraum auswählen, der sich vom Adressraum Ihres Rechenzentrums unterscheidet.
Sie sollten ein dediziertes Subnetz für den Kubernetes-Cluster verwenden.
Wenn Sie mehrere vorhandene virtuelle Netzwerke verwenden, sollten Sie unterschiedliche Adressräume in jedem Netzwerk verwenden, wenn Sie das virtuelle Netzwerk-Peering verwenden möchten. Überlappende Adressräume können ihre Fähigkeit zum Aktivieren von Peering beeinträchtigen.

Festlegen der IP-Adressblöcke

Das AKS-Modul unterstützt die Bereitstellung in einem vorhandenen virtuellen Netzwerk. Wenn Sie in einem vorhandenen virtuellen Netzwerk bereitgestellt werden, verwendet Ihr Cluster Blöcke aufeinander folgender Adressen für Agentknoten, Steuerungsebenenknoten, Clusterdienste und Container (Pods). Jeder Adressblock kann in ein Subnetz innerhalb des virtuellen Netzwerks übersetzt werden. Alle Adressblöcke in der Clusterbereitstellung müssen Teil des gesamten virtuellen Netzwerkadressraums sein. Das Auswählen von Adressblöcken außerhalb des virtuellen Netzwerkadressraums kann zu Verbindungsproblemen führen.

Beim Einrichten eines Kubernetes-Clusters sind mindestens drei Adressblöcke erforderlich:

Knotenadressblock: Der Adressblock, der zum Zuweisen von Adressen zu den Clusterknoten verwendet wird. Dieser Wert kann ein einzelner Adressblock für alle Clusterknoten sein oder separate Blöcke (Subnetze) für Steuerebenen- und Agentpools sein. Berücksichtigen Sie bei der Auswahl des Adressbereichs für diesen Block die Anzahl der Knoten in Ihrem Cluster. Für Azure CNI erhalten Knoten und Container ihre Adressen aus demselben Adressblock, berücksichtigen daher die Anzahl der Container, die Sie in Ihrem Cluster bereitstellen möchten, wenn Sie den Adressbereich bei Verwendung von Azure CNI auswählen.
Dienstadressblock: Der Adressblock, aus dem Dienste, die im Kubernetes-Cluster bereitgestellt wurden, ihre Clusteradresse abrufen. Berücksichtigen Sie bei der Auswahl des Adressbereichs für diesen Block die maximale Anzahl von Diensten, die Sie in Ihrem Cluster ausführen möchten.
Cluster-Adressblock: Der Adressblock, aus dem Pods ihre Clusteradresse erhalten. Berücksichtigen Sie bei der Auswahl des Adressbereichs für diesen Block die maximale Anzahl von Pods, die Sie in Ihrem Cluster ausführen möchten. Wie bereits erwähnt, sind beim Azure CNI der Cluster- und Knotenadressblock identisch.

Zusätzlich zu den Adressblöcken müssen Sie für Steuerebenenknoten zwei weitere Werte festlegen. Sie müssen die Anzahl der IP-Adressen kennen, die für Ihren Cluster reserviert werden sollen, und die erste aufeinander folgende statische IP innerhalb des Subnetz-IP-Raums. Das AKS-Modul erfordert einen Bereich von bis zu 16 nicht verwendeten IP-Adressen, wenn Sie mehrere Steuerebenenknoten verwenden. Der Cluster verwendet eine IP-Adresse für jede Steuerungsebene bis zu fünf Steuerebenenknoten. Die AKS-Engine erfordert auch die nächsten 10 IP-Adressen nach dem letzten Steuerungsebenenknoten als Toleranzbereich für die IP-Adressenreservierung. Letztendlich wird nach der Reservierung für die Steuerungsebenenknoten und den Toleranzbereich eine weitere IP-Adresse vom Load Balancer verwendet, insgesamt somit 16. Bei der Platzierung Ihres IP-Adressblocks benötigt das Subnetz die folgenden Zuteilungen der vorhandenen IP-Adressen:

Die ersten vier IP-Adressen und die letzte IP-Adresse sind reserviert und können nicht in einem Azure-Subnetz verwendet werden.
Ein Puffer von 16 IP-Adressen sollte frei bleiben.
Der Wert der ersten IP-Adresse Ihres Clusters sollte sich am Ende des Adressraums befinden, um IP-Konflikte zu vermeiden. Wenn möglich, weisen Sie die firstConsecutiveStaticIP Eigenschaft einer IP-Adresse am Ende des verfügbaren IP-Adressraums im Subnetz zu.

Zum Beispiel, wenn Sie für einen Cluster mit drei Steuerungsknoten ein Subnetz mit 256 Adressen verwenden, zum Beispiel 10.100.0.0/24, müssen Sie Ihre erste aufeinanderfolgende statische IP-Adresse vor 239 festlegen. Die folgende Tabelle enthält die Adressen und die entsprechenden Überlegungen:

Bereich für Subnetz vom Typ „/24“	Anzahl	Hinweis
172.100.0.0–172.100.0.3	4	Reserviert im Azure-Subnetz
172.100.0.224-172.100.0.238	14	Anzahl von IP-Adressen für einen von der AKS-Engine definierten Cluster Drei IP-Adressen für drei Knoten der Steuerungsebene Zehn IP-Adressen als Reserve Eine IP-Adresse für den Lastenausgleich
172.100.0.238 – 172.100.0.254	16	16 IP-Adressen als Puffer
172.100.0.255	1	Reserviert im Azure-Subnetz

In diesem Beispiel lautet die firstConsecutiveStaticIP-Eigenschaft 172.100.0.224.

Für größere Subnetze; Beispielsweise /16 mit mehr als 60 Tausend Adressen ist es möglicherweise nicht praktisch, Ihre statischen IP-Zuordnungen am Ende des Netzwerkraums festzulegen. Legen Sie den statischen IP-Adressbereich Ihres Clusters nach den ersten 24 Adressen Ihres IP-Adressbereichs fest, um die Resilienz des Clusters bei der Beanspruchung von Adressen zu gewährleisten.

Beispiel für Adressblöcke mit kubenet

Im folgenden Beispiel können Sie sehen, wie der Adressraum im virtuellen Netzwerk für einen Cluster basierend auf diesen verschiedenen Überlegungen aufgeteilt ist, wenn das Netzwerk-Plug-In kubenet mit dedizierten Subnetzen für den Knoten der Steuerungsebene und Agent-Knotenpools mit drei Knoten pro Pool verwendet wird.

Adressraum des virtuellen Netzwerks: 10.100.0.0/16

Adressblock (Subnetz)	CIDR	IP-Adressbereich	Anzahl IP-Adressen (verfügbar)
Block der Knoten der Steuerungsebene	10.100.0.0/24	10.100.0.0–10.100.0.255	255 – 4 reservierte = 251
Agent-Knotenblock	10.100.1.0/24	10.100.1.0–10.100.1.255	255 – 4 reservierte = 251
Dienstblock	10.100.16.0/20	10.100.16.0–10.100.31.255	4.096 – 5 reservierte = 4.091
Clusterblock	10.100.128.0/17	10.100.128.0–10.100.255.255	32.768 – 5 reservierte = 32.763

In diesem Beispiel lautet die firstConsecutiveStaticIP-Eigenschaft 10.100.0.239.

Beispiel für Adressblöcke mit dem Azure CNI

Im folgenden Beispiel können Sie sehen, wie der Adressraum im virtuellen Netzwerk für einen Cluster basierend auf diesen verschiedenen Überlegungen aufgeteilt ist, wenn das Netzwerk-Plug-In Azure CNI mit dedizierten Subnetzen für den Steuerungsebenen- und den Agent-Knotenpool mit drei Knoten pro Pool verwendet wird.

Adressraum des virtuellen Netzwerks: 172.24.0.0/16

Hinweis

Wenn sich in Ihrer Umgebung der öffentliche IP-Adressbereich innerhalb von CIDR10.0.0.0/8 befindet, verwenden Sie kubenet als Netzwerk-Plug-In.

Adressblock (Subnetz)	CIDR	IP-Adressbereich	Anzahl IP-Adressen (verfügbar)
Block der Knoten der Steuerungsebene	172.24.0.0/24	172.24.0.0–172.24.0.255	255 – 4 reservierte = 251
Agentknoten und Clusterblock	172.24.128.0/17	172.24.128.0–172.24.255.255	32.768 – 5 reservierte = 32.763
Dienstblock	172.24.16.0/20	172.24.16.0 – 172.24.31.255	4.096 – 5 reservierte = 4.091

In diesem Beispiel wäre der Wert für die Eigenschaft firstConsecutiveStaticIP172.24.0.239.

Aktualisieren des API-Modells

Aktualisieren Sie das API-Modell, das zum Bereitstellen des Clusters vom AKS-Modul in Ihrem benutzerdefinierten virtuellen Netzwerk verwendet wird.

Legen Sie in masterProfile-die folgenden Werte fest:

Feld	Beispiel	Beschreibung
vnetSubnetId	`/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn`	Geben Sie die Azure Resource Manager-Pfad-ID des Subnetzes an. Dieser Wert ist dem Adressblock der Steuerungsebenenknoten zugeordnet.
firstConsecutiveStaticIP	10.100.0.239	Weisen Sie der Konfigurationseigenschaft `firstConsecutiveStaticIP` eine IP-Adresse gegen Ende des verfügbaren IP-Adressraums im gewünschten Subnetz zu. `firstConsecutiveStaticIP` gilt nur für den Knotenpool der Steuerungsebene.

Legen Sie in agentPoolProfiles die folgenden Werte fest:

Feld	Beispiel	Beschreibung
vnetSubnetId	`/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn`	Geben Sie die Azure Resource Manager-Pfad-ID des Subnetzes an. Dieser Wert ist dem Adressblock der Agent-Knoten zugeordnet.

Suchen Sie in orchestratorProfile nach kubernetesConfig, und legen Sie den folgenden Wert fest:

Feld	Beispiel	Beschreibung
clusterSubnet	`10.100.128.0/17`	Das IP-Subnetz zum Zuordnen von IP-Adressen für Pod-Netzwerkschnittstellen. Dieser Wert ist dem Clusteradressblock zugeordnet. Das Subnetz muss sich im VNET-Adressraum befinden. Bei aktiviertem Azure CNI lautet der Standardwert 10.240.0.0/12. Ohne Azure CNI lautet der Standardwert 10.244.0.0/16. Verwenden Sie das Subnetz /16 anstelle von /24. Wenn Sie /24 verwenden, wird dieses Subnetz nur einem Knoten zugewiesen. Der andere Knoten erhält kein POD-Netzwerk zugewiesen, da der verfügbare IP-Bereich erschöpft ist, deshalb sind sie im Cluster nicht einsatzbereit.
serviceCidr	`10.100.16.0/20`	Hierbei handelt es sich um das IP-Subnetz, das zum Zuordnen von IP-Adressen für im Cluster bereitgestellte Dienste verwendet wird. Dieser Wert wird dem Clusterdienstblock zugeordnet.
dnsServiceIP	`10.100.16.10`	Hierbei handelt es sich um die IP-Adresse, die dem DNS-Dienst des Clusters zugewiesen werden soll. Die Adresse muss aus dem Subnetz serviceCidr stammen. Dieser Wert muss beim Angeben von serviceCidr festgelegt werden. Der Standardwert ist die .10-Adresse des Subnetzes serviceCidr.

Beispiel bei Verwendung von kubenet:
Mit einem Netzwerkadressraum von 10.100.0.0/16, in dem das Subnetz für control-plane-sn10.100.0.0/24 ist und agents-sn10.100.1.0/24 ist

"masterProfile": {
  ...
  "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
  "firstConsecutiveStaticIP": "10.100.0.239",
  ...
},
...
"agentPoolProfiles": [
  {
    ...
    "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn",
    ...
  },
    ...
"kubernetesConfig": [
  {
    ...
    "clusterSubnet": "10.100.128.0/17",
    "serviceCidr": "10.100.16.0/20",
    "dnsServiceIP" : "10.100.16.10",

    ...
  },

Wenn Sie beispielsweise Azure CNI mit einem Netzwerkadressraum von 172.24.0.0/16 verwenden, in dem das Subnetz für control-plane-sn172.24.0.0/24 ist und k8s-sn172.24.128.0/17ist:

"masterProfile": {
  ...
  "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
  "firstConsecutiveStaticIP": "172.24.0.239",
  ...
},
...
"agentPoolProfiles": [
  {
    ...
    "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/k8s-sn",
    ...
  },
    ...
"kubernetesConfig": [
  {
    ...
    "clusterSubnet": "172.24.128.0/17",
    "serviceCidr": "172.24.16.0/20",
    "dnsServiceIP" : "172.24.16.10",
    ...
  },

Bereitstellen Ihres Clusters

Nachdem Sie die Werte Ihrem API-Modell hinzugefügt haben, können Sie den Cluster mit dem Befehl deploy in der AKS-Engine über Ihren Clientcomputer bereitstellen. Eine entsprechende Anleitung finden Sie unter Bereitstellen eines Kubernetes-Clusters.

Festlegen der Routingtabelle

Wenn Sie kubenet verwenden, z. B. mit networkPlugin: kubenet im kubernetesConfig-API-Modellkonfigurationsobjekt, gilt Folgendes: Kehren Sie nach der Clusterbereitstellung zu Ihrem virtuellen Netzwerk im Azure Stack-Benutzerportal zurück. Legen Sie auf dem Subnetzblatt sowohl die Routingtabelle als auch die Netzwerksicherheitsgruppe (NSG) fest – Ermitteln Sie nach erfolgreicher Bereitstellung eines Clusters im benutzerdefinierten virtuellen Netzwerk die ID der Routingtabellenressource auf dem Blatt Netzwerk in der Ressourcengruppe Ihres Clusters.

Öffnen Sie in Ihrer Azure Stack Hub-Instanz das Azure Stack Hub-Benutzerportal.
Wählen Sie Alle Ressourcen.
Geben Sie den Namen Ihres virtuellen Netzwerks in das Suchfeld ein.
Wählen Sie Subnetze und anschließend den Namen des Subnetzes aus, das Ihren Cluster enthält.
Wählen Sie Routingtabelle und anschließend die Routingtabelle für Ihren Cluster aus.
Stellen Sie sicher, dass dies für jedes subnetz, das im API-Modell angegeben ist, einschließlich des masterProfile Subnetzes erfolgt.