Verwenden von kubenet-Netzwerken mit Ihren eigenen IP-Adressbereichen in Azure Kubernetes Service (AKS)

Artikel
08/06/2022
12 Minuten Lesedauer

Standardmäßig verwenden AKS-Cluster kubenet. Ein virtuelles Azure-Netzwerk sowie ein Subnetz werden für Sie erstellt. Mit kubenet erhalten Knoten eine IP-Adresse aus dem Subnetz des virtuellen Azure-Netzwerks. Pods erhalten eine IP-Adresse von einem logisch unterschiedlichen Adressraum zum Subnetz des virtuellen Azure-Netzwerks der Knoten. Die Netzwerkadressübersetzung (NAT, Network Address Translation) wird dann so konfiguriert, dass die Pods Ressourcen im virtuellen Azure-Netzwerk erreichen können. Die Quell-IP-Adresse des Datenverkehrs wird mit NAT in die primäre IP-Adresse des Knotens übersetzt. Dieser Ansatz reduziert die Anzahl der IP-Adressen, die Sie in Ihrem Netzwerkadressraum für die Verwendung von Pods reservieren müssen, erheblich.

Mit Azure Container Networking Interface (CNI) erhält jeder Pod eine IP-Adresse aus dem Subnetz, mit der direkt darauf zugegriffen werden kann. Diese IP-Adressen müssen in Ihrem Netzwerkadressraum eindeutig sein und im Voraus geplant werden. Jeder Knoten verfügt über einen Konfigurationsparameter für die maximale Anzahl von Pods, die er unterstützt. Die entsprechende Anzahl von IP-Adressen pro Knoten wird dann im Voraus für diesen Knoten reserviert. Dieser Ansatz erfordert mehr Planung und führt oft zu einer Erschöpfung der IP-Adresse oder der Notwendigkeit, Cluster in einem größeren Subnetz neu zu erstellen, wenn die Anforderungen Ihrer Anwendung wachsen. Sie können die maximale Anzahl von Pods, die auf einem Knoten bereitgestellt werden können, zum Zeitpunkt der Clustererstellung oder beim Erstellen neuer Knotenpools konfigurieren. Wenn Sie die maximale Anzahl von Pods beim Erstellen neuer Knotenpools nicht angeben, wird der Standardwert 110 für Kubenet verwendet.

Dieser Artikel veranschaulicht die Verwendung von kubenet-Netzwerken zum Erstellen und Verwenden eines virtuellen Netzwerksubnetzes für einen AKS-Cluster. Weitere Informationen zu Netzwerkoptionen und -überlegungen finden Sie unter Netzwerkkonzepte für Kubernetes und AKS.

Voraussetzungen

Das virtuelle Netzwerk des AKS-Clusters muss ausgehende Internetkonnektivität zulassen.
In einem Subnetz sollte nicht mehr als ein AKS-Cluster erstellt werden.
AKS-Cluster dürfen für den Adressbereich des Kubernetes-Diensts, den Adressbereich für den Pod oder den Adressbereich für das virtuelle Clusternetzwerk nicht 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 oder 192.0.2.0/24 verwenden.
Die vom AKS-Cluster verwendete Clusteridentität muss mindestens die Rolle Netzwerkmitwirkender für das Subnetz in Ihrem virtuellen Netzwerk haben. Die CLI unterstützt Sie bei der automatischen Rollenzuweisung. Wenn Sie eine ARM-Vorlage oder andere Clients verwenden, müssen Sie die Rollenzuweisung manuell ausführen. Sie müssen auch die entsprechenden Berechtigungen haben (z. B. „Abonnementbesitzer“), um eine Clusteridentität erstellen und ihr Berechtigungen zuweisen zu können. Wenn Sie eine benutzerdefinierte Rolle anstelle der integrierten Rolle des Netzwerkmitwirkenden definieren möchten, sind die folgenden Berechtigungen erforderlich:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read

Warnung

