Kubernetes Ressourcenmanagement & Autoscaling — Requests, Limits und HorizontalPodAutoscaler

In diesem 90-Minuten-Modul klärt ihr die Frage, die jedem produktiven Deployment vorausgeht: Wie viel darf ein Container eigentlich verbrauchen – und was passiert, wenn er mehr will? Zuerst die Unterscheidung, die am häufigsten durcheinandergeht: requests ist der Bedarf, den der Scheduler garantiert einplant, limits ist die Obergrenze, die der Kubelet auf dem Node zur Laufzeit durchsetzt. Daraus leitet ihr her, warum CPU bei Überschreitung nur gedrosselt (Throttling), Memory dagegen mit einem Out-Of-Memory-Kill beendet wird – und warum genau dieses Verhältnis von requests zu limits die drei Quality-of-Service-Klassen Guaranteed, Burstable und BestEffort ergibt, die bei Ressourcenknappheit über die Eviction-Reihenfolge entscheiden. Der zweite Block ergänzt eine LimitRange: ein Namespace-Default für Requests/Limits, damit Container ohne eigene Angabe nicht automatisch als BestEffort laufen – bewusst abgegrenzt von der ResourceQuota aus dem Modul Administration, die ein Namespace-Aggregat begrenzt, keinen Container-Default setzt. Den größten Block bildet der HorizontalPodAutoscaler (HPA): sein Regelkreis, der in festen Intervallen Metriken abfragt und die Replica-Zahl anpasst, kubectl autoscale als imperativer Weg und ein autoscaling/v2-Manifest als deklarativer Weg – und die harte Kopplung, die in der Praxis am häufigsten übersehen wird: Ohne gesetzte requests.cpu auf dem Ziel-Deployment hat der HPA keine Bezugsgröße für averageUtilization und skaliert schlicht nicht. Der VerticalPodAutoscaler schließt als reines Konzept ab – bewusst ohne eigenes Hands-on, weil VPA und HPA sich bei CPU/Memory gegenseitig ausschließen und ein eigener VPA-Recommender-Stack den Rahmen dieses Moduls sprengen würde. In drei Hands-on-Übungen vergleicht ihr die QoS-Klassen live inklusive Eviction-Reihenfolge, weist CPU-Throttling mit kubectl top pod nach und baut einen kompletten HPA-Regelkreis von Scale-out bis Scale-down auf – die Last dafür erzeugt ihr ausschließlich in-cluster über einen busybox-Pod, ohne externes Tool und ohne Egress. Voraussetzung ist das Modul “Kubernetes Workloads & Konfiguration” – der HPA setzt ein bestehendes Deployment voraus. Die Session läuft weiterhin vollständig lokal über Minikube, ohne Cloud-Account und ohne Kostenwirkung.