Automatische Verwaltung von Pod-Disruptions-Budgets in AKS (Vorschauversion)

Während AKS-Clusterupgrades leert der Upgradeprozess Knoten, indem Pods verdrängt werden, damit die Knoten neu installiert oder ersetzt werden können. Pod Disruption Budgets (PDBs) schützen die Anwendungsverfügbarkeit während dieses Prozesses, indem sie einschränken, wie viele Pods gleichzeitig nicht verfügbar sein können. Falsch konfigurierte PDBs können jedoch auch die Evakuierung vollständig blockieren, oder Deployments verfügen möglicherweise nicht über genügend Replikate, um das Budget zu erfüllen. Bereitstellungen ohne PDB haben das gegenteilige Problem: Nichts schützt ihre Pods davor, gleichzeitig entfernt zu werden, was zu Ausfallzeiten bei Upgrades führt.

Die automatische PDB-Verwaltung ist eine AKS-Erweiterung, die auf dem Open-Source-Projekt basiert, das die PDB-Verwaltung während Upgrades automatisiert. Sie hat folgende Aufgaben:

• Erstellt PDBs automatisch für Bereitstellungen, die nicht über eine verfügen, sodass Ihre Workloads während freiwilliger Unterbrechungen geschützt sind.
• Skaliert die Anzahl der Replikate vorübergehend hoch, wenn ein PDB die Auslagerung eines Pods auf einem gesperrten Knoten blockiert, sodass das Disruptions-Budget eingehalten wird und das Leeren des Knotens fortgesetzt werden kann.
• Skaliert Replikate wieder zurück nach Abschluss der Auslagerungen, damit Sie nicht für zusätzliche Kapazität zahlen müssen, die über die Anforderungen des Upgrades hinausgeht.

Das Ergebnis ist, dass Upgrades zuverlässig abgeschlossen werden, ohne dass Sie PDB-Schutzmechanismen zwangsweise umgehen oder unter Quarantäne gestellte Knoten manuell beheben müssen. Hintergrundinformationen dazu, wie AKS-Upgrades Knoten entleeren und wie sich PDBs auf diesen Prozess auswirken, finden Sie unter Wie AKS-Clusterupgrades funktionieren.

Wann die automatische PDB-Verwaltung verwendet werden sollte

Erwägen Sie die Aktivierung der automatischen PDB-Verwaltung in folgenden Fällen:

• Bereitstellungen verfügen nicht über PDBs. Pods werden ohne Verfügbarkeitsgarantien während Upgrades entfernt, was zu potenziellen Ausfallzeiten führt.
• PDBs verhindern das Leeren von Knoten. Ein PDB mit minAvailable, das der Replikatanzahl entspricht (oder maxUnavailable: 0), verhindert, dass ein Pod verdrängt wird, wodurch das Upgrade mit einer Fehlermeldung wie Cannot evict pod as it would violate the pod's disruption budget fehlschlägt.
• Replikate reichen für das Disruption-Budget nicht aus. Das PDB ist vorhanden und korrekt konfiguriert, aber die Bereitstellung verfügt nicht über genügend Replikate, um auch nur eine einzige Entfernung aufzufangen.
• Häufig treten Fehler bei der Upgradeentleerung auf und verlangen eine automatisierte, proaktive Lösung anstelle einer manuellen Bereinigung.

Identifizieren von PDB-bezogenen Entleerungsfehlern

Bevor Sie die automatische PDB-Verwaltung aktivieren, überprüfen Sie, ob in Ihrem Cluster PDB-bezogene Entwässerungsfehler auftreten:

• Azure Aktivitätsprotokoll. Öffnen Sie im Azure-Portal Ihre AKS-Clusterressource, und wählen Sie "Aktivitätsprotokoll" aus. Suchen Sie nach fehlgeschlagenen Upgradevorgängen mit Status Failed und Nachrichten, die auf Pod-Disruptions-Budgets oder Entleerungsfehler verweisen.

• Kubernetes-Ereignisse. Führen Sie den folgenden Befehl aus, um kürzlich aufgetretene Entfernungs- und Entleerungs-Ereignisse zu finden:

  kubectl get events --sort-by='.lastTimestamp' -A | grep -i "disruption\|evict\|drain"
  

  Eine vollständige Anleitung zum Arbeiten mit Kubernetes-Ereignissen finden Sie unter Kubernetes-Ereignisse.

Vergleich mit anderen Optionen