Um Windows Server-Knotenpools verwenden zu können, müssen Sie Azure CNI verwenden. Die Verwendung von „kubenet“ als das Netzwerkmodell ist für Windows Server-Container nicht verfügbar.

Voraussetzungen

Azure CLI-Version 2.0.65 oder höher muss installiert und konfiguriert sein. Führen Sie az --version aus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

Übersicht über kubenet-Netzwerke mit eigenem Subnetz

In vielen Umgebungen gibt es definierte virtuelle Netzwerke und Subnetze mit zugeordneten IP-Adressbereichen. Diese Ressourcen des virtuellen Netzwerks werden verwendet, um mehrere Dienste und Anwendungen zu unterstützen. Um Netzwerkkonnektivität zu gewährleisten, können AKS-Cluster kubenet (grundlegender Netzwerkbetrieb) oder Azure CNI (erweiterter Netzwerkbetrieb) verwenden.

Mit kubenet erhalten nur die Knoten eine IP-Adresse im Subnetz des virtuellen Netzwerks. Pods können nicht direkt miteinander kommunizieren. Stattdessen werden benutzerdefiniertes Routing (User Defined Routing, UDR) und IP-Weiterleitung für die Konnektivität zwischen Pods über Knoten verwendet. Standardmäßig werden UDRs und die IP-Weiterleitungskonfiguration vom AKS-Dienst erstellt und verwaltet, Sie haben jedoch die Möglichkeit, eine eigene Routingtabelle für benutzerdefinierte Routenverwaltung zu verwenden. Sie können auch Pods hinter einem Dienst bereitstellen, der eine zugewiesene IP-Adresse empfängt und einen Lastenausgleich des Datenverkehrs für die Anwendung durchführt. Das folgende Diagramm zeigt, wie die AKS-Knoten eine IP-Adresse im Subnetz des virtuellen Netzwerks empfangen, aber nicht die Pods:

Kubenet-Netzwerkmodell mit einem AKS-Cluster

Azure unterstützt maximal 400 Routen in einer UDR, also können Sie keinen AKS-Cluster mit mehr als 400 Knoten haben. AKS-Features wie z. B. virtuelle Knoten und Azure-Netzwerkrichtlinien werden mit kubenet nicht unterstützt. Sie können Calico-Netzwerkrichtlinien verwenden, da diese mit kubenet unterstützt werden.

Mit Azure CNI empfängt jeder Pod eine IP-Adresse im IP-Subnetz und kann direkt mit anderen Pods und Diensten kommunizieren. Ihre Cluster können so groß wie der IP-Adressbereich sein, den Sie angeben. Allerdings muss der IP-Adressbereich im Voraus geplant werden, und alle IP-Adressen werden von den AKS-Knoten basierend auf der maximalen Anzahl von Pods genutzt, die sie unterstützen können. Erweiterte Netzwerkfeatures und -szenarien wie z. B. virtuelle Knoten oder Netzwerkrichtlinien (entweder Azure oder Calico) werden mit Azure CNI unterstützt.

Einschränkungen und Erwägungen für kubenet

Beim Entwurf von kubenet ist ein zusätzlicher Hop erforderlich, wodurch der Pod-Kommunikation eine geringfügige Wartezeit hinzugefügt wird.
Routingtabellen und benutzerdefinierte Routen sind für die Verwendung von kubenet erforderlich, wodurch die Vorgänge komplexer werden.
Direkte Pod-Adressierung wird aufgrund des kubenet-Designs für kubenet nicht unterstützt.
Im Gegensatz zu Azure CNI-Clustern können mehrere kubenet-Clustern Subnetze nicht gemeinsam verwenden.
AKS wendet keine Netzwerksicherheitsgruppen (NSGs) auf sein Subnetz an und ändert keine der NSGs, die diesem Subnetz zugeordnet sind. Wenn Sie Ihr eigenes Subnetz bereitstellen und NSGs hinzufügen, die diesem Subnetz zugeordnet sind, müssen Sie sicherstellen, dass die Sicherheitsregeln in den NSGs Datenverkehr zwischen den CIDR-Knoten und -Pods zulassen. Weitere Details finden Sie unter Netzwerksicherheitsgruppen.
Zu den in kubenet nicht unterstützten Funktionen gehören:
- Azure-Netzwerkrichtlinien, aber Calico-Netzwerkrichtlinien werden in kubenet unterstützt.
- Windows-Knotenpools
- Add-On für virtuelle Knoten

