Best Practices für grundlegende Schedulerfunktionen in Azure Kubernetes Service (AKS)

Beim Verwalten von Clustern in Azure Kubernetes Service (AKS) müssen Sie oft Teams oder Workloads isolieren. Mit dem Kubernetes-Scheduler können Sie die Verteilung von Computeressourcen steuern und die Auswirkungen von Wartungsereignissen einschränken.

Dieser Artikel zu Best Practices konzentriert sich auf grundlegende Kubernetes-Planungsfunktionen für Clusteroperatoren. In diesem Artikel werden folgende Vorgehensweisen behandelt:

Durchsetzen von Ressourcenkontingenten

Best Practices-Leitfaden

Planen Sie Ressourcenkontingente auf Namespaceebene, und wenden Sie sie an. Verwenden Sie Kontingente und beschränken Sie Bereiche, um Standardressourcenanforderungen und -grenzwerte für Pods anzufordern oder bereitzustellen. Überwachen Sie die Ressourcennutzung, und passen Sie Kontingente nach Bedarf an.

Legen Sie Ressourcenanforderungen und Ressourcenbeschränkungen in der Podspezifikation fest. Eine Ressourcenanforderung ist die Menge der CPU oder des Arbeitsspeichers, die der Kubernetes-Scheduler zum Platzieren eines Pods verwendet. Ein Ressourcengrenzwert schränkt den Anteil dieser Ressource ein, den ein Container verwenden kann. Das System erzwingt CPU-Grenzwerte durch Drosselung, während speicherreaktive Speichergrenzwerte durch Beenden außerhalb des Arbeitsspeichers (Out-of-Memory, OOM) erzwungen werden. Weitere Informationen finden Sie unter Define pod resource requests and limits.

Verwenden Sie Ressourcenkontingente , um den Aggregatressourcenverbrauch für ein Entwicklungsteam oder Projekt zu begrenzen. Definieren Von Kontingenten auf Namespaceebene für:

• Computeressourcen, z.B. CPU und Arbeitsspeicher oder GPUs.
• Speicherressourcen, einschließlich der Gesamtanzahl der Volumes oder des Speicherplatzes für eine angegebene Speicherklasse.
• Objektanzahl, z. B. die maximale Anzahl geheimer Schlüssel, Dienste oder Aufträge, die erstellt werden können.

Der Kubernetes-Scheduler verwendet Ressourcenanforderungen zum Platzieren von Pods. Container können mehr CPU oder Arbeitsspeicher als angefordert verwenden, wenn Kapazität verfügbar ist, und Ressourcengrenzwerte können Anforderungen überschreiten. Ein Ressourcenkontingent schränkt den aggregierten Namespaceverbrauch separat ein. Wenn das Erstellen oder Aktualisieren einer Ressource ein hartes Kontingent überschreitet, lehnt der API-Server die Anforderung mit einer HTTP-Antwort 403 Forbidden ab. Sie können weiterhin ein Workloadobjekt wie eine Bereitstellung erstellen, auch wenn das Kontingent verhindert, dass der Controller alle angeforderten Pods erstellt.

Wenn ein Ressourcenkontingent CPU oder Arbeitsspeicher verfolgt, muss jeder neue Pod eine Anforderung oder einen Grenzwert für diese Ressource angeben. Andernfalls kann der API-Server den Pod ablehnen. Sie können Standardanforderungen und Grenzwerte für einen Namespace mithilfe eines LimitRange-Steuerelements konfigurieren .

Das folgende Beispiel eines YAML-Manifests mit dem Namen dev-app-team-quotas.yaml legt einen festen Grenzwert von insgesamt 10 CPUs, 20Gi Arbeitsspeicher und 10 Pods fest:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-app-team
spec:
  hard:
    cpu: "10"
    memory: 20Gi
    pods: "10"

Dieses Kontingent begrenzt CPU-Anforderungen bei 10 CPUs, aggregierte Speicheranforderungen bei 20Gi und die Anzahl der nichtterminalen Pods bei 10 im Namespace.

Wenden Sie dieses Ressourcenkontingent auf einen Namespace an, z. B. Dev-Apps:

kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps

Arbeiten Sie mit Ihren Anwendungsentwicklern und -besitzern zusammen, um deren Anforderungen zu verstehen und die entsprechenden Ressourcenkontingente anzuwenden.

Weitere Informationen zu verfügbaren Ressourcenobjekten, Bereichen und Prioritäten finden Sie unter Ressourcenkontingente in Kubernetes.

Einschränken der Auswirkungen auf Unterbrechungen mithilfe von Pod-Unterbrechungsbudgets (PDBs)

Best Practices-Leitfaden

Definieren Sie Pod Disruption Budgets (PDBs) für replizierte Anwendungen, um gleichzeitige freiwillige Evictions während Ereignissen wie AKS-Knotenabflüssen einzuschränken. Warten Sie genügend fehlerfreie Replikate, und lassen Sie mindestens eine Unterbrechung zu, wenn die Workload zulässt, damit die Clusterwartung fortgesetzt werden kann.

Störende Ereignisse, die Pods entfernen, fallen in zwei Kategorien:

Unfreiwillige Unterbrechungen

Unfreiwillige Unterbrechungen sind Ereignisse, die außerhalb der typischen Kontrolle des Clusteroperators oder Anwendungsbesitzers liegen. Dazu gehören:

• Hardwarefehler auf dem physischen Computer
• Kernelstörung
• Löschen einer Knoten-VM