So funktioniert es

Die automatische PDB-Verwaltung umfasst zwei sich ergänzende Mechanismen: automatische PDB-Erstellung (proaktiv) und Skalierung von Replikaten während des Drains (reaktiv).

Automatische PDB-Erstellung

Wenn Sie die automatische Erstellung von PDB aktivieren (controllerConfig.pdb.create=true), überwacht die Erweiterung kontinuierlich Deployments, die kein PDB haben. Die Erweiterung ermittelt eine Übereinstimmung, indem sie den Label-Selektor des PDB mit den Labels der Pod-Vorlage des Deployments vergleicht. Dieser Vergleich stellt sicher, dass jede Bereitstellung nur einmal geschützt ist und doppelte PDBs vermeidet. Wenn es in einem aktivierten Namespace ein ungeschütztes Deployment findet, erstellt es ein PDB. Für Bereitstellungen ohne HPA oder KEDA wird minAvailable auf die aktuelle Replikatanzahl der Bereitstellung gesetzt. Bei Bereitstellungen mit HPA oder KEDA verfolgt minAvailable die minimale Replikatanzahl des Autoscalers, damit das Verhalten der PDB mit den Einschränkungen des Autoscalers übereinstimmt. Die Erweiterung gleicht fortlaufend automatisch erstellte PDBs ab. Wenn sich die Replikatanzahl der Bereitstellung ändert (z. B. durch ein manuelles Update oder einen externen Scaler), wird der Wert des minAvailable PDB entsprechend aktualisiert. Dieser Schutz stellt sicher, dass Pods während freiwilliger Unterbrechungen nicht gleichzeitig entfernt werden.

Automatisch erstellte PDBs werden während des gesamten Lebenszyklus von der Erweiterung verwaltet. Weitere Informationen zu Besitz, Bereinigung und dazu, wie Sie die manuelle Kontrolle übernehmen, finden Sie unter PDB-Besitz und Bereinigung.

Skalierung von Replikaten während der Entleerung

Die Erweiterung überwacht Ihren Cluster auf Situationen, in denen PDB-geschützte Pods während des Entleerungsvorgangs eines Knotens nicht entfernt werden können. Dies geschieht während eines typischen Upgrades:

1. AKS sperrt einen Knoten als Teil des Upgradeprozesses und markiert ihn als nicht planbar.
2. Die Erweiterung erkennt die Sperrmarkierung und überprüft, ob PDB-geschützte Pods auf diesem Knoten keine zulässigen Unterbrechungen haben.
3. Wenn die PDB eine Eviction verhindert, erhöht die Erweiterung vorübergehend die Anzahl der Replikate des Deployments um die Zahl der durch die PDB geschützten Pods auf abgesperrten Knoten (bis zum konfigurierten maxSurge Limit der Bereitstellung), sodass die zusätzliche Kapazität korrekt dimensioniert ist und keine Überprovisionierung erfolgt. Die zusätzlichen Replikate werden auf anderen verfügbaren Knoten geplant.
4. Die zulässigen Unterbrechungen der PDB steigen auf mehr als null, da die Gesamtzahl der fehlerfreien Pods jetzt den minAvailable PDB-Schwellenwert überschreitet.
5. Die Entleerung des Knotens erfolgt ordnungsgemäß. Die Eviction-API kann jetzt Pods von dem gesperrten Knoten entfernen, ohne dabei gegen die PDB zu verstoßen.
6. Sobald die Signale der Entfernung aufhören und die zulässigen Störungen über null steigen, skaliert die Erweiterung die Bereitstellung wieder auf die ursprüngliche Anzahl an Replikaten zurück. Die Herunterskalierung wird nicht fortgesetzt, wenn weitere Knoten noch gesperrt sind oder wenn der Entleerungsvorgang noch läuft. Diese Bedingung verhindert unnötige Fluktuation während Entleerungen mit mehreren Knoten. Die Skalierung erfolgt automatisch nach einem Cooldownzeitraum (Standard 60 Sekunden), ohne dass ein manueller Eingriff erforderlich ist.

Koordination mit Autoscalern (HPA und KEDA)

Bereitstellungen werden häufig von einem Autoscaler verwaltet. Um Racebedingungen zu vermeiden, bei denen der Autoscaler die Bereitstellung wieder verkleinert, bevor die Entfernungen abgeschlossen sind, passt die Erweiterung den Mindestwert des Autoscalers an (nicht nur die Anzahl der Replikate) und macht diese Änderung rückgängig, sobald die Entfernungen abgeschlossen sind.

