Workloads Kubernetes: i 6 tipi, il ciclo di vita e le best practice

Il monitoraggio dei workloads Kubernetes

Il monitoraggio dei workloads Kubernetes non dovrebbe limitarsi a mostrare se i Pod sono in esecuzione. L'obiettivo è identificare problemi di capacità, instabilità applicativa, colli di bottiglia nello scheduling e allocazioni inefficienti delle risorse, per poi usare questi risultati per mettere a punto le impostazioni delle risorse, le policy di autoscaling e la configurazione dei workloads.

Utilizzo di CPU e memoria

Le metriche di CPU e memoria aiutano a stabilire se i workloads dispongono di risorse sufficienti per funzionare in modo affidabile senza riservare più capacità del cluster di quanta ne serva.

Metriche da monitorare

• Utilizzo CPU: CPU effettivamente consumata da ogni container e Pod.
• Request di CPU: CPU riservata ai fini dello scheduling.
• Limit di CPU: CPU massima utilizzabile da un container, quando i limit sono configurati.
• Throttling della CPU: tempo in cui a un container viene impedito di usare CPU aggiuntiva perché ha raggiunto il proprio limit di CPU.
• Utilizzo memoria e working set: memoria attivamente consumata dal workload.
• Request e limit di memoria: memoria riservata e memoria massima consentita per il container.
• Tendenze di utilizzo: pattern di utilizzo storici, inclusi picchi, utilizzo prolungato e crescita graduale della memoria.

Confrontare l'utilizzo effettivo con le request è particolarmente utile, perché le request influenzano sia lo scheduling dei Pod sia il comportamento dell'Horizontal Pod Autoscaler quando si usano metriche di utilizzo delle risorse.

Suggerimenti per l'ottimizzazione

Usare i dati di utilizzo per fare right-sizing delle request anziché affidarsi solo alle stime iniziali. I workloads costantemente sottoutilizzati possono avere request inutilmente elevate, mentre quelli che si avvicinano regolarmente alle risorse disponibili possono richiedere più capacità.

Valutare azioni come:

• Adeguare le request di CPU e memoria per riflettere meglio la domanda osservata.
• Indagare il throttling prolungato della CPU prima di limitarsi ad aumentare i limit.
• Aumentare i limit di memoria quando una domanda legittima del workload supera le impostazioni attuali.
• Indagare la crescita costante della memoria per individuare possibili memory leak.
• Usare HPA, VPA o altri meccanismi di autoscaling quando i requisiti di risorse cambiano significativamente con la domanda.
• Esaminare percentili di lungo periodo e periodi di picco anziché ottimizzare su un singolo snapshot.

Riavvii e failure dei Pod

Le metriche di riavvio e failure rivelano instabilità dei workloads che potrebbero non essere evidenti dalla fase attuale del Pod. Un Pod può risultare Running mentre uno dei suoi container va ripetutamente in crash e si riavvia.

Metriche e segnali da monitorare

• Numero e frequenza dei riavvii dei container
• Motivo della terminazione del container
• Exit code
• Stato attuale e precedente dei container
• Startup, readiness e liveness probe fallite
• Eventi CrashLoopBackOff
• Errori di image pull e di configurazione
• Log applicativi prima e dopo un riavvio

Monitorare la frequenza dei riavvii nel tempo è in genere più utile che reagire a un riavvio isolato. Aumenti improvvisi o loop di riavvio persistenti sono indicatori più forti di un problema sottostante.

Suggerimenti per il troubleshooting e l'ottimizzazione

La risposta appropriata dipende dal motivo per cui il container si è riavviato. Iniziare dal motivo di terminazione, dallo stato precedente del container, dagli eventi Kubernetes e dai log applicativi.

Tra le azioni comuni:

• Correggere crash applicativi o eccezioni non gestite.
• Adeguare le probe troppo aggressive rispetto ai tempi di avvio o di risposta dell'applicazione.
• Correggere Secret, ConfigMap, volumi o variabili d'ambiente mancanti.
• Aumentare la memoria quando i riavvii sono causati da condizioni OOM.
• Indagare servizi a valle non disponibili quando i failure coincidono con errori di dipendenze.
• Rivedere i deployment recenti quando la frequenza dei riavvii aumenta subito dopo un rollout.

Evitare di trattare i riavvii solo come un problema di capacità. Aumentare le risorse non risolverà failure causati da bug applicativi, configurazioni non valide o health probe configurate in modo errato.

