Autoscaling: HPA und der metrics-server

kubectl top nodes funktioniert nicht — und das ist richtig

error: Metrics API not available

Das ist keine kaputte Installation. Kubernetes sammelt von sich aus keine Messwerte. kubectl top fragt eine API namens metrics.k8s.io ab, und die gehört nicht zum Kern — sie wird von einer Zusatzkomponente nachgereicht.

Das überrascht fast jeden, weil kubectl top aussieht, als gehöre es dazu. Genauso wenig gehören Dashboard, Prometheus oder ein Ingress-Controller zum Kern. Kubernetes liefert die Mechanik, nicht die Ausstattung.

Angehängte APIs

Der metrics-server registriert sich als APIService und erweitert damit die Kubernetes-API um einen Pfad. Danach fühlt sich metrics.k8s.io an wie ein eingebauter Teil:

kubectl get apiservices | grep metrics

Das ist ein Muster, das dir wieder begegnet — genau so binden sich später auch andere Erweiterungen ein.

Installieren

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
kubectl -n kube-system get deploy metrics-server -w

Und jetzt bleibt er auf 0/1 stehen.

Der Zertifikatsfehler

kubectl -n kube-system logs deploy/metrics-server | tail -20

x509: cannot validate certificate ... because it doesn't contain any IP SANs

Warum das passiert: metrics-server holt die Werte direkt beim kubelet jedes Knotens ab, über HTTPS. Die Zertifikate, mit denen sich die kubelets ausweisen, sind bei kubeadm selbstsigniert und tragen die Knoten-IP nicht als gültigen Namen. metrics-server prüft das — und weigert sich zu Recht.

Der schnelle Weg (Labor)

kubectl -n kube-system patch deployment metrics-server --type=json \
  -p='[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--kubelet-insecure-tls"}]'

Nach etwa einer Minute:

kubectl top nodes
kubectl top pods -A

Was du damit abschaltest: metrics-server prüft die Zertifikate der kubelets nicht mehr. Im Labor unkritisch, im Produktivbetrieb nicht akzeptabel — wer sich dazwischenschaltet, könnte falsche Messwerte liefern und damit Skalierungsentscheidungen beeinflussen.

Der saubere Weg

In der kubelet-Konfiguration serverTLSBootstrap: true setzen. Dann stellen die kubelets Zertifikatsanträge, die von der Cluster-CA unterschrieben werden:

kubectl get csr
kubectl certificate approve <name>

Danach stimmt die Vertrauenskette und der unsichere Schalter kann weg.

Was metrics-server ist — und was nicht

Ist:	aktuelle Werte für kubectl top und Skalierungsentscheidungen
Ist nicht:	ein Überwachungssystem

Er hält nur ein kurzes Fenster im Speicher, schreibt nichts weg und kennt keine Vergangenheit. Wer wissen will, wie die Auslastung gestern um drei war, braucht Prometheus — Folge 25.

Der HPA und seine Rechnung

kubectl autoscale deployment web --cpu-percent=50 --min=2 --max=10
kubectl get hpa

Die Formel dahinter:

gewünschte Repliken = aufgerundet( aktuelle Repliken × ( aktueller Wert / Zielwert ) )

Bei 4 Pods mit im Schnitt 80 % gegen ein Ziel von 50 %: 4 × (80/50) = 6,4 → 7 Repliken.

Der Punkt, an dem die meisten scheitern

--cpu-percent=50 heißt nicht „50 Prozent eines Kerns". Es heißt 50 Prozent der angeforderten CPU — also von resources.requests.cpu.

Ohne Requests gibt es keine Bezugsgröße, und der HPA meldet:

unable to get metrics for resource cpu: missing request for cpu

Deshalb hängt diese Folge direkt an Folge 20. Requests sind nicht nur eine Reservierung für den Scheduler — sie sind die Grundlage jeder prozentualen Skalierung.

Warum das Runterfahren so lange dauert

Hochskaliert wird sofort. Heruntergefahren erst nach dem Stabilisierungsfenster — voreingestellt 300 Sekunden.

Der Grund ist Erfahrung: Ohne diese Bremse würde die Zahl der Pods bei schwankender Last ständig hin und her springen, und jeder Wechsel kostet Startzeit und Verbindungen. Einstellbar ist es:

behavior:
  scaleDown:
    stabilizationWindowSeconds: 60

Zum Nachlesen

• Horizontal Pod Autoscaling
• metrics-server

Eine geordnete Übersicht über die offizielle Dokumentation steht unter Nachlesen.