Performance di Kubernetes: 10 metriche chiave e guida al tuning

Che cos'è la performance di Kubernetes?

TL;DR: La performance di Kubernetes è definita da efficienza, affidabilità e velocità del cluster. Le aree chiave includono i tempi di avvio dei pod, la reattività dell'API server e il consumo di risorse. Per ottimizzarla è necessario mettere a punto l'allocazione delle risorse, evitare il throttling della CPU e utilizzare strumenti come ClusterLoader2 per effettuare benchmark dei limiti sotto carico.

Metriche di performance critiche:

Per mantenere il cluster in salute, è necessario monitorare attivamente queste aree fondamentali del sistema:

• Utilizzo della CPU: monitorare l'utilizzo della CPU a livello di pod, container e nodo per identificare contesa di risorse, throttling e vincoli di capacità.
• Utilizzo della memoria: tenere traccia del consumo di memoria per rilevare memory leak, prevenire la pressione sui nodi ed evitare l'eviction dei pod.
• Riavvii dei pod: prestare attenzione ai riavvii frequenti dei container, che possono indicare crash applicativi, probe fallite o superamento dei limiti di risorse.
• Stato e disponibilità dei pod: monitorare gli stati e la readiness dei pod per garantire che i workloads restino integri e in grado di servire il traffico.
• Metriche di pressione dei nodi: monitorare il throttling della CPU, il consumo totale di memoria e l'I/O su disco, poiché i colli di bottiglia a livello di nodo si ripercuotono sui workloads.
• I/O di disco e storage: misurare throughput, latenza e IOPS per individuare i colli di bottiglia dello storage che incidono sulle prestazioni applicative.
• Performance dello scheduler: monitorare la latenza di scheduling, i pod in stato Pending e i fallimenti di scheduling per garantire un posizionamento efficiente dei workloads.
• Metriche di autoscaling: monitorare attività di scaling, numero di repliche e metriche di utilizzo per verificare che gli autoscaler rispondano adeguatamente alle variazioni della domanda.
• Metriche applicative: misurare latenza, throughput, tassi di errore e altri indicatori a livello di servizio per comprendere le prestazioni percepite dagli utenti.
• Metriche del control plane: monitorare la latenza di etcd (idealmente <10 ms) e le latenze delle richieste di kube-apiserver per prevenire colli di bottiglia a livello di API.

In questo articolo:

• Perché la performance di Kubernetes è importante
• Problemi comuni di performance in Kubernetes
• Metriche di performance critiche di Kubernetes
• Come risolvere i problemi di performance di Kubernetes
• Best practice di tuning delle performance di Kubernetes

---

Perché la performance di Kubernetes è importante

La performance di Kubernetes incide su disponibilità delle applicazioni, scalabilità ed efficienza dei costi. Un cluster performante gestisce workloads variabili con ritardi minimi, mentre prestazioni scadenti possono tradursi in tempi di risposta più lenti, interruzioni del servizio e spreco di risorse infrastrutturali. Poiché le organizzazioni si affidano a Kubernetes per eseguire i sistemi di produzione, mantenere prestazioni elevate è indispensabile per raggiungere gli obiettivi di business e operativi.

• Migliora l'affidabilità delle applicazioni: un'allocazione delle risorse e uno scheduling efficienti aiutano le applicazioni a restare stabili con workloads variabili, riducendo il rischio di interruzioni e degrado delle prestazioni.
• Migliora l'esperienza utente: tempi di avvio dei pod più rapidi, latenza inferiore e reattività costante delle applicazioni migliorano l'esperienza degli utenti finali.
• Supporta uno scaling efficiente: i cluster ad alte prestazioni rispondono rapidamente alle variazioni della domanda, garantendo che i workloads scalino senza ritardi inutili.
• Riduce i costi infrastrutturali: un utilizzo ottimizzato di CPU, memoria, storage e rete riduce gli sprechi e aiuta a evitare l'overprovisioning.
• Previene la contesa di risorse: il tuning delle prestazioni contribuisce a evitare che i workloads competano eccessivamente per le risorse condivise, riducendo i colli di bottiglia e mantenendo un comportamento prevedibile.
• Migliora l'efficienza operativa: uno scheduling più veloce, un ripristino più rapido dai guasti e operazioni di cluster più fluide riducono il carico sui team di piattaforma e operations.
• Aiuta a rispettare i service level objective (SLO): monitorare e ottimizzare le prestazioni consente di mantenere gli obiettivi di disponibilità, tempi di risposta e affidabilità.
• Rafforza la stabilità del cluster: identificare e risolvere problemi come pressione sui nodi, riavvii eccessivi dei pod o ritardi del control plane aiuta a mantenere un ambiente Kubernetes sano e resiliente.

