Introduzione
In Linux, usando il comando top, è possibile visualizzare in tempo reale i processi attivi sul sistema. Usato come strumento di diagnostica, o semplicemente per monitorare il consumo di risorse, è innegabile la sua utilità, soprattutto grazie alla capacità di identificare quale processo è responsabile di un consumo elevato di risorse computazionali.
Esiste uno strumento analogo in Kubernetes? Capace di monitorare i consumi di risorse di Pod o addirittura i consumi per nodo?
Il comando kubectl top risponde a questa domanda!
Installazione del Metrics Server
Purtroppo, provare ad usare il comando kubectl top node in un nuovo Cluster Kubernetes porterà ad un errore:
Come si evince dall’ output del comando manca l’API del server di metriche, e senza di esse è impossibile raccogliere le metriche di nodi o pod.
Se il Metrics Server è già installato all’interno del tuo Cluster, e quindi non hai ottenuto questo output, puoi saltare questo paragrafo.
Il progetto Metrics Server è gestito e mantenuto dalla Kubernetes SIGs (Kubernetes Special Interest Group), su GitHub è possibile trovare tutta la documentazione a riguardo.
È possibile installare il Metrics Server, sia tramite Helm Chart, che direttamente scaricando i manifest ed applicandoli nel Cluster, come è possibile vedere in questo link.
In questo articolo vengono utilizzati i manifest. È possibile anche indicare latest invece della versione, per scaricare l’ ultima versione disponibile:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Prima di poter usare il Metrics Server correttamente, potrebbe essere necessario aggiungere un parametro alla configurazione del Deployment per consentire la comunicazione con i nodi usando self signed cerificate (gli oggetti creati tramite i manifest precedenti vengono creati nel Namespace kube-system) :
kubectl edit deployments.apps -n kube-system metrics-server
--kubelet-insecure-tls
Usando il comando kubectl top, si può controllare la corretta installazione del Metrics Server
Kubectl top node
Kubectl top
Usando il comando kubectl top è possibile monitorare i consumi di risorse per nodi o per pod, usando rispettivamente:
Kubectl top node
Kubectl top pod
In questo ambiente ci sono tre deployment con diverse repliche e diverse immagini:
Kubectl top esprime i consumi di CPU in millicore, dove 1000m equivale al 100% di un singolo core della CPU.
100m | 10% di un core |
500m | 50% di un core |
1000m | Un core |
2000m | Due core |
Il Metrics Server potrebbe avere bisogno di qualche minuto dopo la creazione di nuovi Pod, prima di fornire metriche esatte, pertanto è sempre necessario attendere.
Filtrare ed Ordinare gli oggetti
Con kubectl top esistono diversi metodi per filtrare gli oggetti di cui si vogliono conoscere i consumi:
Per ottenere i consumi di una risorsa specifica, sia essa un Nodo o un Pod, bisogna indicare il nome della risorsa nel comando:
Per filtrare gli oggetti grazie ad una label risulterà necessario il flag "--selector" e poi la label.
È possibile ordinare l’elenco degli oggetti per consumo di CPU o memoria, usando rispettivamente i flag "--sort-by=cpu" o "--sort-by=memory".
È anche possibile specificare un namespace, ed ottenere solo i Pod contenuti in quel Namespace:
Ed ovviamente è anche possibile utilizzare insieme questi parametri per filtrare al meglio le risorse ed ottenere solo i risultati interessati:
CONCLUSIONE
Grazie al Metrics Server in Kubernetes è possibile avere rapidamente informazioni sul consumo di CPU e memoria all’ interno del Cluster, e grazie ai parametri del comando kubectl top e possibile filtrare ed ordinare queste informazioni, in modo da ottenere informazione specifiche e capillari sul carico di lavoro del Cluster.
Il Metrics Server è anche un componente fondamentale per il funzionamento di altri componenti in Kubernetes, tra cui l’Horizontal Pod Autoscaler o la Kubernetes Dashboard; pertanto, i sui utilizzi non sono limitati al monitoraggio.
Installare il Metrics Server è anche il primo strumento da utilizzare per diagnosticare eventuali problemi di prestazioni e decidere se ingrandire il Cluster o ridurre il numero di Pod.
A cura di Pascal Carone
