Kubectl top pod: CPU- und Speicherverbrauch in Kubernetes im Blick behalten

TLDR: kubectl top pod liefert eine Live-Momentaufnahme des CPU- (Millicores) und Speicherverbrauchs (Mi/Gi) pro Pod, bereitgestellt durch den Metrics Server. Nutzen Sie den Befehl, um ressourcenhungrige Pods aufzuspüren, sortieren Sie mit --sort-by=cpu/--sort-by=memory, schlüsseln Sie den Verbrauch mit --containers pro Container auf und vergleichen Sie die tatsächliche Nutzung mit den konfigurierten Requests/Limits – so erkennen Sie Über- oder Unterprovisionierung, bevor es zu Throttling oder OOM-Kills kommt.

In diesem Artikel:

• Voraussetzungen für die Nutzung von kubectl top pod
• Grundlegende Syntax von kubectl top pod
• Anwendungsfälle für kubectl top pod
• So lesen Sie die Ausgabe von kubectl top pod
• Best Practices für kubectl top pod

So lesen Sie die Ausgabe von kubectl top pod

Die Ausgabe von kubectl top pod ist eine Momentaufnahme der aktuellen CPU- und Speichernutzung der Pods. Wer die Bedeutung der einzelnen Spalten kennt, kann ressourcenhungrige Workloads leichter identifizieren und Performance-Problemen auf den Grund gehen.

Beispielausgabe:

NAME                      CPU(cores)   MEMORY(bytes)
nginx-6d4cf56db6-xk8rt    2m           15Mi
api-server-7f89c7d9d      25m          120Mi

Die Spalten bedeuten:

• NAME — Der Name des Pods
• CPU (cores) — Aktuelle CPU-Nutzung
• MEMORY (bytes) — Aktueller Speicherverbrauch

CPU-Werte werden üblicherweise in Millicores (m) angegeben:

• 1000m entsprechen 1 CPU-Core
• 250m entsprechen 0,25 CPU-Cores

Zum Beispiel:

• 2m bedeutet, dass der Pod nur sehr wenig CPU nutzt
• 500m bedeutet, dass der Pod einen halben CPU-Core beansprucht

Speicherwerte werden in binären Einheiten angezeigt:

• Ki = Kibibyte
• Mi = Mebibyte
• Gi = Gibibyte

Die angezeigten Werte sind aktuelle Nutzungsmetriken, die der Metrics Server erfasst. Es handelt sich nicht um historische Durchschnittswerte – zwischen zwei Befehlsausführungen können sie sich ändern. kubectl top pod eignet sich daher am besten für schnelle operative Prüfungen und nicht für langfristiges Monitoring.

Ausgabe für Container:

Mit dem Flag --containers enthält die Ausgabe Metriken für jeden Container innerhalb des Pods:

kubectl top pod nginx-6d4cf56db6-xk8rt --containers

Beispielausgabe:

POD                       NAME    CPU(cores)   MEMORY(bytes)
nginx-6d4cf56db6-xk8rt    nginx   2m           15Mi

Pod-Probleme mit der top-pod-Ausgabe diagnostizieren:

Wenn Sie ungewöhnlichen Ressourcenverbrauch festgestellt haben, vergleichen Sie die tatsächliche Nutzung mit den konfigurierten Requests und Limits. So erkennen Sie, ob Pods korrekt dimensioniert sind oder nachjustiert werden müssen, um Performance und Ressourceneffizienz zu verbessern.

Best Practices für kubectl top pod

Die folgenden Praxistipps helfen Ihnen beim Einsatz des Befehls.

1. Sicherstellen, dass der Metrics Server installiert und funktionsfähig ist

Bevor Sie sich auf kubectl top pod verlassen, prüfen Sie, ob der Metrics Server in Ihrem Cluster installiert ist und einwandfrei funktioniert. Den Status prüfen Sie mit kubectl get deployment metrics-server -n kube-system und einem Blick in die Logs auf Fehler.

Ist der Metrics Server falsch konfiguriert oder nicht funktionsfähig, liefert kubectl top pod möglicherweise unvollständige Daten oder schlägt komplett fehl. Überwachen Sie den Zustand des Metrics Servers regelmäßig, damit die Ressourcenmetriken den aktuellen Zustand Ihrer Workloads widerspiegeln.

Beispiel:

kubectl --namespace=kube-system get deployment metrics-server

Ausgabe:

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           45d

Metrikerfassung prüfen:

kubectl top nodes

Ausgabe:

NAME             CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
worker-node-1    420m         21%    3120Mi           39%
worker-node-2    365m         18%    2875Mi           36%

2. Immer den richtigen Namespace prüfen

Kubernetes-Cluster umfassen häufig mehrere Namespaces, jeweils mit unterschiedlichen Workloads oder Umgebungen. Wenn Sie nicht im Default-Namespace arbeiten, geben Sie bei kubectl top pod den richtigen Namespace mit dem Flag -n an.

Wer den Namespace nicht angibt, übersieht schnell Probleme oder zieht falsche Schlüsse zur Ressourcennutzung. So könnte Ihnen etwa eine Ressourcenspitze in einer Staging-Umgebung entgehen, wenn Sie nur den Default-Namespace prüfen.

Beispiel:

kubectl --namespace production top pod

Ausgabe:

NAME                        CPU(cores)   MEMORY(bytes)
frontend-76d9c7f7f5-qn9p8   65m          210Mi
backend-5c8b7d9f67-jh2wt    220m         580Mi
redis-0                     15m          140Mi

3. Nach CPU oder Speicher sortieren, um auffällige Pods schneller zu finden

Durch das Sortieren nach CPU- oder Speichernutzung treten die Pods mit dem höchsten Ressourcenverbrauch sofort hervor. Nutzen Sie --sort-by=cpu oder --sort-by=memory, um die ressourcenintensivsten Pods an den Anfang der Ausgabe zu bringen. Die Analyse der Pods nach Ressourcenverbrauch hilft, Engpässe zu beheben, und unterstützt die Kapazitätsplanung.

Beispiel:

kubectl top pods -n production --sort-by=memory

Ausgabe:

NAME                          CPU(cores)   MEMORY(bytes)
analytics-worker-7f4b7d5c8d   320m         1850Mi
api-server-6b8f4d5f4d         140m         720Mi
frontend-76d9c7f7f5           60m          220Mi

4. Nutzung mit Requests und Limits abgleichen

Um die Ressourcenmetriken richtig zu interpretieren, vergleichen Sie die von kubectl top pod gemeldete tatsächliche Nutzung mit den in den Pod-Spezifikationen definierten Requests und Limits. Nähert sich ein Pod häufig seinen Ressourcen-Limits, drohen Throttling oder Eviction. Eine im Verhältnis zu den Requests dauerhaft niedrige Nutzung deutet auf Überprovisionierung hin. Dieser Abgleich hilft Teams, Ressourcenzuweisungen anzupassen und Probleme wie OOMKills oder CPU-Throttling zu vermeiden.

Beispiel:

Aktuelle Nutzung anzeigen:

kubectl -n production top pod api-server-6b8f4d5f4d

Ausgabe:

NAME                     CPU(cores)   MEMORY(bytes)
api-server-6b8f4d5f4d    850m         920Mi

Konfigurierte Ressourcen prüfen:

kubectl -n production describe pod api-server-6b8f4d5f4d

Ausgabe (Auszug):

Limits:
  cpu:     1
  memory:  1Gi
Requests:
  cpu:     500m
  memory:  512Mi

In diesem Beispiel nähert sich der Pod sowohl dem CPU- als auch dem Speicher-Limit und muss möglicherweise nachjustiert werden.

5. Labels für Prüfungen auf Workload-Ebene nutzen

Mit Kubernetes-Labels lassen sich Pods nach Anwendung, Umgebung oder eigenen Schlüsseln filtern und gruppieren. Kombinieren Sie kubectl top pod mit dem Flag -l, um die Ressourcennutzung eines bestimmten Workloads, Teams oder Microservices zu überwachen.

Beispiel:

Pods mit einem bestimmten Label abrufen:

kubectl -n production get pods -l app=web

Ausgabe:

NAME                       READY   STATUS
web-6d7f9d8f8b-7xt2m       1/1     Running
web-6d7f9d8f8b-kq4pn       1/1     Running

Ressourcennutzung dieser Pods prüfen:

kubectl top pod -n production | grep web

Ausgabe:

web-6d7f9d8f8b-7xt2m   35m   120Mi
web-6d7f9d8f8b-kq4pn   42m   135Mi

