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

AKS-Cluster verwenden kubenet und erstellen für Sie standardmäßig ein virtuelles Azure-Netzwerk und -Subnetz. 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 (Network Address Translation, NAT) 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 durch 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 im Voraus geplant werden und in Ihrem Netzwerkadressraum eindeutig sein. 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 maxPods 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 können 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 oder 192.0.2.0/24 für den Adressbereich des Kubernetes-Diensts, den Adressbereich für den Pod oder den Adressbereich für das virtuelle Clusternetzwerk nicht verwenden. Dieser Bereich kann nicht aktualisiert werden, nachdem Sie Ihren Cluster erstellt haben.
• 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 festlegen. 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 definieren wollen, anstatt die integrierte Rolle „Netzwerkmitwirkender“ zu verwenden, benötigen Sie die folgenden Berechtigungen:
  • 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. Das kubenet-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 haben Sie virtuelle Netzwerke und Subnetze mit zugeordneten IP-Adressbereichen definiert und verwenden diese Ressourcen zur Unterstützung mehrerer Dienste und Anwendungen. 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 sorgen benutzerdefiniertes Routing (User Defined Routing, UDR) und IP-Weiterleitung für die Konnektivität zwischen Pods über Knoten hinweg. UDRs und die IP-Weiterleitungskonfiguration werden erstellt und standardmäßig vom AKS-Dienst verwaltet, Sie können jedoch Ihre eigene Routingtabelle für die benutzerdefinierte Routenverwaltung verwenden, wenn Sie dies möchten. 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:

Azure unterstützt maximal 400 Routen in einer UDR, also können Sie keinen AKS-Cluster mit mehr als 400 Knoten haben. Virtuelle Knoten in AKS und Azure-Netzwerkrichtlinien werden mit kubenet nicht unterstützt. Calico-Netzwerkrichtlinien werden unterstützt.

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 müssen Sie den IP-Adressbereich im Voraus planen, und alle IP-Adressen werden von den AKS-Knoten basierend auf der maximalen Anzahl von Pods konsumiert, 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.
  • Weitere Informationen finden Sie unter Anpassen des ausgehenden Clusters mit einer benutzerdefinierten Routingtabelle in AKS und Anpassen des ausgehenden Clusters mit ausgehenden Typen in AKS.
• 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
  • Windows-Knotenpools
  • Add-On für virtuelle Knoten

Hinweis

Einige der System-Pods, z. B. Konnektivität innerhalb des Clusters, verwenden die IP-Adresse des Hostknotens statt einer IP aus dem Überlagerungsadressraum. Die System-Pods verwenden nur die Knoten-IP und keine IP-Adresse aus dem virtuellen Netzwerk.

IP-Adressenverfügbarkeit und -auslastung

Ein häufiges Problem bei Azure CNI ist, dass der zugewiesene IP-Adressbereich zu klein ist, um dann mehr Knoten hinzuzufügen, wenn Sie einen Cluster skalieren oder upgraden. Möglicherweise ist das Netzwerkteam auch nicht in der Lage, einen ausreichend großen IP-Adressbereich zu vergeben, um die erwarteten Anforderungen Ihrer Anwendung zu erfüllen.

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 potentielle 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önnen beispielsweise mit einem /27-IP-Adressbereich in Ihrem Subnetz einen Cluster mit 20-25 Knoten mit genügend Platz zum Skalieren oder Upgraden ausführen. Diese Clustergröße unterstützt bis zu 2200-2750 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 250.

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 des virtuellen Azure-Netzwerks reserviert die ersten drei IP-Adressen für Verwaltungsvorgänge. Diese Knotenanzahl kann bis zu 27 610 Pods mit standardmäßig maximal 110 Pods pro Knoten unterstützen.
• Azure CNI: Derselbe grundlegende /24-Subnetzbereich kann nur maximal acht Knoten im Cluster unterstützen. Diese Knotenanzahl kann nur bis zu 240 Pods mit standardmäßig maximal 30 Pods pro Knoten unterstützen.

Hinweis

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

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. Wir empfehlen, Ihre AKS-Cluster in Subnetzen virtueller Azure-Netzwerke außerhalb dieses Adressbereichs zu erstellen, z. B. 172.16.0.0/16.

Auswählen eines zu verwendenden Netzwerkmodells

Die folgenden Überlegungen zeigen auf, wann die einzelnen Netzwerkmodelle am besten geeignet sind:

Verwenden Sie kubenet, wenn:

• Ihr IP-Adressraum ist beschränkt.
• Die Podkommunikation findet überwiegend innerhalb des Clusters statt.
• Sie benötigen keine erweiterten AKS-Features wie virtuelle Knoten oder Azure-Netzwerkrichtlinien.

Verwenden Sie Azure CNI, wenn:

• 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.
• Sie benötigen erweiterte AKS-Features wie virtuelle Knoten oder Azure-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

1. Erstellen Sie mit dem Befehl az group create eine Ressourcengruppe.

   az group create --name myResourceGroup --location eastus
   

