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

Artikel
11/23/2024

Sie können einen Kubernetes-Cluster mithilfe der AKS-Engine (Azure Kubernetes Service) in einem benutzerdefinierten virtuellen Netzwerk bereitstellen. In diesem Artikel erfahren Sie, wie Sie die benötigten Informationen in Ihrem virtuellen Netzwerk finden. Hier werden Schritte zum Berechnen der von Ihrem Cluster verwendeten IP-Adressen, zum Festlegen der Werte im API-Modell sowie zum Festlegen der Routingtabelle und der Netzwerksicherheitsgruppe beschrieben.

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).

Einschränkungen 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-Clustersubnetz muss einen IP-Adressbereich verwenden, der im Adressraum des IP-Adressbereichs des benutzerdefinierten VNETs liegt. Weitere Informationen finden Sie unter Ermitteln des IP-Adressblocks.
Beachten Sie, dass die empfohlene Größe für die 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. Beispiele für kubenet und das Azure CNI finden Sie weiter unten.
Der Adressraum 169.254.0.0/16 kann nicht für benutzerdefinierte virtuelle Netzwerke 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 benötigen die Ressourcen-ID und den IP-Adressbereich des Subnetzes. Die Ressourcen-ID und der Bereich werden bei der Clusterbereitstellung in Ihrem API-Modell verwendet.

Ö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. Dieser Wert wird später für den Schlüssel vnetSubnetId im API-Modell für Ihren Cluster verwendet. Die Ressourcen-ID für das Subnetz hat folgendes 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 nicht einer 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 bestehende virtuelle Netzwerke verwenden und ein Peering virtueller Netzwerke nutzen möchten, ziehen Sie die Verwendung verschiedener Adressräume für die einzelnen Netzwerke in Erwägung. Überlappende Adressräume können dazu führen, dass Sie möglicherweise kein Peering aktivieren können.

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: Dies ist der Adressblock, der zum Zuweisen von Adressen für die Clusterknoten verwendet wird. Hierbei kann es sich um einen einzelnen Adressblock für alle Clusterknoten oder getrennte Blöcke (Subnetze) für Pools auf Steuerungsebene und Agent-Pools handeln. Berücksichtigen Sie bei der Auswahl des Adressbereichs für diesen Block die Anzahl der Knoten in Ihrem Cluster. Beim Azure CNI erhalten Knoten und Container Adressen aus demselben Adressblock. Berücksichtigen Sie daher, wenn Sie das Azure CNI verwenden, bei der Auswahl des Adressbereichs die Anzahl von Containern, die Sie in Ihrem Cluster bereitstellen möchten.
Dienstadressblock: Dies ist der Adressblock, aus dem die Clusteradresse von Diensten stammt, die im Kubernetes-Cluster bereitgestellt werden. 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.
Clusteradressblock: Dies ist der Adressblock mit den Clusteradressen für Pods. 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.

Neben den Adressblöcken müssen Sie für Knoten der Steuerungsebene noch zwei weitere Werte festlegen. Dazu müssen Sie wissen, wie viele IP-Adressen Sie für Ihren Cluster reservieren müssen, und Ihnen muss die erste der fortlaufenden statischen IP-Adressen im IP-Adressraum des Subnetzes bekannt sein. 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 Knoten der Steuerungsebene). Das AKS-Modul erfordert auch die nächste 10 IP-Adresse nach dem letzten Steuerebenenknoten für die Ip-Adressreservierung der Kopfraum. Schließlich wird eine weitere IP-Adresse vom Lastenausgleichsmodul nach den Steuerebenenknoten und der Kopfraumreservierung für insgesamt 16 verwendet. 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.

Für einen Cluster mit drei Knoten der Steuerungsebene gilt beispielsweise Folgendes: Bei Verwendung eines Subnetzes mit 256 Adressen (beispielsweise 10.100.0.0/24) muss die erste der fortlaufenden statischen IP-Adressen auf einen Wert kleiner 239 festgelegt werden. 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 müsste die Eigenschaft firstConsecutiveStaticIP auf 172.100.0.224 festgelegt werden.

Bei größeren Subnetzen (beispielsweise „/16“ mit mehr als 60.000 Adressen) ist es ggf. nicht ohne Weiteres möglich, Ihre statischen IP-Zuweisungen auf den hinteren Bereich 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 wäre der Wert für die Eigenschaft firstConsecutiveStaticIP 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 firstConsecutiveStaticIP 172.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 oben erwähnten Adressblock der Knoten der Steuerungsebene 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 oben erwähnten Agent-Knoten-Adressblock 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 oben erwähnten 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. Weiteren Knoten wird kein Podnetzwerk zugewiesen, da der IP-Adressraum erschöpft ist, und daher stehen sie im Cluster nicht zur Verfügung.
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 ist dem oben erwähnten 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-sn 10.100.0.0/24 ist und agents-sn 10.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",

    ...
  },

Beispiel bei Verwendung des Azure CNI:
Mit einem Netzwerkadressraum von 172.24.0.0/16, in dem das Subnetz für control-plane-sn 172.24.0.0/24 ist und k8s-sn 172.24.128.0/17 ist

"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 ihrem API-Modell die Werte hinzugefügt haben, können Sie Ihren Cluster über den deploy Befehl im AKS-Modul 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 in Ihrem 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.