Pod Pending e non schedulabili

I Pod in stato Pending possono indicare che la domanda dei workloads ha superato la capacità disponibile del cluster o che i vincoli di scheduling impediscono a Kubernetes di trovare un nodo idoneo.

Metriche e segnali da monitorare

• Numero di Pod Pending
• Tempo in cui i Pod rimangono Pending
• Numero di Pod non schedulabili
• Eventi dello scheduler e motivi di rifiuto
• CPU, memoria, GPU e altre risorse richieste
• Capacità disponibile sui nodi idonei
• Requisiti di node affinity e selector
• Taint e toleration
• Topology spread constraint
• Condizioni di scheduling e attach dei PersistentVolume

L'età dei Pod Pending è particolarmente utile. Brevi ritardi di scheduling possono essere normali, mentre i Pod che restano non schedulabili per periodi prolungati richiedono di solito un intervento.

Suggerimenti per risolvere i colli di bottiglia nello scheduling

Identificare innanzitutto se il problema è causato da capacità insufficiente o da regole di scheduling eccessivamente restrittive.

Tra le azioni possibili:

• Fare right-sizing delle request quando i Pod richiedono una capacità sostanzialmente superiore a quella realmente necessaria.
• Correggere node selector, regole di affinity o toleration che limitano inutilmente il posizionamento.
• Rivedere i requisiti di topology spread quando Kubernetes non trova abbastanza nodi idonei.
• Garantire che i workloads GPU o altri workloads specializzati abbiano accesso a nodi compatibili.
• Aggiungere capacità al cluster quando una domanda legittima dei workloads supera le risorse disponibili.
• Configurare l'autoscaling dei nodi in modo che la nuova capacità possa essere fornita automaticamente.

Negli ambienti scalati dinamicamente, Pod Pending persistenti dovrebbero inoltre innescare una revisione del livello di provisioning dei nodi. Ad esempio, Karpenter può effettuare il provisioning di nodi in base ai requisiti dei Pod non schedulabili, ma i vincoli dei suoi NodePool devono comunque consentire la creazione di capacità di istanze adeguata.

Container OOMKilled

OOMKilled indica che un container è stato terminato dalla gestione out-of-memory del sistema operativo. Una causa comune è un container che tenta di consumare più memoria di quanta ne consenta il limit configurato.

Metriche e segnali da monitorare

• Motivo di terminazione del container: OOMKilled
• Exit code 137
• Working set della memoria
• Request e limit di memoria
• Consumo di memoria di picco
• Utilizzo della memoria immediatamente prima della terminazione
• Frequenza dei riavvii dopo eventi OOM
• Crescita della memoria a lungo termine

Le metriche storiche sono particolarmente preziose perché le metriche correnti dei container vengono azzerate dopo un riavvio del container.

Suggerimenti per prevenire gli OOM kill

Iniziare stabilendo se l'utilizzo di memoria rappresenta una domanda applicativa legittima o un comportamento anomalo.

Tra le ottimizzazioni possibili:

• Aumentare i limit di memoria quando workloads normali richiedono legittimamente più capacità.
• Alzare le request di memoria quando i Pod consumano costantemente molta più memoria di quanta ne richiedano.
• Indagare memory leak applicativi quando l'utilizzo cresce continuamente nel tempo.
• Limitare la concorrenza o le dimensioni dei batch quando singole richieste causano grandi picchi di memoria.
• Rivedere cache, impostazioni dell'heap JVM e configurazione della memoria a livello applicativo.
• Usare i dati di utilizzo storici per stabilire impostazioni delle risorse realistiche.
• Valutare l'autoscaling verticale quando i requisiti di memoria cambiano sostanzialmente nel tempo.

Aumentare ripetutamente i limit di memoria senza identificarne la causa può nascondere problemi applicativi e far crescere i costi infrastrutturali. Le modifiche alle risorse dovrebbero quindi basarsi sul comportamento del workload e sull'utilizzo storico, non solo sugli eventi OOM.

Best practice per la gestione dei workloads Kubernetes

Definire request e limit delle risorse accurati

Impostare le request di CPU e memoria in base a requisiti realistici dei workloads. Lo scheduler usa le request per decidere dove posizionare i pod, quindi valori troppo alti possono sprecare capacità del cluster o lasciare i pod in attesa. Request troppo basse possono portare a nodi sovraccarichi.

