Kubernetes Workloads im Griff: 6 Typen, Lifecycle und Best Practices

Monitoring von Kubernetes Workloads

Das Monitoring von Kubernetes Workloads sollte mehr leisten, als nur anzuzeigen, ob Pods laufen. Ziel ist es, Kapazitätsprobleme, instabile Anwendungen, Scheduling-Engpässe und ineffiziente Ressourcenzuweisung zu identifizieren – und diese Erkenntnisse zu nutzen, um Ressourceneinstellungen, Autoscaling-Richtlinien und Workload-Konfiguration zu optimieren.

CPU- und Memory-Auslastung

CPU- und Memory-Metriken helfen zu beurteilen, ob Workloads genug Ressourcen haben, um zuverlässig zu laufen, ohne mehr Cluster-Kapazität zu reservieren als nötig.

Zu überwachende Metriken

• CPU-Nutzung: Tatsächlich verbrauchte CPU je Container und Pod.
• CPU-Requests: Für das Scheduling reservierte CPU.
• CPU-Limits: Maximale CPU, die ein Container nutzen darf, sofern Limits konfiguriert sind.
• CPU-Throttling: Zeit, in der ein Container daran gehindert wird, zusätzliche CPU zu nutzen, weil er sein CPU-Limit erreicht hat.
• Memory-Nutzung und Working Set: Aktiv vom Workload verbrauchter Arbeitsspeicher.
• Memory-Requests und -Limits: Reservierter Arbeitsspeicher und maximal zulässiger Arbeitsspeicher für den Container.
• Auslastungstrends: Historische Nutzungsmuster, einschließlich Spitzen, dauerhafter Auslastung und schleichendem Memory-Wachstum.

Der Vergleich der tatsächlichen Auslastung mit den Requests ist besonders aufschlussreich, da Requests sowohl das Pod-Scheduling als auch das Verhalten des Horizontal Pod Autoscalers beeinflussen, wenn Metriken zur Ressourcenauslastung verwendet werden.

Tipps zur Optimierung

Nutzen Sie Auslastungsdaten, um Resource Requests per Right-Sizing anzupassen, statt sich nur auf anfängliche Schätzungen zu verlassen. Dauerhaft unterausgelastete Workloads haben möglicherweise unnötig hohe Requests, während Workloads, die regelmäßig an ihre verfügbaren Ressourcen stoßen, mehr Kapazität benötigen könnten.

Mögliche Maßnahmen:

• CPU- und Memory-Requests anpassen, damit sie den beobachteten Bedarf besser widerspiegeln.
• Anhaltendes CPU-Throttling untersuchen, statt einfach die Limits zu erhöhen.
• Memory-Limits erhöhen, wenn der legitime Workload-Bedarf die aktuellen Einstellungen übersteigt.
• Stetiges Memory-Wachstum auf mögliche Memory-Leaks untersuchen.
• HPA, VPA oder andere Autoscaling-Mechanismen einsetzen, wenn sich der Ressourcenbedarf mit der Nachfrage deutlich ändert.
• Langfristige Perzentile und Spitzenzeiten betrachten, statt anhand einer einzelnen Momentaufnahme zu optimieren.

Pod-Neustarts und -Fehler

Restart- und Fehlermetriken decken instabile Workloads auf, die an der aktuellen Pod-Phase nicht unbedingt erkennbar sind. Ein Pod kann Running melden, während einer seiner Container wiederholt abstürzt und neu startet.

Zu überwachende Metriken und Signale

• Anzahl und Rate der Container-Neustarts
• Grund der Container-Terminierung
• Exit-Codes
• Aktueller und vorheriger Container-Zustand
• Fehlgeschlagene Startup-, Readiness- und Liveness-Probes
• CrashLoopBackOff-Events
• Image-Pull- und Konfigurationsfehler
• Anwendungslogs vor und nach einem Neustart

Die Restart-Rate über die Zeit zu überwachen ist in der Regel nützlicher, als auf einen einzelnen Neustart zu reagieren. Plötzliche Anstiege oder anhaltende Restart-Schleifen sind deutlichere Hinweise auf ein zugrunde liegendes Problem.

Tipps für Troubleshooting und Optimierung