2. Wenn Ihnen kein Subnetz eines virtuellen Netzwerks zur Verfügung steht, erstellen Sie diese Netzwerkressourcen mit dem Befehl az network vnet create. Der folgende Beispielbefehl erstellt ein virtuelles Netzwerk namens myAKSVnet mit dem Adresspräfix 192.168.0.0/16 und ein Subnetz namens myAKSSubnet mit dem Adresspräfix 192.168.1.0/24:

   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
   

3. Rufen Sie die Subnetzressourcen-ID mit dem az network vnet subnet show-Befehl ab, und speichern Sie diese als Variable mit dem Namen SUBNET_ID zur späteren Verwendung.

   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 eines AKS-Clusters mit systemseitig zugewiesenen verwalteten Identitäten

Hinweis

Beim Verwenden der systemseitig zugewiesenen Identität weist die Azure-Befehlszeilenschnittstelle der systemseitig zugewiesenen Identität nach dem Erstellen des Clusters die Rolle „Netzwerkmitwirkender“ zu. Wenn Sie eine ARM-Vorlage oder andere Clients verwenden, müssen Sie stattdessen die benutzerseitig zugewiesene verwaltete Identität verwenden.

• Erstellen Sie einen AKS-Cluster mit systemseitig zugewiesenen verwalteten Identitäten mittels dem az aks create-Befehl.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --network-plugin kubenet \
      --service-cidr 10.0.0.0/16 \
      --dns-service-ip 10.0.0.10 \
      --pod-cidr 10.244.0.0/16 \
      --vnet-subnet-id $SUBNET_ID    
  

  Bereitstellungsparameter:

  • --service-cidr ist optional. Mithilfe dieser Adresse werden interne Dienste im AKS-Cluster einer IP-Adresse zugewiesen. Dieser IP-Adressbereich sollte ein Adressraum sein, der ansonsten in Ihrer Netzwerkumgebung nicht verwendet wird. Dies schließt auch lokale Netzwerkbereiche ein, wenn Sie Ihre virtuellen Azure-Netzwerke mithilfe von ExpressRoute oder einer Site-to-Site-VPN-Verbindung verbinden (oder dies in Zukunft planen). Der Standardwert ist 10.0.0.0/16.
  • --dns-service-ip ist optional. Die Adresse muss die .10-Adresse Ihres Dienst-IP-Adressbereichs sein. Der Standardwert ist 10.0.0.10.
  • --pod-cidr ist optional. Diese Adresse muss ein großer Adressraum sein, der nicht an einer anderen Stelle in Ihrer Netzwerkumgebung verwendet wird. Dieser Bereich schließt alle lokalen Netzwerkbereiche ein, wenn Sie mit ExpressRoute oder Site-to-Site-VPN-Verbindungen eine Verbindung Ihrer virtuellen Azure-Netzwerke herstellen möchten oder dies planen. Der Standardwert ist 10.244.0.0/16.
    • Dieser Adressbereich muss groß genug sein für die Anzahl der Knoten, auf die Sie erwartungsgemäß hochskalieren werden. Sie können diesen Adressbereich nicht mehr ändern, nachdem der Cluster bereitgestellt wurde.
    • Mit dem Pod-IP-Adressbereich wird jedem Knoten im Cluster ein /24-Adressraum zugewiesen. Im folgenden Beispiel weist --pod-cidr von 10.244.0.0/16 dem ersten Knoten 10.244.0.0/24 zu, dem zweiten Knoten 10.244.1.0/24 und dem dritten Knoten 10.244.2.0/24.
    • Beim Skalieren oder Upgraden des Clusters weist die Azure-Plattform weiterhin jedem neuen Knoten einen Pod-IP-Adressbereich zu.

Erstellen eines AKS-Clusters mit benutzerseitig zugewiesener verwalteter Identität

Erstellen einer verwalteten Identität

• Erstellen Sie mithilfe des az identity-Befehls eine verwaltete Identität. Wenn Sie über eine vorhandene verwaltete Identität verfügen, suchen Sie stattdessen die Prinzipal-ID mit dem az identity show --ids <identity-resource-id>-Befehl.

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

  Ihre Ausgabe sollte in etwa wie die folgende Beispielausgabe 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"
  }
  

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

Wenn Sie die 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.

• Rufen Sie die Ressourcen-ID des virtuellen Netzwerks mit dem az network vnet show-Befehl ab, und speichern Sie diese als Variable mit dem Namen VNET_ID.

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

• Weisen Sie der verwaltete Identität für den AKS-Cluster Berechtigungen als Netzwerkmitwirkender für das virtuelle Netzwerk zu, indem Sie den az role assignment create-Befehl verwenden und die <prinzipalID> bereitstellen.

  az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"
  
  # Example command
  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