---

Problemi comuni di performance in Kubernetes

1. Request e limit delle risorse mal configurati

Request e limit delle risorse impostati in modo errato sono una causa frequente di problemi di performance negli ambienti Kubernetes. Se le request sono troppo alte, lo scheduler può lasciare i nodi sottoutilizzati, con conseguente spreco di risorse e costi infrastrutturali più elevati. Al contrario, request troppo basse possono spingere le applicazioni a competere per CPU e memoria, aumentando la probabilità di throttling ed errori out-of-memory (OOM). Questo squilibrio compromette la stabilità dei workloads e l'efficienza del cluster.

Anche i limit incidono sulle prestazioni. Quando sono impostati in modo troppo aggressivo, i pod possono essere terminati o soggetti a throttling, compromettendo la disponibilità del servizio. Senza limit, processi fuori controllo possono consumare tutte le risorse disponibili su un nodo, penalizzando i workloads adiacenti.

Come intervenire: Trovare il giusto equilibrio richiede un'analisi continua dei pattern di utilizzo e l'adeguamento di request e limit man mano che i workloads evolvono.

2. Throttling della CPU

Il throttling della CPU si verifica quando un container tenta di utilizzare più CPU del limite assegnato, spingendo Kubernetes a limitarne l'uso. Ciò può comportare tempi di risposta più lunghi, throughput applicativo degradato e prestazioni imprevedibili. Il throttling è particolarmente problematico per i workloads sensibili alla latenza, dove anche brevi rallentamenti possono incidere sull'esperienza utente o sull'affidabilità del servizio. Un throttling frequente deriva spesso da limit di CPU troppo bassi rispetto alle esigenze del workload.

Come intervenire: Monitorare l'utilizzo della CPU e le metriche di throttling aiuta a identificare i container interessati. La soluzione passa in genere dal right-sizing di request e limit della CPU e dalla verifica che le policy di autoscaling consentano di gestire workloads con picchi di carico senza introdurre throttling inutile.

3. Pressione sulla memoria ed eviction dei pod

La pressione sulla memoria si verifica quando un nodo esaurisce la memoria disponibile, costringendo lo scheduler di Kubernetes a effettuare l'eviction dei pod per liberare risorse. Ciò può compromettere la disponibilità delle applicazioni, soprattutto se vengono terminati servizi critici o se i pod rimossi impiegano molto tempo a riavviarsi. La pressione sulla memoria è spesso causata da sovra-allocazione, uso inefficiente della memoria da parte delle applicazioni o assenza di limit di memoria su determinati workloads. Le eviction dovute alla pressione sulla memoria possono innescare guasti a cascata se anche altri nodi sono vicini alla capacità massima o se i pod rimossi non possono essere schedulati altrove.

Come intervenire: Il monitoraggio continuo dell'uso della memoria dei nodi, la definizione di request e limit di memoria adeguati e l'ottimizzazione del consumo di memoria delle applicazioni aiutano a prevenire eviction frequenti e a mantenere la stabilità del cluster.

4. Autoscaling non ottimale

