Kubectl Top Pod: monitorare l'uso di CPU e memoria in Kubernetes

In breve: kubectl top pod fornisce un'istantanea in tempo reale dell'utilizzo di CPU (millicore) e memoria (Mi/Gi) per ciascun pod, grazie al Metrics Server. È utile per individuare i pod che consumano più risorse, ordinare i risultati con --sort-by=cpu/--sort-by=memory, scomporre l'utilizzo per container con --containers e confrontare l'uso effettivo con le request e i limit configurati, così da intercettare situazioni di over- o under-provisioning prima che causino throttling o OOM kill.

In questo articolo:

• Prerequisiti per l'uso di kubectl top pod
• Sintassi di base di kubectl top pod
• Casi d'uso di kubectl top pod
• Come leggere l'output di kubectl top pod
• Best practice per l'uso di kubectl top pod

Come leggere l'output di kubectl top pod

L'output di kubectl top pod fornisce un'istantanea dell'utilizzo attuale di CPU e memoria dei pod. Comprendere il significato di ciascuna colonna aiuta a individuare i workloads più esigenti e a diagnosticare i problemi di prestazioni.

Esempio di output:

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

Le colonne rappresentano:

• NAME — Il nome del pod
• CPU (cores) — L'utilizzo attuale della CPU
• MEMORY (bytes) — Il consumo attuale di memoria

I valori di CPU sono generalmente espressi in millicore (m):

• 1000m equivalgono a 1 core CPU
• 250m equivalgono a 0,25 core CPU

Ad esempio:

• 2m significa che il pod sta usando una quantità di CPU molto ridotta
• 500m significa che il pod sta consumando metà di un core CPU

I valori di memoria sono espressi in unità binarie:

• Ki = kibibyte
• Mi = mebibyte
• Gi = gibibyte

I valori mostrati sono metriche di utilizzo corrente raccolte dal Metrics Server. Non si tratta di medie storiche e possono variare tra un'esecuzione del comando e l'altra. Per questo motivo, kubectl top pod è più indicato per verifiche operative rapide che per il monitoraggio a lungo termine.

Output per i container:

Utilizzando il flag --containers, l'output include le metriche di ciascun container all'interno del pod:

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

Esempio di output:

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

Usare l'output di top pod per diagnosticare i problemi dei pod:

Dopo aver individuato un consumo di risorse anomalo, confrontare l'utilizzo effettivo con le request e i limit configurati. In questo modo si può stabilire se i pod sono dimensionati correttamente o se richiedono una messa a punto per migliorare prestazioni ed efficienza delle risorse.

Best practice per l'uso di kubectl top pod

Ecco alcune pratiche utili da tenere presenti quando si utilizza questo comando.

1. Verificare che il Metrics Server sia installato e funzionante

Prima di affidarsi a kubectl top pod, verificare che il Metrics Server sia installato e funzioni correttamente nel cluster. È possibile controllarne lo stato con kubectl get deployment metrics-server -n kube-system ed esaminare i log alla ricerca di errori.

Se il Metrics Server non è configurato correttamente o presenta problemi, kubectl top pod potrebbe restituire dati incompleti o fallire del tutto. Monitorare regolarmente lo stato del Metrics Server per garantire che le metriche riflettano la situazione attuale dei workloads.

Esempio:

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

Output:

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

Verificare la raccolta delle metriche:

kubectl top nodes

Output:

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

2. Controllare sempre il namespace giusto

I cluster Kubernetes ospitano spesso più namespace, ciascuno con workloads o ambienti diversi. Quando si usa kubectl top pod, specificare il namespace corretto con il flag -n se non si sta lavorando in quello predefinito.

Non specificare il namespace può portare a trascurare problemi o a trarre conclusioni errate sull'utilizzo delle risorse. Ad esempio, si potrebbe non notare un picco di risorse in un ambiente di staging se si controlla solo il namespace di default.

Esempio:

kubectl --namespace production top pod

Output:

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

3. Ordinare per CPU o memoria per trovare più in fretta i pod "rumorosi"

Ordinare i pod per utilizzo di CPU o memoria mette in evidenza quelli che consumano più risorse. Usare --sort-by=cpu o --sort-by=memory per portare in cima all'output i pod più esigenti. Esaminare i pod in base al consumo di risorse aiuta a risolvere i colli di bottiglia e facilita la pianificazione della capacità.

Esempio:

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

Output:

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

4. Confrontare l'utilizzo con request e limit