Die richtige Reaktion hängt davon ab, warum der Container neu gestartet wurde. Beginnen Sie mit dem Terminierungsgrund, dem vorherigen Container-Zustand, den Kubernetes-Events und den Anwendungslogs.

Typische Maßnahmen:

• Anwendungsabstürze oder unbehandelte Exceptions beheben.
• Probes anpassen, die für Start- oder Antwortzeiten der Anwendung zu aggressiv sind.
• Fehlende Secrets, ConfigMaps, Volumes oder Umgebungsvariablen korrigieren.
• Memory erhöhen, wenn Neustarts durch OOM-Zustände verursacht werden.
• Nicht verfügbare nachgelagerte Services untersuchen, wenn Fehler mit Abhängigkeitsfehlern zusammenfallen.
• Jüngste Deployments überprüfen, wenn die Restart-Rate unmittelbar nach einem Rollout steigt.

Behandeln Sie Neustarts nicht ausschließlich als Kapazitätsproblem. Mehr Ressourcen lösen keine Fehler, die durch Anwendungsbugs, ungültige Konfiguration oder falsch konfigurierte Health-Probes verursacht werden.

Pending und nicht einplanbare Pods

Pending Pods können darauf hindeuten, dass die Workload-Nachfrage die verfügbare Cluster-Kapazität übersteigt oder dass Scheduling-Beschränkungen Kubernetes daran hindern, einen geeigneten Node zu finden.

Zu überwachende Metriken und Signale

• Anzahl der Pending Pods
• Dauer, die Pods im Status Pending verbleiben
• Anzahl nicht einplanbarer Pods
• Scheduler-Events und Ablehnungsgründe
• Angeforderte CPU, Memory, GPUs und weitere Ressourcen
• Verfügbare Kapazität auf geeigneten Nodes
• Node-Affinity- und Selector-Anforderungen
• Taints und Tolerations
• Topology Spread Constraints
• Scheduling- und Attachment-Bedingungen für PersistentVolumes

Besonders aussagekräftig ist das Alter der Pending Pods. Kurze Scheduling-Verzögerungen können normal sein, während Pods, die über längere Zeit nicht einplanbar bleiben, in der Regel ein Eingreifen erfordern.

Tipps zur Behebung von Scheduling-Engpässen

Klären Sie zunächst, ob das Problem an fehlender Kapazität oder an zu restriktiven Scheduling-Regeln liegt.

Mögliche Maßnahmen:

• Resource Requests per Right-Sizing anpassen, wenn Pods deutlich mehr Kapazität anfordern, als sie tatsächlich benötigen.
• Node-Selectors, Affinity-Regeln oder Tolerations korrigieren, die die Platzierung unnötig einschränken.
• Topology-Spread-Anforderungen überprüfen, wenn Kubernetes nicht genügend geeignete Nodes findet.
• Sicherstellen, dass GPU- oder andere spezialisierte Workloads Zugriff auf kompatible Nodes haben.
• Cluster-Kapazität erweitern, wenn der legitime Workload-Bedarf die verfügbaren Ressourcen übersteigt.
• Node-Autoscaling konfigurieren, damit neue Kapazität automatisch bereitgestellt werden kann.

In dynamisch skalierten Umgebungen sollten dauerhaft im Status Pending verbleibende Pods auch eine Überprüfung der Node-Provisioning-Ebene auslösen. Karpenter kann beispielsweise Nodes auf Basis der Anforderungen nicht einplanbarer Pods bereitstellen – die NodePool-Constraints müssen die Erstellung geeigneter Instanzkapazität jedoch zulassen.

OOMKilled-Container

OOMKilled bedeutet, dass ein Container durch das Out-of-Memory-Handling des Betriebssystems beendet wurde. Eine häufige Ursache ist ein Container, der versucht, mehr Memory zu verbrauchen, als sein konfiguriertes Limit erlaubt.

Zu überwachende Metriken und Signale

• Terminierungsgrund des Containers: OOMKilled
• Exit-Code 137
• Memory Working Set
• Memory-Requests und -Limits
• Memory-Spitzenverbrauch
• Memory-Auslastung unmittelbar vor der Terminierung
• Restart-Häufigkeit nach OOM-Events
• Langfristiges Memory-Wachstum

Historische Metriken sind besonders wertvoll, da aktuelle Container-Metriken nach einem Neustart des Containers zurückgesetzt werden.