IP-Adressenverfügbarkeit und -auslastung

Ein häufiges Problem bei Azure CNI ist, dass der zugewiesene IP-Adressbereich zu klein ist, um weitere Knoten hinzuzufügen, wenn Sie einen Cluster skalieren oder upgraden. Das Netzwerkteam kann vielleicht auch keinen IP-Adressbereich zur Verfügung zu stellen, der groß genug ist, Ihre erwarteten Anwendungsanforderungen zu unterstützen.

Als Kompromiss können Sie einen AKS-Cluster erstellen, der kubenet verwendet und eine Verbindung mit einem vorhandenen Subnetz eines virtuellen Netzwerks herstellt. Mit diesem Ansatz können die Knoten definierte IP-Adressen empfangen, ohne dass vorab eine große Anzahl von IP-Adressen für alle möglichen Pods reserviert werden muss, die im Cluster ausgeführt werden könnten.

Mit kubenet können Sie einen viel kleineren IP-Adressbereich verwenden und große Cluster und Anwendungsanforderungen unterstützen. Sie könnten beispielsweise noch mit einem /27-IP-Adressbereich in Ihrem Subnetz einen Cluster mit 20-25 Knoten mit genügend Platz zum Skalieren oder Aktualisieren ausführen. Diese Clustergröße unterstützt bis zu 2.200-2.750 Pods (mit standardmäßig maximal 110 Pods pro Knoten). Die maximale Anzahl von Pods pro Knoten, die Sie mit Kubenet in AKS konfigurieren können, ist 110.

Die folgenden grundlegenden Berechnungen zeigen den Unterschied zwischen Netzwerkmodellen im Vergleich:

kubenet – ein einfacher /24-IP-Adressbereich kann bis zu 251 Knoten im Cluster unterstützen (jedes Subnetz eines virtuellen Azure-Netzwerks reserviert die ersten drei IP-Adressen für Verwaltungsvorgänge).
- Diese Knotenanzahl könnte bis zu 27.610 Pods unterstützen (mit standardmäßig maximal 110 Pods pro Knoten mit kubenet).
Azure CNI – derselbe grundlegende /24-Subnetzadressbereich könnte nur maximal 8 Knoten im Cluster unterstützen.
- Diese Knotenanzahl könnte nur bis zu 240 Pods unterstützen (mit standardmäßig maximal 30 Pods pro Knoten mit Azure CNI).

Hinweis

Bei diesen Maximalwerten werden keine Upgrade- oder Skalierungsvorgänge berücksichtigt. In der Praxis können Sie die maximale Anzahl von Knoten, die der Subnetz-IP-Adressbereich unterstützt, nicht ausführen. Sie müssen dafür sorgen, dass einige IP-Adressen zur Verwendung während der Skalierungs- oder Upgradevorgänge verfügbar sind.

Peering virtueller Netzwerke und ExpressRoute-Verbindungen

Um lokale Konnektivität zu bieten, kann sowohl der kubenet- als auch der Azure CNI-Netzwerkansatz Peering in virtuellen Netzwerken oder ExpressRoute-Verbindungen verwenden. Planen Sie Ihre IP-Adressbereiche sorgfältig, um Überschneidungen und falsches Datenverkehrsrouting zu verhindern. In vielen lokalen Netzwerken wird z.B. ein 10.0.0.0/8-Adressbereich verwendet, der über die ExpressRoute-Verbindung angekündigt wird. Sie sollten Ihre AKS-Cluster in Subnetzen virtueller Azure-Netzwerke außerhalb dieses Adressbereichs erstellen, z. B. 172.16.0.0/16.