L'autoscaling è una funzionalità fondamentale di Kubernetes, ma una configurazione errata può portare a un provisioning insufficiente o eccessivo delle risorse. Se le soglie di scaling sono troppo conservative, i workloads potrebbero non scalare abbastanza rapidamente durante i picchi di domanda, causando colli di bottiglia. Uno scaling aggressivo può invece generare churn inutile dei pod, contesa di risorse e costi infrastrutturali più elevati.

Un autoscaling non ottimale deriva spesso da metriche imprecise o insufficienti alla base delle decisioni di scaling. Affidarsi solo a CPU o memoria può non riflettere la reale domanda del workload, specialmente per applicazioni sensibili a I/O o latenza.

Come intervenire: Il tuning delle impostazioni dell'autoscaler e l'utilizzo di metriche personalizzate che riflettano le prestazioni applicative sono necessari per uno scaling efficace e un comportamento coerente dei workloads.

5. Probe a cascata

Kubernetes utilizza probe di readiness e liveness per determinare lo stato di salute dei pod, ma probe mal progettate possono creare problemi di performance. Se le probe sono troppo frequenti, possono sovraccaricare l'applicazione di richieste, aumentando latenza e consumo di risorse. In alcuni casi, i fallimenti delle probe possono innescare riavvii inutili, con conseguente instabilità del servizio e tempi di ripristino più lunghi.

I fallimenti delle probe possono aggravare i problemi durante eventi di stress del cluster, come guasti dei nodi o rolling update. Se più pod falliscono contemporaneamente gli health check, si possono verificare riavvii di massa e un degrado delle prestazioni del cluster.

Come intervenire: Un tuning attento di intervalli, timeout e soglie delle probe è necessario per evitare questi effetti e garantire che le probe svolgano la loro funzione.

6. Colli di bottiglia dello storage

Le prestazioni dello storage sono un collo di bottiglia comune nei cluster Kubernetes, in particolare per i workloads stateful. Volumi persistenti lenti, alta latenza dei dischi o IOPS limitati possono portare a rallentamenti applicativi, tempi di avvio dei pod più lunghi e, nei casi peggiori, perdita di dati. I colli di bottiglia dello storage derivano spesso da backend di storage sottodimensionati o da pattern di accesso ai dati inefficienti.

Come intervenire: Monitorare le metriche di I/O dello storage e selezionare storage class adeguate è indispensabile per prevenire i colli di bottiglia. I workloads con requisiti di throughput elevato o bassa latenza dovrebbero utilizzare soluzioni di storage adatte alle loro esigenze. Rivedere le prestazioni dello storage, ottimizzare i pattern di accesso delle applicazioni e scalare le risorse di storage al crescere della domanda aiuta a mantenere la reattività del cluster e l'integrità dei dati.

---

Metriche di performance critiche di Kubernetes

Utilizzo della CPU

L'utilizzo della CPU è una metrica chiave delle performance di Kubernetes perché mostra quanta potenza di calcolo consumano workloads e nodi. Un utilizzo elevato può indicare un carico intenso, mentre un utilizzo costantemente basso può suggerire overprovisioning e allocazione inefficiente delle risorse. Analizzando i trend di utilizzo della CPU nel tempo, i team possono dimensionare correttamente i workloads, migliorare l'efficienza dello scheduling e configurare policy di autoscaling in grado di rispondere alla domanda.

Perché le metriche di CPU sono importanti:

• Monitorare l'utilizzo della CPU a livello di pod, container e nodo aiuta a stabilire se i workloads dispongono di capacità di calcolo sufficiente per operare in modo affidabile.
• Le metriche di CPU sono importanti anche per identificare il throttling e mettere a punto request e limit delle risorse.
• Se i container raggiungono spesso i propri limit di CPU, i tempi di risposta delle applicazioni possono aumentare e il throughput diminuire.

Utilizzo della memoria

L'utilizzo della memoria misura quanta RAM viene consumata da container, pod e nodi all'interno di un cluster Kubernetes. Poiché la memoria è una risorsa non comprimibile, un utilizzo eccessivo può causare instabilità, inclusi errori out-of-memory ed eviction dei pod.