• Erstellen Sie mithilfe des az aks create-Befehls einen AKS-Cluster, und geben Sie für das Argument assign-identity die Ressourcen-ID der verwalteten Identität der Steuerungsebene an, um die benutzerseitig zugewiesene verwaltete Identität zuzuweisen.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --node-count 3 \
      --network-plugin kubenet \
      --vnet-subnet-id $SUBNET_ID \
      --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 für Sie und fügt 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

Sie können der benutzerdefinierten Routingtabelle benutzerdefinierte Regeln hinzufügen bzw. diese aktualisieren. Vom Kubernetes-Cloudanbieter werden jedoch Regeln hinzugefügt, die nicht aktualisiert oder entfernt werden dürfen. Regeln wie 0.0.0.0/0 müssen in jeder Routingtabelle enthalten und dem Ziel Ihres Internetgateways zugeordnet sein, beispielsweise einer NVA oder einem anderen ausgehenden Gateway. Seien Sie vorsichtig beim Aktualisieren von Regeln.

Weitere Informationen zur Einrichtung einer benutzerdefinierten Routingtabelle finden Sie hier.

Für die erfolgreiche Weiterleitung von Anforderungen erfordert ein kubenet-Netzwerk organisierte Routingtabellenregeln. Aufgrund dieses Konzepts müssen die Routingtabellen für jeden Cluster, der darauf angewiesen ist, sorgfältig gewartet werden. Eine Routingtabelle kann nicht von mehreren Clustern genutzt werden, da sich die Pod-CIDRs verschiedener Cluster möglicherweise überlappen, was zu unerwarteten und fehlerhaften Routingszenarien führen kann. Wenn Sie mehrere Cluster im gleichen virtuellen Netzwerk konfigurieren oder jedem Cluster ein eigenes virtuelles Netzwerk zuweisen, beachten Sie die folgenden 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 können jedoch auf der Routingtabelle geändert werden.
• Von jedem AKS-Cluster muss eine einzelne, eindeutige Routingtabelle für alle Subnetze verwendet werden, die dem Cluster zugeordnet sind. Sie können eine Routentabelle nicht mit mehreren Clustern wiederverwenden, da es zu Überschneidungen von Pod-CIDRs und widersprüchlichen Routingregeln kommen kann.
• Für eine systemseitig zugewiesene verwaltete Identität wird nur die Bereitstellung Ihres eigenen Subnetzes und Ihrer eigenen Routingtabelle über die Azure CLI unterstützt, da Azure CLI die Rollenzuweisung automatisch hinzufügt. Wenn Sie eine ARM-Vorlage oder andere Clients verwenden, müssen Sie eine benutzerseitig zugewiesene verwaltete Identität verwenden, Berechtigungen vor der Clustererstellung zuweisen und sicherstellen, 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.

Hinweis

Wenn Sie Ihr eigenes VNet und Ihre eigene Routingtabelle mit dem kubenet-Netzwerk-Plug-In erstellen und verwenden, müssen Sie eine benutzerseitig zugewiesene Identität auf Steuerungsebene verwenden. Bei der systemseitig zugewiesenen Identität auf Steuerungsebene können Sie die Identität vor dem Erstellen eines Clusters nicht abrufen, was zu einer Verzögerung während der Rollenzuweisung führt.

Sowohl systemseitig zugewiesene als auch benutzerseitig zugewiesene verwaltete Identitäten werden unterstützt, wenn Sie Ihr eigenes VNet und Ihre eigene Routingtabelle mit dem Azure-Netzwerk-Plug-In erstellen und verwenden. Es wird dringend empfohlen, eine benutzerseitig zugewiesene verwaltete Identität für BYO-Szenarien zu verwenden.

Hinzufügen einer Routingtabelle mit einer benutzerseitig zugewiesenen verwalteten Identität zu Ihrem AKS-Cluster

Nachdem Sie eine benutzerdefinierte Routingtabelle erstellt und sie einem Subnetz in Ihrem virtuellen Netzwerk zugeordnet haben, können Sie einen neuen AKS-Cluster erstellen, der Ihre Routingtabelle mit einer benutzerseitig zugewiesenen verwalteten Identität angibt. 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.

1. Rufen Sie die Subnetz-ID mit dem az network vnet subnet list-Befehl ab.

   az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]
   

2. Erstellen Sie einen AKS-Cluster mit einem benutzerdefinierten Subnetz, das mit einer Routingtabelle vorkonfiguriert ist, indem Sie den az aks create-Befehl verwenden und Ihre Werte für die Parameter --vnet-subnet-id, --enable-managed-identity und --assign-identity angeben.

   az aks create -g myResourceGroup -n myManagedCluster --vnet-subnet-id mySubnetIDResourceID --enable-managed-identity --assign-identity controlPlaneIdentityResourceID
   

Nächste Schritte

In diesem Artikel wurde gezeigt, wie Sie Ihren AKS-Cluster in Ihrem vorhandenen Subnetz des virtuellen Netzwerks bereitstellen. Jetzt können Sie mit dem Erstellen neuer Apps mit Helm oder der Bereitstellung vorhandener Apps mit Helm beginnen.