Auswählen eines zu verwendenden Netzwerkmodells

Die Wahl des für Ihren AKS-Cluster zu verwendenden Netzwerk-Plug-Ins ist in der Regel ein Kompromiss zwischen Flexibilität und erweiterten Konfigurationsanforderungen. Die folgenden Überlegungen helfen bei der Entscheidung, welches Netzwerkmodell sich wohl am besten eignet.

Verwenden Sie kubenet unter folgenden Bedingungen:

Ihr IP-Adressraum ist beschränkt.
Die Podkommunikation findet überwiegend innerhalb des Clusters statt.
Erweiterte AKS-Features wie virtuelle Knoten oder Azure-Netzwerkrichtlinien sind nicht erforderlich. Verwenden Sie Calico-Netzwerkrichtlinien.

Verwenden Sie Azure CNI unter folgenden Bedingungen:

Sie haben genügend verfügbaren IP-Adressraum.
Podkommunikation findet überwiegend mit außerhalb des Clusters befindlichen Ressourcen statt.
Sie möchten keine benutzerdefinierten Routen für Podverbindungen verwalten.
Erweiterte AKS-Features wie virtuelle Knoten oder Azure-Netzwerkrichtlinien sind erforderlich. Verwenden Sie Calico-Netzwerkrichtlinien.

Weitere Informationen zur Entscheidung, welches Netzwerkmodell Sie verwenden, finden Sie unter Vergleich der Netzwerkmodelle und ihres Supportumfang.

Erstellen eines virtuellen Netzwerks und des Subnetzes

Erstellen Sie für den Einstieg in die Verwendung von kubenet und Ihrem eigenen Subnetz des virtuellen Netzwerks zunächst mit dem Befehl az group create eine Ressourcengruppe. Im folgenden Beispiel wird eine Ressourcengruppe mit dem Namen myResourceGroup am Standort eastus erstellt:

az group create --name myResourceGroup --location eastus

Wenn Ihnen kein Subnetz eines virtuellen Netzwerks zur Verfügung steht, erstellen Sie diese Netzwerkressourcen mit dem Befehl az network vnet create. Im folgenden Beispiel erhält das virtuelle Netzwerk den Namen myAKSVnet mit dem Adresspräfix 192.168.0.0/16. Ein Subnetz mit dem Namen myAKSSubnet mit dem Adresspräfix 192.168.1.0/24 wird erstellt.

az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24

Rufen Sie die Subnetz-Ressourcen-ID ab und speichern Sie sie als Variable:

SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

Erstellen eines AKS-Clusters im virtuellen Netzwerk

Erstellen Sie nun mithilfe des Befehls az aks create einen AKS-Cluster in Ihrem virtuellen Netzwerk und Subnetz.

Erstellen eines AKS-Clusters mit systemseitig zugewiesenen verwalteten Identitäten

Sie können einen AKS-Cluster mithilfe einer systemseitig zugewiesenen verwalteten Identität erstellen, indem Sie den folgenden CLI-Befehl ausführen.

Hinweis

Wenn Sie die systemseitig zugewiesene Identität verwenden, weist azure-cli die systemseitig zugewiesene Identität nach dem Erstellen des Clusters die Rolle „Netzwerkmitwirkender“ zu. Wenn Sie eine ARM-Vorlage oder andere Clients verwenden, müssen Sie die benutzerseitig zugewiesene verwaltete Identität verwenden.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID

Hinweis

Wenn Sie einen AKS-Cluster zum Einschließen einer Calico-Netzwerkrichtlinie ermächtigen möchten, können Sie den folgenden Befehl verwenden.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet --network-policy calico \
    --vnet-subnet-id $SUBNET_ID

Erstellen eines AKS-Clusters mit benutzerseitig zugewiesenen verwalteten Identitäten

Erstellen oder Abrufen einer verwalteten Identität

Sollten Sie über keine verwaltete Identität verfügen, könnten Sie mithilfe des Befehls az identity eine erstellen.