Perché le metriche di memoria sono importanti:

• Monitorare l'utilizzo della memoria aiuta a identificare workloads con memory leak, consumi superiori al previsto o troppo vicini ai limit configurati.
• Tenere traccia dell'uso della memoria è fondamentale per impostare request e limit accurati. Se le request di memoria sono troppo basse, i pod possono finire su nodi che non riescono a sostenerli nei picchi di domanda.
• Se i limit sono troppo restrittivi, le applicazioni possono essere terminate in modo imprevisto.

Riavvii dei pod

I riavvii dei pod indicano con quale frequenza i container all'interno dei pod si riavviano, un possibile segnale di problemi applicativi o infrastrutturali. Riavvii frequenti possono derivare da crash delle applicazioni, health check falliti, superamento dei limit di memoria, errori di configurazione o guasti delle dipendenze. Un numero elevato di riavvii può ridurre la disponibilità e indicare problemi di affidabilità del workload.

Perché i riavvii dei pod sono importanti:

• Monitorare i riavvii dei pod aiuta i team a individuare applicazioni instabili prima che causino interruzioni del servizio.
• I pattern di riavvio andrebbero analizzati insieme a log, utilizzo delle risorse e risultati delle probe per determinare la causa principale.
• Ridurre i riavvii non necessari migliora l'affidabilità delle applicazioni, accorcia i tempi di ripristino e favorisce prestazioni Kubernetes prevedibili.

Stato e disponibilità dei pod

Le metriche di stato e disponibilità dei pod mostrano se i workloads funzionano come previsto e se il numero desiderato di pod è disponibile per servire il traffico. Gli stati importanti includono Running, Pending, Failed, CrashLoopBackOff e ImagePullBackOff. Pod bloccati in stati diversi da Running possono indicare problemi di scheduling, problemi con le immagini, carenza di risorse o errori di configurazione.

Perché le metriche dei pod sono importanti:

• Le metriche di disponibilità sono importanti per i workloads di produzione perché indicano se le applicazioni possono soddisfare la domanda degli utenti.
• Monitorare i pod ready e disponibili aiuta a rilevare degrado del servizio, rollout falliti e problemi di capacità.
• Mantenere un'elevata disponibilità dei pod garantisce che le applicazioni restino reattive durante eventi di scaling, deployment e guasti dei nodi.

Metriche di pressione dei nodi

Le metriche di pressione dei nodi indicano se un nodo Kubernetes è sotto stress di risorse. Le condizioni di pressione più comuni includono memory pressure, disk pressure e PID pressure. Quando un nodo entra in stato di pressione, Kubernetes può effettuare l'eviction dei pod o impedire la schedulazione di nuovi pod su quel nodo, con conseguenze sulla disponibilità delle applicazioni e sulla stabilità del cluster.

Perché le metriche dei nodi sono importanti:

• Monitorare la pressione dei nodi aiuta a individuare i colli di bottiglia infrastrutturali prima che causino disservizi.
• Queste metriche vanno analizzate insieme ai dati su CPU, memoria, disco e densità dei pod per capire perché un nodo è sotto stress.
• Gestire la pressione dei nodi con capacity planning, ridistribuzione dei workloads e tuning delle risorse aiuta a mantenere un cluster stabile.

I/O di disco e storage

Le metriche di I/O di disco e storage misurano l'efficienza con cui i workloads Kubernetes leggono e scrivono sui sistemi di storage. Includono throughput del disco, IOPS, latenza e utilizzo dei volumi. Prestazioni di storage scadenti possono rallentare i tempi di risposta delle applicazioni, ritardare l'avvio dei pod e penalizzare i workloads stateful come database, code di messaggi e sistemi di analytics.

Perché le metriche di I/O sono importanti:

• Monitorare l'I/O dello storage è indispensabile per rilevare colli di bottiglia nei volumi persistenti, nelle storage class e nell'infrastruttura sottostante.
• Latenza elevata o IOPS saturi possono indicare che un workload necessita di storage più veloce, pattern di accesso ai dati migliori o capacità aggiuntiva.
• Prestazioni di storage solide contribuiscono a mantenere le applicazioni reattive e i servizi stateful affidabili.