So können Betriebsteams den Ressourcenverbrauch einer bestimmten Anwendung oder eines Dienstes schnell bewerten, ohne nicht relevante Workloads durchsehen zu müssen.

Kontinuierliches Right-Sizing von Pod-Ressourcen mit PerfectScale

kubectl top pod liefert Ihnen zwar eine Live-Momentaufnahme des CPU- und Speicherverbrauchs – doch daraus die passenden Requests und Limits für Hunderte von Workloads abzuleiten, bleibt eine ständige manuelle Aufgabe. Die Performance-Optimierungslösung von PerfectScale verbessert die Kubernetes-Performance durch autonomes Right-Sizing von Workloads, verhindert Ausfälle und optimiert den Ressourceneinsatz für 99,99 % Verfügbarkeit. So werden aus den Nutzungsmustern, die Sie mit kubectl top pod entdecken, direkt sichere, datenbasierte Konfigurationsänderungen.

Zentrale Funktionen von PerfectScale:

• Automatische Problembehebung: Erkennt und behebt Resilienzrisiken sofort – einschließlich Unterprovisionierung wie OOM, CPU-Throttling und Eviction –, um maximale Verfügbarkeit zu gewährleisten und Latenzen zu eliminieren.
• Autonomes Right-Sizing von CPU und Speicher: Analysiert Ihre Workloads kontinuierlich und passt CPU- und Speicher-Requests und -Limits auf Basis des tatsächlichen Bedarfs an. Das reduziert das Throttling-Risiko, senkt die Cloud-Kosten und behebt genau die Über- und Unterprovisionierung, die Sie mit kubectl top pod aufspüren.
• Härtung der Infrastruktur: Bietet ganzheitliche Transparenz über Ihre Nodes, um Fehlkonfigurationen proaktiv aufzudecken, Node-Überbuchung durch präzise Empfehlungen für Speicher-Limits zu verhindern, Node-Affinitäten und Taints zu validieren und die passendsten Node-Typen für Ihre Pods auszuwählen.
• Priorisierung nach Auswirkung: Behebt kritische Probleme in Echtzeit dank automatischer Priorisierung, richtet das Alerting an Ihren SLAs/SLOs aus, sendet Sofortbenachrichtigungen über Kanäle wie Slack, MS Teams oder Datadog und eskaliert Probleme mit einem Klick in ein Ticket.

Bereit für den Schritt von manuellen Momentaufnahmen zur autonomen Optimierung? Erfahren Sie, wie PerfectScale die Kubernetes-Performance steigert.

FAQ

Warum liefert kubectl top pod die Meldung "Metrics API not available"? Der Metrics Server ist in Ihrem Cluster nicht installiert oder nicht funktionsfähig. Prüfen Sie dies mit kubectl get deployment metrics-server -n kube-system und installieren Sie ihn bei Bedarf über das offizielle Components-Manifest.

Was bedeutet die Spalte CPU(cores) eigentlich? Sie wird in Millicores (m) angegeben. 1000m entsprechen einem vollen CPU-Core, 250m sind also ein Viertel Core und 2m eine vernachlässigbare CPU-Menge.

Eignet sich kubectl top pod für langfristiges Monitoring? Nein. Es handelt sich um eine Live-Momentaufnahme des Metrics Servers, nicht um einen historischen Durchschnitt – der Befehl eignet sich daher für schnelle operative Prüfungen, nicht für Trendanalysen. Nutzen Sie für langfristiges Monitoring Prometheus/Grafana oder vergleichbare Tools.

Wie sehe ich Metriken pro Container statt pro Pod? Fügen Sie das Flag --containers hinzu: kubectl top pod <pod-name> --containers.

Wie finde ich die auffälligsten Pods in einem Namespace? Mit kubectl top pod -n <namespace> --sort-by=cpu oder --sort-by=memory sortieren Sie die Pods nach Verbrauch, den höchsten zuerst.

Woran erkenne ich, ob ein Pod unter- oder überprovisioniert ist? Vergleichen Sie die Live-Nutzung aus kubectl top pod mit den konfigurierten Requests und Limits des Pods (sichtbar über kubectl describe pod). Liegt die Nutzung dauerhaft nahe am Limit, besteht das Risiko einer Unterprovisionierung; liegt sie weit unter dem Request, deutet das auf Überprovisionierung hin.