Usare i limit dove offrono una protezione utile contro il consumo eccessivo di risorse. I limit di CPU possono causare throttling, mentre il superamento di un limit di memoria può portare a un container OOMKilled. Testare le impostazioni dei limit sotto un carico rappresentativo anziché scegliere valori arbitrari.

Fare right-sizing continuo dei workloads

I requisiti di risorse cambiano con l'evolvere di codice applicativo, traffico e pattern di utilizzo. Esaminare regolarmente il consumo effettivo di CPU e memoria e confrontarlo con request e limit configurati.

Per il right-sizing dei workloads, usare metriche storiche anziché brevi snapshot. Tenere conto dell'utilizzo normale, dei picchi di domanda, dei requisiti di avvio e della crescita prevista. Questo aiuta a ridurre la capacità inutilizzata senza rendere le applicazioni vulnerabili a picchi prevedibili.

Usare il controller di workload appropriato

Scegliere il controller in base a come l'applicazione deve essere eseguita. Usare i Deployment per applicazioni stateless in esecuzione continua e gli StatefulSet quando le repliche richiedono identità stabili, operazioni ordinate o storage persistente.

I DaemonSet sono adatti al software che deve essere eseguito su nodi selezionati, come agent di monitoraggio o di rete. Usare i Job per le attività finite e i CronJob per le esecuzioni pianificate. Scegliere il controller corretto fornisce il comportamento del ciclo di vita senza richiedere logiche di gestione personalizzate.

Configurare le probe di readiness, liveness e startup

Usare le readiness probe per determinare quando un pod può ricevere traffico in sicurezza. Una readiness probe fallita rimuove il pod dagli endpoint Service ordinari senza riavviarne il container, il che la rende adatta a condizioni temporanee come failure delle dipendenze o fasi di inizializzazione.

Usare le liveness probe per rilevare applicazioni che non possono riprendersi senza un riavvio. Le startup probe sono utili per applicazioni con tempi di inizializzazione lunghi o imprevedibili, perché impediscono ai controlli di liveness di riavviare l'applicazione prima del completamento dell'avvio.

Configurare con cura percorsi, soglie, intervalli e timeout delle probe. Probe troppo aggressive possono creare failure riavviando applicazioni sane ma temporaneamente lente.

Usare i Pod Disruption Budget per le applicazioni critiche

Un PodDisruptionBudget limita quante repliche di un'applicazione possono risultare non disponibili durante le interruzioni volontarie. Queste interruzioni possono verificarsi durante operazioni come il drain dei nodi, la manutenzione del cluster o alcune attività di autoscaling.

Configurare un budget usando minAvailable o maxUnavailable in base ai requisiti di ridondanza dell'applicazione. Un budget non previene ogni tipo di guasto, come un'interruzione imprevista di un nodo, e non può garantire disponibilità quando un'applicazione ha un numero troppo basso di repliche.

Evitare budget che rendano impossibile la manutenzione ordinaria. Il workload ha bisogno di abbastanza repliche sane perché Kubernetes possa rispettare il budget durante l'eviction sicura dei pod.

Distribuire le repliche tra nodi e zone di disponibilità

Più repliche offrono una protezione limitata se vengono tutte eseguite sullo stesso nodo o nello stesso dominio di guasto. Usare pod anti-affinity o topology spread constraint per distribuire le repliche tra nodi, zone o altri confini topologici.

La distribuzione riduce l'impatto dei guasti di nodi e zone di disponibilità. Può inoltre evitare che la manutenzione su un singolo nodo rimuova in una sola volta troppa capacità applicativa.

Bilanciare i requisiti di resilienza con la flessibilità dello scheduling. Regole di posizionamento rigide possono lasciare i pod in attesa quando il cluster non dispone di abbastanza nodi adatti nella topologia richiesta.

Combinare l'autoscaling dei workloads e del cluster

L'autoscaling dei workloads e quello del cluster risolvono problemi di capacità diversi. L'HorizontalPodAutoscaler può aumentare o diminuire le repliche applicative in base alle metriche, mentre l'autoscaling a livello di nodo può adeguare la capacità del cluster quando i pod non possono essere schedulati con le risorse esistenti.

Questi meccanismi vanno configurati insieme. Scalare un Deployment serve a poco se le nuove repliche restano in attesa perché il cluster non ha capacità. Allo stesso modo, aggiungere nodi non aumenta automaticamente le repliche applicative quando la domanda cresce.