Tipps zur Vermeidung von OOM-Kills

Klären Sie zunächst, ob die Memory-Nutzung einem legitimen Anwendungsbedarf oder einem anomalen Verhalten entspricht.

Mögliche Optimierungen:

• Memory-Limits erhöhen, wenn normale Workloads legitim mehr Kapazität benötigen.
• Memory-Requests anheben, wenn Pods dauerhaft deutlich mehr Memory verbrauchen als angefordert.
• Memory-Leaks in der Anwendung untersuchen, wenn die Nutzung über die Zeit kontinuierlich wächst.
• Parallelität oder Batch-Größen begrenzen, wenn einzelne Anfragen große Memory-Spitzen verursachen.
• Caches, JVM-Heap-Einstellungen und Memory-Konfiguration auf Anwendungsebene überprüfen.
• Historische Auslastungsdaten nutzen, um realistische Ressourceneinstellungen festzulegen.
• Vertikales Autoscaling in Betracht ziehen, wenn sich der Memory-Bedarf über die Zeit deutlich verändert.

Memory-Limits wiederholt zu erhöhen, ohne die Ursache zu identifizieren, kann Anwendungsprobleme verschleiern und die Infrastrukturkosten in die Höhe treiben. Ressourcenänderungen sollten daher auf dem Workload-Verhalten und der historischen Nutzung basieren – nicht allein auf OOM-Events.

Best Practices für das Management von Kubernetes Workloads

Präzise Resource Requests und Limits definieren

Legen Sie CPU- und Memory-Requests auf Basis realistischer Workload-Anforderungen fest. Der Scheduler nutzt Requests bei der Entscheidung, wo Pods platziert werden – zu hohe Werte können Cluster-Kapazität verschwenden oder Pods im Status Pending zurücklassen. Zu niedrige Requests können zu überlasteten Nodes führen.

Setzen Sie Limits dort ein, wo sie sinnvollen Schutz vor übermäßigem Ressourcenverbrauch bieten. CPU-Limits können Throttling verursachen, während das Überschreiten eines Memory-Limits zu einem OOMKilled-Container führen kann. Testen Sie Limit-Einstellungen unter repräsentativer Last, statt willkürliche Werte zu wählen.

Workloads kontinuierlich per Right-Sizing anpassen

Der Ressourcenbedarf ändert sich, wenn sich Anwendungscode, Traffic und Nutzungsmuster weiterentwickeln. Prüfen Sie den tatsächlichen CPU- und Memory-Verbrauch regelmäßig und vergleichen Sie ihn mit den konfigurierten Requests und Limits.

Nutzen Sie beim Right-Sizing historische Metriken statt kurzer Momentaufnahmen. Berücksichtigen Sie Normalbetrieb, Spitzenlasten, Startanforderungen und erwartetes Wachstum. So reduzieren Sie ungenutzte Kapazität, ohne Anwendungen anfällig für vorhersehbare Lastspitzen zu machen.

Den passenden Workload-Controller verwenden

Wählen Sie den Controller danach aus, wie die Anwendung laufen muss. Nutzen Sie Deployments für zustandslose, dauerhaft laufende Anwendungen und StatefulSets, wenn Replikate stabile Identitäten, geordnete Abläufe oder persistenten Storage benötigen.

DaemonSets eignen sich für Software, die auf ausgewählten Nodes laufen muss, etwa Monitoring- oder Netzwerk-Agents. Nutzen Sie Jobs für endliche Tasks und CronJobs für zeitgesteuerte Ausführung. Mit dem richtigen Controller erhalten Sie das passende Lifecycle-Verhalten ohne eigene Verwaltungslogik.

Readiness-, Liveness- und Startup-Probes konfigurieren

Nutzen Sie Readiness-Probes, um zu bestimmen, wann ein Pod sicher Traffic empfangen kann. Eine fehlgeschlagene Readiness-Probe entfernt den Pod aus den regulären Service-Endpoints, ohne seinen Container neu zu starten – geeignet für temporäre Zustände wie Abhängigkeitsfehler oder Initialisierung.

Nutzen Sie Liveness-Probes, um Anwendungen zu erkennen, die sich ohne Neustart nicht erholen können. Startup-Probes sind hilfreich für Anwendungen mit langen oder unvorhersehbaren Initialisierungszeiten, weil sie verhindern, dass Liveness-Checks die Anwendung vor Abschluss des Starts neu starten.