Performance dello scheduler

La performance dello scheduler misura la rapidità e l'efficacia con cui lo scheduler di Kubernetes assegna i pod ai nodi. Gli indicatori chiave includono la latenza di scheduling dei pod, il numero di pod in stato Pending e i fallimenti di scheduling. Uno scheduling lento può ritardare l'avvio delle applicazioni, ridurre la reattività dello scaling e creare problemi di disponibilità del servizio durante picchi di traffico o eventi di ripristino.

Perché le metriche dello scheduler sono importanti:

• Monitorare la performance dello scheduler aiuta a individuare problemi come capacità del cluster insufficiente, regole di affinity restrittive, taints e tolerations, o request di risorse impossibili da soddisfare.
• Uno scheduling efficiente garantisce che i workloads vengano collocati rapidamente sui nodi giusti e che le risorse del cluster siano utilizzate in modo efficace.
• Questo è particolarmente importante in ambienti grandi o dinamici in cui i pod vengono creati, aggiornati o rischedulati di frequente.

Metriche di autoscaling

Le metriche di autoscaling mostrano l'efficacia con cui Kubernetes adegua la capacità di workloads e cluster in base alla domanda. Possono includere l'attività dell'horizontal pod autoscaler, il confronto tra repliche attuali e desiderate, l'utilizzo di CPU o memoria, metriche applicative personalizzate e il comportamento del cluster autoscaler. Un autoscaling corretto aiuta le applicazioni a gestire i picchi di domanda senza interventi manuali.

Perché le metriche di autoscaling sono importanti:

• Monitorare queste metriche aiuta i team a capire se le policy di scaling sono troppo lente, troppo aggressive o basate su segnali incompleti.
• Se l'autoscaling non risponde con sufficiente rapidità, gli utenti possono riscontrare latenza o errori. Se scala in modo troppo aggressivo, costi e churn dei pod possono aumentare.
• Un autoscaling ben calibrato supporta prestazioni affidabili e un uso efficiente delle risorse.

Metriche applicative

Le metriche applicative offrono una visione specifica per workload di come i servizi si comportano dal punto di vista del business e degli utenti. Possono includere latenza delle richieste, tassi di errore, throughput, profondità delle code, volume delle transazioni e indicatori di salute specifici del servizio. Mentre le metriche infrastrutturali mostrano come vengono utilizzate le risorse Kubernetes, le metriche applicative rivelano se l'applicazione soddisfa le aspettative di performance.

Perché le metriche applicative sono importanti:

• Monitorare queste metriche collega la performance di Kubernetes all'esperienza utente e ai service level objective. Ad esempio, l'utilizzo di CPU e memoria può apparire normale mentre la latenza delle richieste o i tassi di errore stanno aumentando.
• Combinando le metriche applicative con quelle infrastrutturali di Kubernetes, i team possono diagnosticare i problemi con maggiore precisione e dare priorità alle ottimizzazioni che migliorano la qualità del servizio.

Metriche del control plane

Le metriche del control plane misurano lo stato di salute e la reattività dei componenti Kubernetes responsabili della gestione del cluster: API server, scheduler, controller manager ed etcd. Le metriche importanti includono latenza dell'API server, frequenza delle richieste, prestazioni di etcd, profondità delle code dei controller e tassi di errore del control plane.

Perché le metriche del control plane sono importanti:

• Un control plane poco performante può ripercuotersi sull'intero cluster, causando ritardi in scheduling, scaling, deployment e ripristino dai guasti.
• Monitorare le metriche del control plane aiuta a rilevare problemi come saturazione delle API, scritture lente su etcd o arretrati nei controller.
• Mantenere un control plane in salute garantisce che Kubernetes possa rispondere rapidamente alle variazioni dei workloads e mantenere il cluster affidabile.

---