Sie können unfreiwillige Störungen vermeiden, indem Sie:

• Verwenden mehrerer Replikate Ihrer Pods in einer Bereitstellung
• Betreiben mehrerer Knoten im AKS-Cluster

Freiwillige Unterbrechungen

_ Freiwillige disruptions_ sind Ereignisse, die der Clusteroperator oder Anwendungsbesitzer anfordert. Dazu gehören:

• Entwässern eines Knotens während eines Clusterupgrades
• Aktualisieren einer Bereitstellungsvorlage
• Direktes Löschen eines Pods

Nicht alle freiwilligen Unterbrechungen werden durch PDBs eingeschränkt. Durch das direkte Löschen eines Pod- oder Workload-Objekts werden PDBs umgangen, und Workloadcontroller wie Bereitstellungen und StatefulSets sind während der rollierenden Updates nicht durch PDBs beschränkt. Konfigurieren Sie die Rolloutstrategie der Workload separat, um die Verfügbarkeit während Anwendungsupdates aufrechtzuerhalten. Weitere Informationen finden Sie unter "Unterbrechungen" in Kubernetes.

PDBs beschränken gleichzeitige freiwillige Evictions für ausgewählte Pods über die Kubernetes Eviction-API. Während eines rollierenden AKS-Upgrades fügt AKS die Kapazität entsprechend den Knotenpooleinstellungen, Kabeln und Entwässern eines Knotens hinzu und ersetzt dann die Images oder ersetzt den entwässerten Knoten. Die Eviction-API wertet den PDB während des Abflusses aus. Nach einer Entfernung erstellt der Workloadcontroller einen Ersatz-Pod, und der Planer platziert ihn auf einem Knoten mit verfügbarer Kapazität. Ein restriktives PDB, unzureichende fehlerfreie Replikate oder unzureichende Clusterkapazität können den Abfluss verzögern oder blockieren.

Festlegen einer Mindestanzahl verfügbarer Pods

Betrachten Sie ein ReplicaSet mit fünf NGINX-Pods mit Bezeichnung app: nginx-frontend. Während eines freiwilligen Unterbrechungsereignisses, z. B. eines Clusterupgrades, müssen mindestens drei Pods verfügbar bleiben. Das folgende PodDisruptionBudget Manifest definiert diese Anforderung:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 3
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Dieses Budget erfordert mindestens drei Pods mit dem Etikett app: nginx-frontend , um während einer freiwilligen Vertreibung gesund zu bleiben.

Sie können einen Prozentsatz angeben, z. B. 60%, sodass das Budget angepasst wird, wenn das ReplicaSet skaliert wird.

Festlegen einer maximalen Anzahl nicht verfügbarer Pods

Ein PDB kann entweder minAvailable oder maxUnavailable, aber nicht beide definieren. Wenn Sie freiwillige Zwänge basierend auf nicht verfügbaren Pods einschränken möchten, geben Sie maxUnavailable diese als ganze Zahl oder prozentual an. Das folgende Manifest erlaubt eine freiwillige Ausweisung nur, wenn nach der Ausweisung nicht mehr als zwei Pods im ReplicaSet nicht mehr verfügbar wären:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  maxUnavailable: 2
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Dieses Budget erlaubt eine freiwillige Vertreibung nur, wenn nicht mehr als zwei Pods mit dem Etikett app: nginx-frontend nach der Vertreibung nicht mehr verfügbar wären. Unfreiwillige Störungen können dennoch dazu führen, dass die Verfügbarkeit unter diesen Schwellenwert fällt.

Mit der AlwaysAllow Richtlinie für die unsunde Pod-Entfernung können Sie pods, die nicht fehlerfrei sind, entwässern. Ohne diese Einstellung kann die Standardrichtlinie IfHealthyBudget einen Abfluss blockieren, während auf fehlerhafte Pods gewartet wird, um fehlerfrei zu werden. Verwenden Sie AlwaysAllow , wenn die Entwässerung wichtiger ist, als eine ungesunde Pod mehr Zeit zur Wiederherstellung zu geben.

Speichern Sie das PDB-Manifest, das Sie als nginx-pdb.yaml verwenden möchten, und wenden Sie es dann auf Ihren AKS-Cluster an:

kubectl apply -f nginx-pdb.yaml

Überprüfen Sie vor der Clusterwartung, ob jede PDB die erwartete Entfernung zulässt:

kubectl get poddisruptionbudgets --namespace <namespace>

Ein ALLOWED DISRUPTIONS Wert, der 0 einen AKS-Knotenabfluss blockieren kann. Arbeiten Sie mit Ihren Anwendungsentwicklern und -besitzern zusammen, um genügend fehlerfreie Replikate zu verwalten und ein Budget auszuwählen, das die Anwendungsverfügbarkeit mit Wartungsanforderungen ausgleicht.

Weitere Informationen zur Verwendung von Budgets für die Unterbrechung von Pods finden Sie unter Spezifizieren von Budgets für die Unterbrechung für Ihre Anwendung.

Verwandte Inhalte

Dieser Artikel konzentriert sich auf grundlegende Kubernetes-Schedulerfeatures. Weitere Informationen zu Clustervorgängen in AKS finden Sie in den folgenden Artikeln zu bewährten Methoden:

• Best Practices für Clusterisolierung in Azure Kubernetes Service (AKS)
• Erweiterte Scheduler-Funktionen in Kubernetes
• Authentifizierung und Autorisierung