Konfigurieren Sie Probe-Pfade, Schwellenwerte, Intervalle und Timeouts mit Bedacht. Zu aggressive Probes können selbst Fehler erzeugen, indem sie gesunde, aber vorübergehend langsame Anwendungen neu starten.

Pod Disruption Budgets für kritische Anwendungen nutzen

Ein PodDisruptionBudget begrenzt, wie viele Replikate einer Anwendung bei freiwilligen Unterbrechungen nicht verfügbar sein dürfen. Solche Unterbrechungen können bei Operationen wie Node-Draining, Cluster-Wartung oder bestimmten Autoscaling-Aktivitäten auftreten.

Konfigurieren Sie das Budget über minAvailable oder maxUnavailable entsprechend den Redundanzanforderungen der Anwendung. Ein Budget verhindert nicht jede Art von Ausfall, etwa einen unerwarteten Node-Ausfall, und kann keine Verfügbarkeit sicherstellen, wenn eine Anwendung zu wenige Replikate hat.

Vermeiden Sie Budgets, die Routinewartungen unmöglich machen. Der Workload braucht genügend gesunde Replikate, damit Kubernetes das Budget einhalten und gleichzeitig Pods sicher verdrängen kann.

Replikate über Nodes und Availability Zones verteilen

Mehrere Replikate bieten nur begrenzten Schutz, wenn sie alle auf demselben Node oder in derselben Fehlerdomäne laufen. Nutzen Sie Pod-Anti-Affinity oder Topology Spread Constraints, um Replikate über Nodes, Zonen oder andere Topologiegrenzen zu verteilen.

Die Verteilung reduziert die Auswirkungen von Node- und Availability-Zone-Ausfällen. Sie kann außerdem verhindern, dass die Wartung eines einzelnen Nodes zu viel Anwendungskapazität auf einmal entzieht.

Wägen Sie Resilienzanforderungen und Scheduling-Flexibilität gegeneinander ab. Strikte Platzierungsregeln können Pods im Status Pending zurücklassen, wenn der Cluster nicht genügend geeignete Nodes in der geforderten Topologie hat.

Workload- und Cluster-Autoscaling kombinieren

Workload-Autoscaling und Cluster-Autoscaling lösen unterschiedliche Kapazitätsprobleme. Der HorizontalPodAutoscaler kann Anwendungsreplikate anhand von Metriken erhöhen oder verringern, während das Autoscaling auf Node-Ebene die Cluster-Kapazität anpassen kann, wenn Pods mit den vorhandenen Ressourcen nicht eingeplant werden können.

Diese Mechanismen sollten gemeinsam konfiguriert werden. Ein Deployment zu skalieren bringt wenig, wenn neue Replikate Pending bleiben, weil der Cluster keine Kapazität hat. Umgekehrt erhöht das Hinzufügen von Nodes nicht automatisch die Anzahl der Anwendungsreplikate, wenn die Nachfrage steigt.

Präzise Resource Requests sind für beide Mechanismen wichtig, da sie Scheduling- und Kapazitätsentscheidungen beeinflussen. Legen Sie sinnvolle Skalierungsbereiche fest und überwachen Sie das Skalierungsverhalten, um übermäßige Änderungen, träge Reaktionen auf Nachfrage oder unnötige Infrastrukturnutzung zu vermeiden.

FAQ

Was ist ein Kubernetes Workload? Ein Kubernetes Workload ist eine Anwendung, ein Service oder ein Task, der auf einem Cluster läuft. Workloads werden innerhalb von Pods ausgeführt, in der Regel aber über übergeordnete Ressourcen verwaltet, die Kubernetes vorgeben, wie diese Pods erstellt, ersetzt, skaliert, aktualisiert und beendet werden.

Was sind die wichtigsten Typen von Kubernetes Workloads? Die zentralen integrierten Workload-Ressourcen sind Deployments, StatefulSets, DaemonSets, Jobs, CronJobs und ReplicaSets. Jede deckt einen anderen Bedarf ab, etwa zustandslose Services, zustandsbehaftete Anwendungen, Agents auf Node-Ebene, einmalige Tasks und geplante Tasks.