Request accurate sono importanti per entrambi i meccanismi, perché influenzano le decisioni di scheduling e di capacità. Impostare intervalli di scaling ragionevoli e monitorare il comportamento dello scaling per evitare modifiche eccessive, risposte lente alla domanda o utilizzo inutile dell'infrastruttura.

FAQ

Che cos'è un workload Kubernetes? Un workload Kubernetes è un'applicazione, un servizio o un'attività in esecuzione su un cluster. I workloads vengono eseguiti all'interno dei Pod, ma di norma sono gestiti tramite risorse di livello superiore che indicano a Kubernetes come creare, sostituire, scalare, aggiornare e terminare quei Pod.

Quali sono i principali tipi di workloads Kubernetes? Le risorse workload integrate principali sono Deployment, StatefulSet, DaemonSet, Job, CronJob e ReplicaSet. Ognuna risponde a un'esigenza diversa, come servizi stateless, applicazioni stateful, agent a livello di nodo, attività una tantum e attività pianificate.

Qual è la differenza tra un Deployment e uno StatefulSet? Un Deployment gestisce applicazioni stateless le cui repliche di Pod sono intercambiabili. Uno StatefulSet è pensato per applicazioni i cui Pod necessitano di nomi stabili, ordinamento prevedibile o storage persistente dedicato, come i database.

Qual è la differenza tra un Job e un CronJob? Un Job esegue uno o più Pod fino al completamento riuscito di un'attività, come una migrazione di database. Un CronJob crea Job secondo una pianificazione ricorrente scritta in sintassi cron, adatta ad attività come backup e generazione di report.

Qual è la differenza tra un workload Kubernetes e la Workload API? Un workload è la risorsa gestita, come un Deployment o un Job. La workload API è l'interfaccia API di Kubernetes che strumenti, controller e applicazioni usano per creare, leggere, aggiornare, eliminare e scalare quelle risorse.

Perché il mio Pod è bloccato in Pending? I Pod in Pending di solito indicano che il cluster non ha capacità o che le regole di scheduling impediscono a Kubernetes di trovare un nodo idoneo. Controllare gli eventi dello scheduler, quindi esaminare request delle risorse, node selector, regole di affinity, toleration e topology spread constraint. L'autoscaling dei nodi può aggiungere capacità quando la domanda è legittima.

Come ottimizzare i workloads Kubernetes con PerfectScale

PerfectScale by DoiT è una piattaforma per ottimizzare le risorse in ogni cluster Kubernetes. Dopo un unico deployment via Helm, offre insight concreti e attuabili e ottimizzazione autonoma su tutto lo stack K8s, dai singoli workloads ai nodi sottostanti. Funziona con autoscaler come HPA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning e Google Autopilot. Supporta cloud pubblici come EKS, GKE e AKS, cloud privati come OpenShift e ambienti on-premises e ibridi.

Funzionalità chiave di PerfectScale:

• Right-sizing autonomo dei workloads: Podfit offre una vista granulare di salute e costi del cluster, identifica risorse sprecate e problemi di resilienza e fornisce raccomandazioni data-driven per il right-sizing dei workloads. È inoltre possibile configurare l'automazione per un'ottimizzazione immediata.
• Raccomandazioni di configurazione per l'autoscaling: raccomandazioni concrete per migliorare le configurazioni di HPA e KEDA, in modo che i workloads scalino in modo efficiente con la domanda.
• Ottimizzazione dei workloads effimeri e ML: right-sizing autonomo dei workloads effimeri come Airflow e i Job Spark, per mantenere ottimizzati anche gli ambienti dinamici.
• Automazione consapevole delle revisioni: PerfectScale valuta ogni nuova release di codice e si adatta ai requisiti mutevoli dei workloads, così le sue ottimizzazioni non contraddicono mai le modifiche di sviluppo.
• Ottimizzazione a livello di nodo: Infrafit offre visibilità sull'utilizzo dei nodi per aiutare a eliminare la capacità inattiva, selezionare i nodi giusti per i workloads e massimizzare l'efficacia di autoscaler di nodi come Karpenter.
• Avvisi in tempo reale con priorità: affrontare rischi di resilienza e picchi di costo con una prioritizzazione basata sull'impatto e ricevere avvisi in Slack, Datadog, MS Teams, PagerDuty e altri strumenti.
• Report su tendenze e governance: monitorare nel tempo le metriche di costo, spreco e rischio su cluster, gruppi di nodi, namespace e workloads per migliorare previsioni e analisi delle root cause.

Scopra come PerfectScale ottimizza continuamente prestazioni e costi dei workloads Kubernetes