az identity create --name myIdentity --resource-group myResourceGroup

Die Ausgabe sollte wie folgt aussehen:

{                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Wenn Sie über eine vorhandene verwaltete Identität verfügen, können Sie die Prinzipal-ID finden, indem Sie den folgenden Befehl ausführen:

az identity show --ids <identity-resource-id>

Die Ausgabe sollte wie folgt aussehen:

{
  "clientId": "<client-id>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",
  "location": "eastus",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Hinzufügen der Rollenzuweisung für eine verwaltete Identität

Wenn Sie Azure CLI verwenden, wird die Rolle automatisch hinzugefügt und Sie können diesen Schritt überspringen. Wenn Sie eine ARM-Vorlage oder andere Clients verwenden, müssen Sie die Prinzipal-ID der vom Cluster verwalteten Identität verwenden, um eine Rollenzuweisung durchzuführen.

Um in den weiteren Schritten die richtigen Delegierungen zuzuweisen, verwenden Sie die Befehle az network vnet show und az network vnet subnet show, um die erforderlichen Ressourcen-IDs abzurufen. Diese Ressourcen-IDs werden als Variablen gespeichert, und auf sie wird in den verbleibenden Schritten verwiesen:

VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)

Weisen Sie nun die verwaltete Identität für den AKS-Cluster mithilfe des Befehls az role assignment create Berechtigungen vom Typ Netzwerkmitwirkender für das virtuelle Netzwerk zu. Geben Sie die <principalId> wie in der Ausgabe des vorherigen Befehls an, um die Identität zu erstellen:

az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

Beispiel:

az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

Hinweis

Bis die Berechtigung wirksam wird, die der von Azure verwendeten verwalteten Identität Ihres Clusters gewährt wird, können bis zu 60 Minuten vergehen.

Erstellen eines AKS-Clusters

Jetzt können Sie einen AKS-Cluster mithilfe der benutzerseitig zugewiesenen verwalteten Identität erstellen, indem Sie den folgenden CLI-Befehl ausführen. Bereitstellen der Identitäts-Ressourcen-ID der Steuerungsebene über assign-identity

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID \
    --enable-managed-identity \
    --assign-identity <identity-resource-id>

Wenn Sie einen AKS-Cluster erstellen, werden eine Netzwerksicherheitsgruppe und Routingtabelle automatisch erstellt. Diese Netzwerkressourcen werden von der AKS-Steuerungsebene verwaltet. Die Netzwerksicherheitsgruppe wird automatisch den virtuellen NICs auf Ihren Knoten zugeordnet. Die Routingtabelle wird automatisch dem Subnetz des virtuellen Netzwerks zugeordnet. Regeln für Netzwerksicherheitsgruppen und Routingtabellen werden beim Erstellen und Verfügbarmachen von Diensten automatisch aktualisiert.

Einbinden Ihres eigenen Subnetzes und Ihrer eigenen Routingtabelle mit kubenet

Mit kubenet muss eine Routingtabelle in Ihren Clustersubnetzen vorhanden sein. AKS unterstützt das Einbinden Ihres eigenen vorhandenen Subnetzes und Ihrer Routingtabelle.

Falls Ihr benutzerdefiniertes Subnetz keine Routingtabelle enthält, erstellt AKS automatisch eine Routingtabelle und fügt ihr während des gesamten Clusterlebenszyklus Regeln hinzu. Wenn Ihr benutzerdefiniertes Subnetz bei der Clustererstellung bereits eine Routingtabelle enthält, wird diese bei Clustervorgänge von AKS berücksichtigt, und es werden entsprechende Regeln für Cloudanbietervorgänge hinzugefügt/aktualisiert.

Warnung

Benutzerdefinierte Regeln können der benutzerdefinierten Routingtabelle hinzugefügt und aktualisiert werden. Vom Kubernetes-Cloudanbieter hinzugefügte Regeln dürfen dagegen nicht aktualisiert oder entfernt werden. Regeln wie „0.0.0.0/0“ müssen in jeder Routingtabelle enthalten und dem Ziel Ihres Internetgateways (beispielsweise einer virtuellen Netzwerkappliance oder einem anderen Ausgangsgateway) zugeordnet sein. Achten Sie beim Aktualisieren von Regeln unbedingt darauf, dass nur Ihre benutzerdefinierten Regeln geändert werden.

Weitere Informationen zur Einrichtung einer benutzerdefinierten Routingtabelle finden Sie hier.

Für die erfolgreiche Weiterleitung von Anforderungen in einem Kubenet-Netzwerk sind organisierte Routingtabellenregeln erforderlich. Routingtabellen müssen daher für jeden Cluster, der auf sie angewiesen ist, sorgfältig verwaltet werden. Eine Routingtabelle kann nicht von mehreren Clustern genutzt werden, da sich die Pod-CIDRs verschiedener Cluster möglicherweise überschneiden, was zu unerwartetem und fehlerhaftem Routing führen kann. Wenn Sie mehrere Cluster im gleichen virtuellen Netzwerk konfigurieren oder jedem Cluster ein eigenes virtuelles Netzwerk zuweisen, berücksichtigen Sie die folgenden Einschränkungen.

Einschränkungen:

Vor dem Erstellen des AKS-Clusters muss dem Subnetz eine benutzerdefinierte Routingtabelle zugeordnet werden.
Die zugeordnete Routingtabellenressource kann nach der Clustererstellung nicht mehr aktualisiert werden. Benutzerdefinierte Regeln in der Routingtabelle können jedoch geändert werden.
Von jedem AKS-Cluster muss eine einzelne, eindeutige Routingtabelle für alle Subnetze verwendet werden, die dem Cluster zugeordnet sind. Eine Routingtabelle kann nicht von mehreren Clustern genutzt werden, da dies zu Überschneidungen bei Pod-CIDRs sowie zu Konflikten bei Routingregeln führen kann.
Mit einer systemseitig zugewiesenen verwalteten Identität wird nur die Bereitstellung Ihres eigenen Subnetzes und Ihrer eigenen Routingtabelle über Azure CLI unterstützt. Grund dafür ist, dass CLI die Rollenzuweisung automatisch hinzufügen wird. Wenn Sie eine ARM-Vorlage oder andere Clients verwenden, müssen Sie eine benutzerseitig zugewiesene verwaltete Identität verwenden und weisen Sie vor dem Erstellen des Clusters die Berechtigungen zu. Stellen Sie sicher, dass die benutzerseitig zugewiesene Identität über Schreibberechtigungen für Ihr benutzerdefiniertes Subnetz und die benutzerdefinierte Routingtabelle verfügt.
Die Verwendung einer Routingtabelle für mehrere AKS-Cluster wird nicht unterstützt.

Nachdem Sie eine benutzerdefinierte Routingtabelle erstellt und dem Subnetz in Ihrem virtuellen Netzwerk zugeordnet haben, können Sie einen neuen AKS-Cluster erstellen, von dem Ihre Routingtabelle genutzt wird. Sie müssen die Subnetz-ID für den Ort verwenden, an dem Sie Ihren AKS-Cluster bereitstellen möchten. Dieses Subnetz muss ebenfalls Ihrer benutzerdefinierten Routingtabelle zugeordnet werden.

# Find your subnet ID
az network vnet subnet list --resource-group
                            --vnet-name
                            [--subscription]

# Create a kubernetes cluster with with a custom subnet preconfigured with a route table
az aks create -g MyResourceGroup -n MyManagedCluster --vnet-subnet-id <MySubnetID-resource-id>

Nächste Schritte

Da jetzt ein AKS-Cluster in Ihrem vorhandenen Subnetz des virtuellen Netzwerks bereitgestellt ist, können Sie den Cluster jetzt wie gewohnt verwenden. Beginnen Sie mit der Erstellung neuer Apps mithilfe von Helm, oderstellen Sie vorhandene Apps mithilfe von Helm bereit.