So prüfen Sie die Sicht der Erweiterung auf eine Bereitstellung, einschließlich eines beliebigen Degraded-Status bei einer nicht unterstützten Autoscaler-Konfiguration:

kubectl get evictionautoscalers -A -o yaml

Voraussetzungen

Stellen Sie vor der Installation der automatischen PDB-Verwaltungserweiterung Folgendes sicher:

• Ein AKS-Cluster mit einer unterstützten Kubernetes-Version.
• Workloads, die Deployments verwenden. StatefulSets werden nicht unterstützt, und die Verwendung der automatischen PDB-Verwaltung mit StatefulSets wird nicht empfohlen.
• Azure CLI Version 2.64.0 oder höher. Führen Sie az --version zum Prüfen aus. Informationen zum Installieren oder Aktualisieren finden Sie unter Install Azure CLI.
• Der Microsoft.KubernetesConfiguration-Anbieter, der in Ihrem Abonnement registriert ist.
• Ihr AKS-Cluster muss eine verwaltete Identität (kein Dienstprinzipal) verwenden. Clustererweiterungen funktionieren nicht mit dienstprinzipalbasierten Clustern. Weitere Informationen finden Sie unter AKS-Clustererweiterungen.

Erweiterungsberechtigungen

Die Erweiterung für die automatische PDB-Verwaltung erfordert Berechtigungen zum Lesen und Schreiben von Deployments, Pod Disruption Budgets und Ereignissen in den von der Erweiterung verwalteten Namespaces. Die Erweiterung installiert während des Setups ein eigenes Dienstkonto und RBAC-Rollen. Die vollständige Liste der Rollen und Berechtigungen finden Sie im Projekt-Repository auf GitHub.

Registrieren des Konfigurationsanbieters

Wenn Sie Azure Kubernetes-Erweiterungen noch nicht verwendet haben, registrieren Sie den erforderlichen Anbieter:

az feature register --namespace Microsoft.KubernetesConfiguration --name Extensions

# Verify registration status
az feature show --namespace Microsoft.KubernetesConfiguration --name Extensions

# After the feature shows "Registered", refresh the provider
az provider register -n Microsoft.KubernetesConfiguration

Installieren der automatischen PDB-Verwaltung

Die automatische PDB-Verwaltung wird als Erweiterung auf Ihrem AKS-Cluster installiert. Wählen Sie eine Installationsoption basierend auf Ihren Anforderungen aus.

Grundlegende Installation

Installieren Sie die Erweiterung mit Standardeinstellungen. In diesem Modus überwacht die Erweiterung durch PDBs blockierte Entfernungen im Namespace kube-system, erstellt aber nicht automatisch PDBs für ungeschützte Bereitstellungen. Der Namespace kube-system ist standardmäßig enthalten, da auch von AKS verwaltete Systemkomponenten PDBs verwenden, die das Leeren von Knoten während Upgrades blockieren können:

az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --auto-upgrade-minor-version true

Installation mit automatischer PDB-Erstellung für bestimmte Namespaces

Aktivieren Sie die automatische PDB-Erstellung, und geben Sie an, welche Namespaces die Erweiterung schützen soll. Dies ist die empfohlene Konfiguration für die meisten Cluster:

az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --configuration-settings controllerConfig.pdb.create=true controllerConfig.namespaces.actionedNamespaces="{kube-system,production}" \
    --auto-upgrade-minor-version true

Installieren mit clusterweitem Schutz

Aktivieren der automatischen PDB-Erstellung für alle Namespaces:

az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --configuration-settings controllerConfig.pdb.create=true controllerConfig.namespaces.enabledByDefault=true \
    --auto-upgrade-minor-version true

Konfigurationsoptionen

Die folgenden Einstellungen steuern, wie sich die automatische PDB-Verwaltung verhält:

Allgemeine Konfigurationsmuster

Namespace-Steuerelement

Die Erweiterung wird je nach enabledByDefault Einstellung in einem von zwei Modi ausgeführt.

Zwei ergänzende Steuerelemente steuern, auf welchen Namespaces die Erweiterung wirkt:

• controllerConfig.namespaces.actionedNamespaces legt bei der Installation die Basisliste fest und ist die einfachste Möglichkeit, eine definierte Menge von Namespaces zu aktivieren.
• Mit der eviction-autoscaler.azure.com/enable Namespaceanmerkung (oder disable) können Clusteroperatoren Namespaces zur Laufzeit aktivieren oder abmelden, ohne die Erweiterung erneut zu installieren.

Opt-In-Modus (Standard)

Wenn enabledByDefaultfalse ist, sind nur die in actionedNamespaces aufgeführten Namespaces aktiviert. Sie können zusätzliche Namespaces einzeln aktivieren, indem Sie eine Anmerkung hinzufügen:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  annotations:
    eviction-autoscaler.azure.com/enable: "true"

Abmeldemodus

Wenn enabledByDefaulttrue ist, sind alle Namespaces aktiviert. Sie können bestimmte Namespaces ausschließen, indem Sie eine Anmerkung hinzufügen:

apiVersion: v1
kind: Namespace
metadata:
  name: my-excluded-namespace
  annotations:
    eviction-autoscaler.azure.com/enable: "false"

Ausschließen bestimmter Bereitstellungen

Um zu verhindern, dass die Erweiterung einen PDB für eine bestimmte Bereitstellung erstellt, fügen Sie der Bereitstellung die folgende Anmerkung hinzu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  annotations:
    eviction-autoscaler.azure.com/pdb-create: "false"

Automatische PDB-Erstellung

Wenn controllerConfig.pdb.create auf true festgelegt ist, erstellt die Erweiterung PDBs für Bereitstellungen, die alle folgenden Kriterien erfüllen:

• Die Bereitstellung verfügt noch nicht über ein passendes PDB.
• Die Bereitstellung befindet sich in einem aktiven Namespace.
• Die Bereitstellung ist nicht durch die Annotation eviction-autoscaler.azure.com/pdb-create: "false" ausgeschlossen.

Automatisch erstellte PDBs werden minAvailable basierend auf der Skalierungsquelle der Workload festgelegt. Bei Bereitstellungen ohne HPA oder KEDA entspricht minAvailable der aktuellen Replikatanzahl der Bereitstellung (ohne die von der Erweiterung hinzugefügten Anstiegsreplikate). Bei Bereitstellungen mit HPA oder KEDA entspricht minAvailable der Mindestanzahl von Replikaten des Autoscalers. Das bedeutet, dass die Entfernung so lange blockiert ist, bis die Erweiterung die Bereitstellung skaliert; ab diesem Zeitpunkt erfüllen die zusätzlichen Replikate die Budgetvorgaben und ermöglichen das Entleeren.

PDB-Besitz und Bereinigung

Von der Erweiterung erstellte PDBs werden mit einer ownedBy: EvictionAutoScaler Anmerkung gekennzeichnet. Diese controllereigenen PDBs werden automatisch gelöscht, wenn:

• Die übergeordnete Bereitstellung wird gelöscht.
• Der Namespace wird aus dem Bereich der Erweiterung entfernt.
• Die Erweiterung wird aus dem Cluster entfernt. PDBs mit der ownedBy: EvictionAutoScaler Anmerkung werden über Kubernetes Garbage Collection bereinigt.

PdBs, die Sie manuell erstellen, werden nie von der Erweiterung geändert oder gelöscht.

Um die manuelle Kontrolle über einen pdB zu übernehmen, der von der Erweiterung erstellt wurde, entfernen Sie die Besitzeranmerkung. Nachdem Sie diese Anmerkung entfernt haben, verwaltet die Erweiterung diese PDB nicht mehr, und Sie sind für das Aktualisieren oder Löschen verantwortlich:

kubectl annotate pdb <pdb-name> -n <namespace> ownedBy-

Überprüfen der Installation

Überprüfen Sie nach der Installation der Erweiterung, ob die automatische PDB-Verwaltung ordnungsgemäß funktioniert.

1. Überprüfen Sie, ob PDBs für Bereitstellungen in aktivierten Namespaces erstellt wurden. Filtern Sie nach PDBs, die von der Erweiterung erstellt wurden:

   kubectl get pdb -A -o custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace,MIN-AVAILABLE:.spec.minAvailable,OWNER:.metadata.annotations.ownedBy | grep EvictionAutoScaler
   

2. Überprüfen Sie die benutzerdefinierten Ressourcen für die automatische PDB-Verwaltung:

   kubectl get evictionautoscalers --all-namespaces
   