Per interpretare le metriche delle risorse, confrontare l'utilizzo effettivo riportato da kubectl top pod con le request e i limit definiti nelle specifiche dei pod. Se un pod si avvicina spesso ai propri limiti di risorse, può subire throttling o eviction. Un utilizzo costantemente basso rispetto alle request indica invece over-provisioning. Questo confronto aiuta i team a regolare l'allocazione delle risorse ed evitare problemi come gli OOMKill o il throttling della CPU.

Esempio:

Visualizzare l'utilizzo corrente:

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

Output:

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

Controllare le risorse configurate:

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

Output (estratto):

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

In questo esempio, il pod si sta avvicinando sia al limite di CPU sia a quello di memoria e potrebbe richiedere una messa a punto.

5. Usare le label per le verifiche a livello di workload

Le label di Kubernetes consentono di filtrare e raggruppare i pod per applicazione, ambiente o chiave personalizzata. Combinando kubectl top pod con il flag -l, è possibile monitorare l'utilizzo delle risorse di un workload, un team o un microservizio specifico.

Esempio:

Recuperare i pod con una label specifica:

kubectl -n production get pods -l app=web

Output:

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

Controllare l'utilizzo delle risorse di quei pod:

kubectl top pod -n production | grep web

Output:

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

In questo modo gli operatori possono valutare rapidamente il consumo di risorse di una specifica applicazione o di un servizio senza passare in rassegna workloads non pertinenti.

Come applicare il right-sizing continuo alle risorse dei pod con PerfectScale

kubectl top pod offre un'istantanea in tempo reale dell'utilizzo di CPU e memoria, ma tradurre quelle letture nelle request e nei limit corretti su centinaia di workloads è un lavoro manuale e continuo. La soluzione di ottimizzazione delle prestazioni di PerfectScale migliora le performance di Kubernetes applicando in modo autonomo il right-sizing dei workloads, prevenendo i downtime e ottimizzando l'uso delle risorse per una disponibilità del 99,99%: così i pattern di utilizzo individuati con kubectl top pod si traducono direttamente in modifiche di configurazione sicure e basate sui dati.

Le funzionalità chiave di PerfectScale:

• Risoluzione automatica dei problemi: identifica e corregge all'istante i rischi per la resilienza, inclusi i problemi di under-provisioning delle risorse come OOM, throttling della CPU ed eviction, per massimizzare l'uptime ed eliminare la latenza.
• Right-sizing autonomo di CPU e memoria: analizza continuamente i workloads e regola request e limit di CPU e memoria in base alla domanda effettiva, riducendo il rischio di throttling e i costi cloud, e risolvendo l'over- e l'under-provisioning che kubectl top pod aiuta a rilevare.
• Hardening dell'infrastruttura: offre visibilità completa sui nodi per far emergere in modo proattivo le configurazioni errate, prevenire l'over-commitment dei nodi con raccomandazioni precise sui limiti di memoria, validare node affinity e taint e selezionare i tipi di nodo più adatti ai pod.
• Prioritizzazione basata sull'impatto: risolve i problemi critici in tempo reale con la prioritizzazione automatica, allinea gli alert a SLA/SLO, invia notifiche istantanee su canali come Slack, MS Teams o Datadog e converte un problema in un ticket con un solo clic.

Pronto a passare dalle istantanee manuali all'ottimizzazione autonoma? Scopra come PerfectScale migliora le prestazioni di Kubernetes.

FAQ

Perché kubectl top pod restituisce "Metrics API not available"? Il Metrics Server non è installato o non funziona correttamente nel cluster. Verificare con kubectl get deployment metrics-server -n kube-system e, se manca, installarlo dal manifest ufficiale dei componenti.

Cosa indica esattamente la colonna CPU(cores)? È espressa in millicore (m). 1000m equivalgono a un core CPU completo, quindi 250m corrispondono a un quarto di core e 2m a una quantità trascurabile di CPU.

kubectl top pod è adatto al monitoraggio a lungo termine? No. È un'istantanea in tempo reale fornita dal Metrics Server, non una media storica, quindi è più indicato per verifiche operative rapide che per l'analisi dei trend. Per il monitoraggio a lungo termine, usare Prometheus/Grafana o strumenti simili.

Come si visualizzano le metriche per container anziché per pod? Aggiungere il flag --containers: kubectl top pod <pod-name> --containers.

Come si trovano i pod più "rumorosi" in un namespace? Usare kubectl top pod -n <namespace> --sort-by=cpu o --sort-by=memory per ordinare i pod per consumo, dal più alto al più basso.

Come capire se un pod è in under- o over-provisioning? Confrontare l'utilizzo in tempo reale di kubectl top pod con le request e i limit configurati del pod (visibili con kubectl describe pod). Un utilizzo costantemente vicino al limit indica un rischio di under-provisioning; un utilizzo molto inferiore alla request indica over-provisioning.