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

Artikel
10/30/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 in Azure Stack Hub mit AKS-Engine verwendet das kubenet-Netzwerk-Plug-In. Die AKS-Engine in 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. Klicken Sie auf OK.
Wählen Sie auf der Seite Virtuelle Netzwerke die Option Eigenschaften aus. Kopieren Sie den unter Ressourcen-ID angegebenen Wert, und fügen Sie 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

Die AKS-Engine unterstützt die Bereitstellung in einem vorhandenen virtuellen Netzwerk. Bei der Bereitstellung in einem vorhandenen virtuellen Netzwerk verwendet Ihr Cluster Blöcke mit aufeinander folgenden Adressen für Agentknoten, Knoten auf Steuerungsebene, 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 Adressraums des virtuellen Netzwerks sein. Die Auswahl von Adressblöcken außerhalb des Adressraums des virtuellen Netzwerks kann zu Konnektivitätsproblemen 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. Die AKS-Engine erfordert einen Bereich von bis zu 16 nicht verwendeten IP-Adressen, wenn Sie mehrere Knoten auf Steuerungsebene verwenden. Der Cluster verwendet eine IP-Adresse für jede Steuerungsebene (bis zu fünf Knoten der Steuerungsebene). Die AKS-Engine erfordert auch die nächsten 10 IP-Adressen nach dem letzten Knoten der Steuerungsebene für die Ip-Adressreservierung im Hauptraum. Schließlich wird vom Lastenausgleich nach den Knoten der Steuerungsebene und der Kopfraumreservierung eine weitere IP-Adresse 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 in keinem 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. Weisen Sie die firstConsecutiveStaticIP Eigenschaft nach Möglichkeit 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“	Number	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-Bereich	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 firstConsecutiveStaticIP10.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-Bereich	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 & 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 von der AKS-Engine 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 `firstConsecutiveStaticIP` 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-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",

    ...
  },

Beispiel bei Verwendung des Azure CNI:
Mit einem Netzwerkadressraum von 172.24.0.0/16, in dem das Subnetz für control-plane-sn172.24.0.0/24 ist und k8s-sn172.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

Nach dem Hinzufügen der Werte zu Ihrem API-Modell können Sie Ihren Cluster von Ihrem Clientcomputer aus bereitstellen, indem Sie den Befehl in der deploy AKS-Engine verwenden. 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 im API-Modell angegebene Subnetz erfolgt, einschließlich des masterProfile Subnetzes.