Einführung
Der Scheduler benötigt Ressourcenanforderungen, um Pods zu platzieren, der Kubelet setzt Limits durch, und der HorizontalPodAutoscaler benötigt Metriken sowie eine aussagekräftige Auslastungsgrundlage. Diese Mechanismen bilden gemeinsam einen Ablauf zur Kapazitätsverwaltung.
Sie konfigurieren Anforderungen und Limits, untersuchen die aktuelle Auslastung, erstellen einen HPA, erzeugen Last und beobachten die Änderung der Replikazahl.
Diese Einstellungen bilden eine Abhängigkeitenkette. Die CPU-Anforderung legt die Grundlage fest, metrics-server meldet die aktuelle Auslastung, und der HPA vergleicht beide Werte, um zu entscheiden, ob sich die Replikazahl ändern soll. Ohne die Anforderung wäre eine prozentuale CPU-Auslastung nicht aussagekräftig.
Anforderungen und Limits festlegen
In diesem Schritt stellen Sie das Kubernetes-HPA-Beispiel mit expliziten Ressourcen bereit.
Eine Anforderung gibt an, welche Ressourcenkapazität für die Planung und als Bezugsgröße für die automatische Skalierung reserviert wird. Ein Limit bezeichnet die maximale Ressourcennutzung, die für den Container durchgesetzt wird. CPU-Ressourcen werden in Kernen oder Millicores angegeben (100m entspricht 0,1 Kern); für den Speicher werden Byte-Einheiten wie Mi verwendet.
cd /home/labex/project/resource-autoscaling
kubectl create namespace practice-capacity
kubectl create deployment cpu-demo -n practice-capacity --image=registry.k8s.io/hpa-example:latest --replicas=1
Fügen Sie der erzeugten Deployment-Ressourcendefinition die Ressourcenvereinbarung hinzu. kubectl set resources aktualisiert die Pod-Vorlage und löst dadurch ein neues Rollout aus:
kubectl set resources deployment/cpu-demo -n practice-capacity --requests=cpu=100m,memory=32Mi --limits=cpu=200m,memory=64Mi
kubectl expose deployment cpu-demo -n practice-capacity --port=80 --target-port=80
kubectl rollout status deployment/cpu-demo -n practice-capacity --timeout=60s
kubectl get deployment cpu-demo -n practice-capacity -o jsonpath='{.spec.template.spec.containers[0].resources}{"\n"}'
100m entspricht einem Zehntel eines CPU-Kerns. Anforderungen beeinflussen die Planung und die Auslastungsberechnung; Limits begrenzen den Ressourcenverbrauch des Containers.
Die JSONPath-Ausgabe sollte sowohl requests als auch limits enthalten. Ein allein festgelegtes Limit würde dem HPA keine Bezugsgröße für die Auslastung liefern.
deployment "cpu-demo" successfully rolled out
{"limits":{"cpu":"200m","memory":"64Mi"},"requests":{"cpu":"100m","memory":"32Mi"}}
JSON kann die Schlüssel in einer anderen Reihenfolge ausgeben. Prüfen Sie die vier Werte und nicht ihre Position in der Zeile.
Ressourcenmetriken untersuchen
In diesem Schritt überprüfen Sie die vorbereitete Metrikpipeline und untersuchen die aktuelle Auslastung.
kubectl top zeigt eine Momentaufnahme der aktuellen Ressourcennutzung, ähnlich wie der Betriebssystembefehl top. Konfigurierte Anforderungen oder Limits werden dabei nicht angezeigt; diese bleiben Bestandteil der Workload-Spezifikation.
cd /home/labex/project/resource-autoscaling
kubectl get deployment metrics-server -n kube-system
for attempt in $(seq 1 18); do
if kubectl top nodes >/dev/null 2>&1 && kubectl top pods -n practice-capacity --containers >/dev/null 2>&1; then
break
fi
echo "Waiting for the first metrics sample (${attempt}/18)..."
sleep 5
done
kubectl top nodes
kubectl top pods -n practice-capacity --containers
kubectl top liest aktuelle Metriken und nicht die Ressourcenanforderungen. Es kann etwas dauern, bis Metriken verfügbar sind. Wenn für einen neuen Pod noch keine Messung vorliegt, versuchen Sie es nach einigen Sekunden erneut.
Die Schleife übernimmt diese Wiederholung für Sie. Sie prüft höchstens 18-mal im Hintergrund, wartet zwischen den Versuchen jeweils fünf Sekunden und führt anschließend die beiden sichtbaren top-Befehle aus, sobald eine Messung verfügbar ist. Bei den Prüfungen verwirft >/dev/null die normale Ausgabe, während 2>&1 die Fehlerausgabe an dieselbe Stelle umleitet. Dadurch bleiben erwartete Meldungen wie „Metriken noch nicht bereit“ vom Terminal fern. Diese Verzögerung ist bei einer Pipeline für aktuelle Nutzungsdaten normal und bedeutet nicht, dass der Pod fehlgeschlagen ist.
Die Werte für Node und Pod können variieren. Achten Sie daher auf das Vorhandensein der CPU- und Speicherspalten und nicht auf exakte Zahlen. --containers schlüsselt die Nutzung auf, wenn ein Pod mehrere Container enthält.
Beispielsweise erzeugte die getestete Umgebung eine Node-Tabelle und eine Tabelle für einzelne Container wie diese:
NAME CPU(cores) CPU(%) MEMORY(bytes) MEMORY(%)
labex-v135 182m 9% 1602Mi 44%
POD NAME CPU(cores) MEMORY(bytes)
cpu-demo-... hpa-example 1m 9Mi
Ihre Werte werden erwartungsgemäß abweichen, da es sich um Messwerte und nicht um Konfigurationswerte handelt.
Einen HorizontalPodAutoscaler erstellen
In diesem Schritt legen Sie eine durchschnittliche CPU-Zielauslastung von 30 Prozent fest und erlauben zwischen einer und vier Replikas.
Bei einer Anforderung von 100m entspricht ein Zielwert von 30 % ungefähr einer durchschnittlichen CPU-Nutzung von 30m pro Pod. Der HPA passt die gewünschte Replikazahl des Deployments an, unterschreitet jedoch niemals min=1 und überschreitet niemals max=4.
cd /home/labex/project/resource-autoscaling
kubectl autoscale deployment cpu-demo -n practice-capacity --cpu=30% --min=1 --max=4
kubectl get hpa cpu-demo -n practice-capacity
kubectl describe hpa cpu-demo -n practice-capacity
Die Auslastung wird relativ zur CPU-Anforderung von 100m gemessen. Ohne diese Anforderung hätte ein prozentuales CPU-Ziel keine Bezugsgröße.
Die aktuelle Syntax von kubectl autoscale schreibt den Prozentwert ausdrücklich als --cpu=30%. Sie ersetzt das ältere Flag --cpu-percent, das Kubernetes 1.35 als veraltet meldet.
In den ersten Sekunden kann die Spalte TARGETS den Wert <unknown> anzeigen, während eine neue Metrikmessung erfasst wird. describe hpa zeigt Bedingungen und Ereignisse, anhand derer Sie erkennen können, ob der Controller nutzbare Metriken zur Verfügung hat.
Eine anfängliche Tabelle kann daher so aussehen, ohne dass ein Fehler vorliegt:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: <unknown>/30% 1 4 0
Nach der nächsten Synchronisierung des Controllers wird <unknown> durch einen gemessenen Prozentwert ersetzt, und REPLICAS spiegelt die Replikazahl des Deployments wider.
Last erzeugen und Skalierung beobachten
In diesem Schritt starten Sie bis zu 60 Sekunden lang einen temporären Client, der wiederholt Anforderungen an den Service sendet.
Der BusyBox-Befehl timeout führt 60 Sekunden lang eine verschachtelte Anforderungsschleife aus. Die while-Schleife ruft wiederholt den CPU-intensiven Demo-Endpunkt auf, und >/dev/null verwirft die Antwortinhalte, damit das Terminal übersichtlich bleibt. Wenn das Zeitlimit erreicht wird, wird normalerweise ein Status ungleich null zurückgegeben. || true behandelt dieses geplante Ende daher als normale Beendigung.
cd /home/labex/project/resource-autoscaling
kubectl run load-generator -n practice-capacity --image=busybox:1.36 --image-pull-policy=IfNotPresent --restart=Never --rm -i -- sh -c 'timeout 60 sh -c "while true; do wget -qO- http://cpu-demo >/dev/null; done" || true'
kubectl get hpa cpu-demo -n practice-capacity
kubectl get deployment cpu-demo -n practice-capacity
Der HPA reagiert asynchron, daher können Änderungen der Replikazahl noch nach dem Ende des Clients erfolgen. Untersuchen Sie die Bedingungen und Ereignisse des HPA, statt eine sofortige Skalierung zu erwarten.
Wenn in der ersten Tabelle noch keine Skalierung zu sehen ist, führen Sie kurz kubectl get hpa cpu-demo -n practice-capacity -w aus und drücken Sie Ctrl+C, sobald Sie eine Änderung beobachten. -w überwacht Aktualisierungen, verändert den HPA jedoch nicht. Der genaue Zeitpunkt ist bewusst nicht Bestandteil der Überprüfung, da Metrik-Regelkreise asynchron arbeiten.
Im getesteten Durchlauf stellte der HPA eine Auslastung oberhalb des Zielwerts fest und erhöhte das Deployment auf zwei bereite Replikas:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: 55%/30% 1 4 2
NAME READY UP-TO-DATE AVAILABLE
cpu-demo 2/2 2 2
Die genaue Auslastung und Replikazahl können abweichen. Entscheidend ist: Die aktuelle Auslastung von 55% lag über dem Zielwert von 30%, daher wurde die gewünschte Kapazität erhöht, blieb jedoch innerhalb der Grenzen von 1 bis 4 Replikas.
Zusammenfassung
Sie haben Anforderungen, Limits, aktuelle Metriken, Auslastungsziele und HPA-Entscheidungen miteinander verknüpft. Kapazitätsverwaltung ist ein Rückkopplungsprozess: Legen Sie eine Grundlage fest, beobachten Sie die Nutzung, definieren Sie Grenzen und prüfen Sie die Bedingungen des Controllers.
