Upgrade von Basic Load Balancer auf Azure Kubernetes Service (AKS)

In diesem Artikel erfahren Sie, wie Sie Ihre Basic Load Balancer-Instanzen auf Standard Load Balancer auf Azure Kubernetes Services (AKS) aktualisieren. Wir empfehlen die Verwendung eines Standard-Load-Balancers für alle Produktionsinstanzen. Es bietet viele wichtige Unterschiede in Ihrer Infrastruktur. Anleitungen zum Upgrade von Basic Load Balancer auf Standard Load Balancer außerhalb von AKS finden Sie in den offiziellen Anleitungen für das Upgrade von Basic Load Balancer.

Von Bedeutung

Ab dem 30. September 2025 unterstützt Azure Kubernetes Service (AKS) den Basic Load Balancer nicht mehr. Um potenzielle Dienstunterbrechungen zu vermeiden, empfehlen wir die Verwendung des Standardlastenausgleichs für neue Bereitstellungen und das Aktualisieren vorhandener Bereitstellungen auf den Standardlastenausgleich. Weitere Informationen zu dieser Außerbetriebnahme finden Sie im GitHub-Issue "Retirement" und in der Ankündigung zur Außerbetriebnahme von Azure Updates. Um über Ankündigungen und Updates auf dem Laufenden zu bleiben, folgen Sie den AKS-Versionshinweisen.

Note

Bei Clustern, die sowohl Verfügbarkeitsgruppen als auch den Basic-Load-Balancer verwenden, gibt es einen separaten az aks update Befehl, den Sie ausführen müssen, um beide Migrationen gleichzeitig durchzuführen (von Verfügbarkeitsgruppen zu Knotenpools für virtuelle Maschinen und vom Basic-Load-Balancer zum Standard-Load-Balancer). Schritte zum Ausführen dieser Migration finden Sie in den Anleitungen zur Migration von Verfügbarkeitssätzen .

Bevor Sie anfangen

Bevor Sie mit der Migration beginnen, überprüfen Sie die folgenden Informationen:

  • Ausfallzeiten treten während der Migration auf. Planen Sie entsprechend für Ausfallzeiten.
  • Nach Beginn der Migration ist ein Rollback nicht zulässig.
  • Bei diesem Vorgang wird auch Ihre Standard-IP zu einer Standard-IP migriert, während die eingehenden IP-Adressen, die dem Lastenausgleichsmodul zugeordnet sind, beibehalten werden. Neue öffentliche IPs werden erstellt und den ausgehenden Standardregeln für den Lastenausgleich zugeordnet, um Clusterausgangsdatenverkehr zu bedienen.

Voraussetzungen

Ihr Cluster muss die folgenden Voraussetzungen erfüllen, bevor Sie die Migration ausführen können:

  • Die mindeste Kubernetes-Version für dieses Skript ist 1.27. Wenn Sie ihr AKS-Cluster aktualisieren müssen, lesen Sie das Upgrade eines AKS-Clusters.
  • Die Azure-Befehlszeilenschnittstelle muss installiert sein. Die erforderliche Mindestversion ist 2.76.0.
  • Wenn der Cluster den Schlüsselverwaltungsdienst mit privatem Schlüsseltresor ausführt, müssen Sie den Schlüsselverwaltungsdienst deaktivieren, bevor Sie die Migration durchführen. Weitere Informationen finden Sie unter "Deaktivieren von KMS".
  • Sie müssen alle ValidatingAdmissionWebhooks oder MutatingAdmissionWebhooks deaktivieren, bevor Sie die Migration ausführen.

Upgrade Basic Load Balancer auf Standard Load Balancer

  1. Aktualisieren Sie Ihren Basic Load Balancer auf einen Standard Load Balancer, indem Sie den az aks update Befehl verwenden und das Kennzeichen mit der --load-balancer-sku Option auf Standard setzen.

    az aks update \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku=Standard

  2. Überprüfen Sie, ob die Migration erfolgreich war, indem Sie den az aks show Befehl verwenden.

    az aks show \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP

    Bestätigen Sie in der Ausgabe, dass der load-balancer-Typ auf Standard gesetzt ist.

  3. Stellen Sie sicher, dass alle Pods und Dienste erfolgreich mithilfe der kubectl get pods und kubectl get svc Befehle laufen.

    kubectl get svc -A
kubectl get pods -A

Bestätigen neuer ausgehender IP-Adressen

Sie können die neuen IP-Adressen bestätigen, die mit ausgehenden Regeln verknüpft sind, indem Sie die Ressourcen-IDs für die IP-Adressen bestätigen und dann die IP-Adressen auflisten.

  1. Rufen Sie die Ressourcen-ID für die ausgehenden IP-Adressen mithilfe des az aks show Befehls ab.

    az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id

  2. Rufen Sie die neue IP-Adresse für jede Ressourcen-ID mithilfe des az network public-ip show Befehls ab.

    az network public-ip show --ids $IP_RESOURCE_ID --query ipAddress -o tsv

Häufig gestellte Fragen

Warum erhalte ich Error: “Load Balancer SKU 'basic' is invalid; must use 'standard'., wenn ich einen neuen AKS-Cluster erstelle oder ein Upgrade durchführe?

Microsoft hat die SKU des Basic Load Balancer für bestimmte AKS-Vorgänge eingestellt, und die Erstellung ist jetzt in einigen Regionen blockiert.

Um dieses Problem zu beheben, stellen Sie sicher, dass Sie beim Erstellen eines neuen Clusters angeben --load-balancer-sku standard . Beispiel:

az aks create \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku standard

Warum kann ich meinen Basic Load Balancer nicht durch einen „Load Balancer Standard“ ersetzen?

Die SKU des Lastenausgleichs ist nach der Erstellung in AKS unveränderlich, da es sich um eine verwaltete Ressource handelt, die sich im Besitz des Clusters befindet.

Sie können dies mithilfe einer der folgenden Optionen beheben:

Warum kann ich meine öffentliche IP nach dem Upgrade von Basic auf Standard Load Balancer nicht finden?

Das Load Balancer-Objekt hat den Verweis auf Ihre öffentliche IP-Ressource während der Migration verloren. Dies kann auftreten, wenn die IP an den Basic SKU Load Balancer gebunden und nicht zurückgebunden wurde.

So beheben Sie dieses Problem:

  1. Stellen Sie sicher, dass die neue öffentliche Standard-IP in der richtigen Ressourcengruppe vorhanden ist.

  2. Ordnen Sie es im Dienstmanifest mithilfe der folgenden Konfiguration neu zu:

    annotations:
  service.beta.kubernetes.io/azure-load-balancer-ipv4: <your-ip>

Wenn Sie das Lastenausgleichsmodul auf einem privaten Cluster ohne öffentliche IP migrieren, warum wird während der Migration noch eine öffentliche IP erstellt?

Wenn outboundTypeLoadBalancer ist, stellt AKS automatisch eine öffentliche IP (PIP) bereit, unabhängig von der SKU des Load Balancers.

So beheben Sie dieses Problem:

  1. outboundType zu userDefinedRouting ändern, um einen vollständig privaten Cluster zu gewährleisten.
  2. Stellen Sie sicher, dass benutzerdefiniertes ausgehendes Routing über die Azure Firewall/NVA konfiguriert ist.

Warum schlägt die Migration in meinem internen Lastenausgleichssetup fehl?

Die aktuellen Migrationstools unterstützen keine internen VNet-Lastenausgleichsgeräte bei der Umstellung von Basic auf Standard im laufenden Betrieb.

So beheben Sie dieses Problem:

  1. Erstellen Sie den Cluster im selben VNet mit standard Load Balancer neu.
  2. Stellen Sie Workloads bereit und überprüfen Sie die interne Namensauflösung.

Meine Knotenpools verwenden Verfügbarkeitssets. Werde ich nach der Migration des Lastenausgleichs trotzdem noch Probleme haben?

Ja. Wenn Ihre Knotenpools Verfügbarkeitssätze verwenden, sind sie auch nach dem 30. September 2025 in AKS veraltet.

So beheben Sie dieses Problem:

  1. Bei Clustern, die sowohl Verfügbarkeitsgruppen als auch den Basischen Lastenausgleich verwenden, gibt es einen separaten az aks update Befehl, den Sie ausführen müssen, um beide Migrationen gleichzeitig durchzuführen (Verfügbarkeitsgruppen auf Knotenpools für virtuelle Maschinen und Basischer Lastenausgleich auf Standardlastenausgleich). Schritte zum Ausführen dieser Migration finden Sie in den Anleitungen zur Migration von Verfügbarkeitssätzen .
  2. Nach dem Upgrade müssen Azure CLI- oder REST-APIs verwendet werden, um CRUD-Vorgänge auszuführen oder den Pool zu verwalten. Überprüfen Sie die Einschränkungen.

Muss ich Standardwebhooks vor dem Upgrade löschen?

Nein. Wenn im Cluster weder ValidatingAdmissionWebhooks noch MutatingAdmissionWebhooks vorhanden sind, sollten die Standardwebhooks in der Steuerungsebene während der Migration problemlos beibehalten werden können.

Zu den Standardmäßigen Webhooks gehören:

  • aks-node-mutating-webhook
  • webhook-admission-controller
  • node-validating-webhook

Welcher Zugriff ist erforderlich, um die Migrationsbefehle auszuführen?

Zum Ausführen der Migrationsbefehle benötigen Sie Folgendes:

  • Entweder die Rolle „Mitwirkender“ oder „Besitzer“ im Abonnement oder in der Ressourcengruppe.
  • Die Azure CLI-Version muss ≥ 2.72.0 sein.
  • Die AKS Preview-Erweiterungsversion muss ≥ 0.5.170 sein.

Wie kann ich feststellen, ob die KMS-Verschlüsselung (Key Management Service) deaktiviert ist?

Mithilfe des az aks list Befehls können Sie überprüfen, ob die KMS-Verschlüsselung auf Ihrem AKS-Cluster aktiviert ist.

az aks list --query "[].{Name:name, KmsEnabled:securityProfile.azureKeyVaultKms.enabled, KeyId:securityProfile.azureKeyVaultKms.keyId}"

  • Wenn die Ausgabe angezeigt wird "KmsEnabled": null, bedeutet dies, dass die KMS-Verschlüsselung für diesen Cluster nicht aktiviert ist, und Sie können alle Schritte überspringen, um sie zu deaktivieren. Beispiel:

      {

    "KeyId": null,

    "KmsEnabled": null,

    "Name": "myAKSCluster"

  },
...

  • Wenn KMS aktiviert ist und Sie es deaktivieren möchten, lesen Sie "Deaktivieren der KMS-Verschlüsselung".

Nächste Schritte

Weitere Informationen zu AKS-Netzwerken finden Sie unter Netzwerkkonzepte für Azure Kubernetes Service (AKS).For more information on AKS networking, see Networking concepts for Azure Kubernetes Service (AKS).

  • Last updated on