3. Testen mit einer Knotensperrung (optional). Richten Sie in einer Test- oder Staging-Umgebung einen Knoten ein und überprüfen Sie, ob die Erweiterung die Bereitstellung skaliert und die zulässigen Unterbrechungen der PDB über null steigen:

   # Cordon a node
   NODE=$(kubectl get pods -n <namespace> -l app=<app-label> -o=jsonpath='{.items[0].spec.nodeName}')
   kubectl cordon $NODE
   
   # Watch for automatic PDB management events
   kubectl get events -n <namespace> --sort-by='.lastTimestamp'
   
   # Check that the deployment scaled up
   kubectl get pods -n <namespace>
   
   # Verify PDB allowed disruptions
   kubectl get poddisruptionbudget <pdb-name> -n <namespace> -o yaml
   
   # After verification, uncordon the node
   kubectl uncordon $NODE
   

Aktualisieren oder Entfernen der Erweiterung

Konfiguration aktualisieren

Um Konfigurationseinstellungen zu ändern, löschen Sie die Erweiterung, und erstellen Sie sie mit den neuen Einstellungen neu:

# Delete the existing extension
az k8s-extension delete \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --name eviction-autoscaler \
    --yes

# Recreate with new configuration
az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --configuration-settings controllerConfig.pdb.create=true controllerConfig.namespaces.enabledByDefault=true \
    --auto-upgrade-minor-version true

Erweiterung entfernen

So deinstallieren Sie die automatische PDB-Verwaltung:

az k8s-extension delete \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --name eviction-autoscaler \
    --yes

Einschränkungen und Überlegungen

• Konfigurationsupdates erfordern das Löschen und erneute Erstellen der Erweiterung.
• Die automatische PDB-Verwaltung funktioniert nur mit Deployments. StatefulSets werden nicht unterstützt, und die Verwendung dieser Erweiterung mit StatefulSets wird nicht empfohlen.
• Die automatische PDB-Verwaltung überschreibt oder ändert keine vorhandenen PDBs. Es funktioniert zusammen mit ihnen, indem die Replikatanzahl angepasst wird.
• Die automatische PDB-Verwaltung koordiniert sich mit einem einzelnen Autoscaler pro Bereitstellung (HPA oder KEDA). Eine Bereitstellung, die von KEDA und einer separaten HPA verwaltet wird, wird nicht unterstützt; die Erweiterung kennzeichnet sich selbst als Degraded und überspringt den Anstieg. Siehe Koordination mit Autoscalern (HPA und KEDA).
• Die automatische PDB-Verwaltung ist unabhängig von den Upgradeeinstellungen für den Knotenpool. Einstellungen wie max-surge, das Zeitlimit für das Entleeren von Knoten, die Verweildauer von Knoten und die Upgrade-Strategie (rollierend oder Blue-Green) müssen nicht geändert werden, damit diese Erweiterung funktioniert, und die Erweiterung hat keinen Einfluss auf das Verhalten dieser Einstellungen.
• Die temporäre Replikatskalierung erfordert verfügbare Kapazität im Cluster. Wenn keine Knoten Platz für die zusätzlichen Pods haben, sollten Sie die Aktivierung des Cluster-Autoscalers oder des Knoten-Auto-Provisioning (NAP) in Betracht ziehen, damit neue Knoten bereitgestellt werden können.

Problembehandlung

Symptome, Ursachen und Lösungen finden Sie im AKS-Hub zur Problembehandlung: Problembehandlung für Azure Kubernetes Service.

Führen Sie Folgendes aus, um die Erweiterungsaktivität direkt auf dem Cluster zu prüfen:

kubectl get evictionautoscalers -A -o yaml
kubectl get events -A --sort-by='.lastTimestamp'

Verwandte Inhalte

• Optionen und Empfehlungen für Upgrades — einschließlich Szenario 2: Fehler beim Leeren von Knoten und PDBs, mit mehreren Lösungsoptionen.
• Funktionsweise von AKS-Clusterupgrades – erläutert den schrittweisen Rollupgradeprozess und was geschieht, wenn eine PDB-Knotenentleerung blockiert.
• Bewährte Methoden für Pod Disruption Budgets – Anleitungen zum Konfigurieren von PDBs für hohe Verfügbarkeit.
• Kubernetes-Dokumentation: Pod Disruption Budgets – Referenz zur Upstream-PDB.
• Automatisches PDB-Managementprojekt zu GitHub – Quellcode und detaillierte technische Referenz.