Was ist der Unterschied zwischen einem Deployment und einem StatefulSet? Ein Deployment verwaltet zustandslose Anwendungen, deren Pod-Replikate austauschbar sind. Ein StatefulSet ist für Anwendungen gedacht, deren Pods stabile Namen, eine vorhersehbare Reihenfolge oder eigenen persistenten Storage benötigen, etwa Datenbanken.

Was ist der Unterschied zwischen einem Job und einem CronJob? Ein Job führt einen oder mehrere Pods aus, bis ein Task erfolgreich abgeschlossen ist, etwa eine Datenbankmigration. Ein CronJob erstellt Jobs nach einem wiederkehrenden Zeitplan in Cron-Syntax – passend für Aufgaben wie Backups und Berichterstellung.

Was ist der Unterschied zwischen einem Kubernetes Workload und der Workload-API? Ein Workload ist die verwaltete Ressource, etwa ein Deployment oder ein Job. Die Workload-API ist die Kubernetes-API-Schnittstelle, über die Tools, Controller und Anwendungen diese Ressourcen erstellen, lesen, aktualisieren, löschen und skalieren.

Warum hängt mein Pod im Status Pending fest? Pending Pods bedeuten meist, dass dem Cluster Kapazität fehlt oder Scheduling-Regeln Kubernetes daran hindern, einen geeigneten Node zu finden. Prüfen Sie die Scheduler-Events und anschließend Resource Requests, Node-Selectors, Affinity-Regeln, Tolerations und Topology Spread Constraints. Node-Autoscaling kann Kapazität ergänzen, wenn der Bedarf legitim ist.

So optimieren Sie Kubernetes Workloads mit PerfectScale

PerfectScale by DoiT ist eine Plattform zur Ressourcenoptimierung über alle Kubernetes-Cluster hinweg. Nach einem einmaligen Helm-Deployment liefert sie umsetzbare Einblicke und autonome Optimierung über Ihren gesamten K8s-Stack – von einzelnen Workloads bis zu den zugrunde liegenden Nodes. Sie arbeitet mit Autoscalern wie HPA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning und Google Autopilot zusammen. Unterstützt werden Public Clouds wie EKS, GKE und AKS, Private Clouds wie OpenShift sowie On-Premises- und Hybrid-Umgebungen.

Zentrale Funktionen von PerfectScale:

• Autonomes Workload-Right-Sizing: Podfit bietet einen granularen Blick auf Cluster-Gesundheit und -Kosten, identifiziert verschwendete Ressourcen und Resilienzrisiken und liefert datenbasierte Empfehlungen für das Right-Sizing von Workloads. Für die sofortige Optimierung lässt sich zusätzlich eine Automatisierung einrichten.
• Empfehlungen für die Autoscaling-Konfiguration: Erhalten Sie umsetzbare Empfehlungen zur Verbesserung Ihrer HPA- und KEDA-Konfigurationen, damit Workloads effizient mit der Nachfrage skalieren.
• Optimierung von ephemeren und ML-Workloads: Ephemere Workloads wie Airflow- und Spark-Jobs werden autonom per Right-Sizing angepasst, damit auch dynamische Umgebungen optimiert bleiben.
• Revisionsbewusste Automatisierung: PerfectScale bewertet jedes neue Code-Release und passt sich an veränderte Workload-Anforderungen an, sodass seine Optimierungen Ihren Entwicklungsänderungen nie widersprechen.
• Optimierung auf Node-Ebene: Infrafit schafft Transparenz über die Node-Auslastung und hilft, ungenutzte Kapazität zu eliminieren, die richtigen Nodes für Ihre Workloads auszuwählen und die Wirkung von Node-Autoscalern wie Karpenter zu maximieren.
• Priorisierte Echtzeit-Alerts: Begegnen Sie Resilienzrisiken und Kostenspitzen mit wirkungsbasierter Priorisierung – mit Alerts in Slack, Datadog, MS Teams, PagerDuty und weiteren Tools.
• Trend- und Governance-Reporting: Verfolgen Sie Kosten-, Waste- und Risikometriken über die Zeit – über Cluster, Node-Gruppen, Namespaces und Workloads hinweg –, um Prognosen und Ursachenanalysen zu verbessern.

Erfahren Sie, wie PerfectScale Performance und Kosten von Kubernetes Workloads kontinuierlich optimiert