Errori di Scheduling in Kubernetes: Soluzioni e Best Practice

Gli errori di scheduling in Kubernetes di solito si manifestano con un pod bloccato in Pending. Questo stato può sembrare vago, ma ha un significato specifico: Kubernetes ha accettato l'oggetto pod, ma lo scheduler non ha trovato un nodo che soddisfi i requisiti del pod. Il container non è crashato. L'applicazione non è stata avviata. In molti casi, l'immagine non è stata nemmeno scaricata.

Il modo più veloce per risolvere questi problemi è confrontare ciò che il pod richiede con ciò che il cluster può offrire. Le richieste di CPU e memoria, le etichette dei nodi, le regole di affinità, i taint, le toleration, i volumi persistenti, le regole di distribuzione topologica e le quote dei namespace possono tutti bloccare il posizionamento. Lo scheduler è rigoroso riguardo ai vincoli obbligatori. Se una regola obbligatoria esclude tutti i nodi, il pod rimane in attesa.

Diagnosi dei Pod in Pending: Il Primo Passo

Prima di tentare correzioni, è necessario diagnosticare con precisione perché lo Scheduler sta fallendo. Lo strumento principale per questa indagine è kubectl describe pod.

Quando un Pod è bloccato in Pending, la sezione Events dell'output del comando contiene informazioni critiche che dettagliano il processo decisionale dello scheduling e eventuali rifiuti.

Utilizzo di `kubectl describe pod`

Individua sempre il Pod problematico:

kubectl describe pod <nome-pod> -n <namespace>

Esamina l'output, concentrandoti sulla sezione Events in fondo. I messaggi qui di solito indicano il vincolo che ha impedito lo scheduling. I messaggi comuni riguardano Insufficient cpu, Insufficient memory, mancata corrispondenza del selettore del nodo, taint non tollerati o binding del volume.

Categorie Comuni di Errori di Scheduling e Soluzioni

I fallimenti di scheduling rientrano generalmente in tre categorie principali: Vincoli di Risorsa, Vincoli di Policy (Affinità/Anti-Affinità) e Configurazione del Nodo (Taint/Toleration).

1. Vincoli di Risorsa (Risorse Insufficienti)

Questa è la causa più frequente. Lo Scheduler richiede un Nodo che possa soddisfare le richieste definite nella specifica del Pod. Se nessun nodo ha abbastanza CPU o Memoria allocabile disponibile, il Pod rimarrà in Pending.

Identificazione del Problema

La sezione Events mostrerà messaggi come:

0/3 nodes are available: 3 Insufficient cpu.
0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match node selector.

Questi messaggi possono essere combinati. Non fermarti alla prima frase. Se tre nodi falliscono per tre motivi diversi, risolvere solo un motivo potrebbe comunque lasciare il pod in sospeso.

Soluzioni per la Carenza di Risorse

Riduci le Richieste del Pod: Se le richieste del Pod sono eccessivamente alte, prova a ridurre le requests di CPU o Memoria nel file YAML del Pod o del Deployment.
Aumenta la Capacità del Cluster: Aggiungi più Nodi al cluster Kubernetes.
Pulisci i Carichi di Lavoro Esistenti: Ridimensiona i carichi di lavoro non essenziali, rimuovi job abbandonati o regola le richieste sovradimensionate sui deployment esistenti. Usa kubectl drain per la manutenzione dei nodi, non come comando di pulizia occasionale.
Usa Limit Ranges: Se il tuo namespace manca di limiti di risorse definiti, implementa oggetti LimitRange per impedire a singoli Pod di accumulare risorse.

2. Selettori di Nodo e Regole di Affinità/Anti-Affinità

Kubernetes consente un controllo granulare su dove i Pod possono o devono essere posizionati utilizzando nodeSelector, nodeAffinity e podAffinity/podAntiAffinity.

Mancata Corrispondenza del Selettore di Nodo

Se definisci un nodeSelector che non corrisponde a nessuna etichetta presente su nessun Nodo disponibile, il Pod non può essere schedulato.

Esempio di Frammento YAML (Causa di Fallimento):

spec:
  nodeSelector:
    disktype: ssd-fast
  containers: [...] # Il Pod rimane in Pending se nessun nodo ha disktype=ssd-fast

Soluzione: Assicurati che l'etichetta specificata in nodeSelector esista su almeno un Nodo (kubectl get nodes --show-labels) e che la corrispondenza sia esatta.

Usa controlli mirati delle etichette quando il cluster ha molte etichette:

kubectl get nodes -L disktype,topology.kubernetes.io/zone
kubectl describe node <nome-nodo>

Un errore comune è usare un'etichetta che esisteva in un gruppo di nodi precedente ma non nel gruppo di nodi sostitutivo. Dopo un aggiornamento del cluster o una migrazione del gruppo di auto-scaling, vecchie regole di posizionamento possono diventare silenziosamente impossibili.

Vincoli di Affinità del Nodo

nodeAffinity offre regole più flessibili (ad esempio, requiredDuringSchedulingIgnoredDuringExecution o preferredDuringSchedulingIgnoredDuringExecution). Se una regola required non può essere soddisfatta, il Pod rimane in Pending.

Suggerimento Diagnostico: Quando si utilizzano regole di affinità complesse, la sezione Events spesso indica: node(s) didn't match node selector.

Affinità e Anti-Affinità del Pod

Queste regole controllano il posizionamento rispetto ad altri Pod. Se, ad esempio, una regola di Anti-Affinità richiede che un Pod non venga eseguito su un Nodo che ospita un servizio specifico, ma tutti i nodi ospitano già quel servizio, lo scheduling fallirà.

Soluzione: Rivedi attentamente la chiave topologica e il selettore nelle tue regole di affinità. Se una regola di anti-affinità è troppo restrittiva, rilassa il requisito o verifica che i Pod target selezionati dalla regola siano effettivamente in esecuzione sui nodi che vuoi evitare.

Preferisci preferredDuringSchedulingIgnoredDuringExecution quando la regola esprime una preferenza piuttosto che un requisito rigido. L'anti-affinità obbligatoria è utile per distribuire repliche di servizi critici, ma può bloccare i deployment in cluster piccoli. Ad esempio, tre repliche con anti-affinità rigorosa uno-per-zona non possono essere schedulare correttamente in un cluster con solo due zone utilizzabili.

3. Taint e Toleration

I Taint vengono applicati direttamente ai Nodi per respingere i Pod, mentre le Toleration vengono aggiunte alle specifiche dei Pod per consentire loro di essere eseguiti su nodi tainted.

Taint: Respinge i Pod a meno che non abbiano una toleration corrispondente.
Toleration: Permette a un Pod di essere schedulato su un nodo con un taint corrispondente.

Identificazione del Rifiuto per Taint

Gli Events indicheranno esplicitamente il motivo del rifiuto:

0/3 nodes are available: 2 node(s) had taint {dedicated: special-workload, effect: NoSchedule}, that the pod didn't tolerate.

Soluzioni per Taint e Toleration

Hai due percorsi principali:

Modifica il Pod (Consigliato per Pod Applicativi): Aggiungi le tolerations richieste alla specifica del Pod che corrispondono al taint del nodo.

Esempio di Toleration:
```
spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "special-workload"
    effect: "NoSchedule"
  containers: [...] 
```
Modifica il Nodo (Consigliato per Amministratori di Cluster): Rimuovi il taint dal Nodo se la restrizione non è più necessaria.
```
# Per rimuovere un taint
kubectl taint nodes <nome-nodo> dedicated:special-workload:NoSchedule-
```

Avviso di Best Practice: Evita di tollerare il taint globale node-role.kubernetes.io/master:NoSchedule sui Pod applicativi a meno che tu non stia intenzionalmente schedulando componenti critici del piano di controllo sui nodi master.

Sui cluster più recenti, i nodi del piano di controllo usano comunemente il taint node-role.kubernetes.io/control-plane invece di, o insieme a, la vecchia terminologia master. Controlla i taint effettivi prima di copiare una toleration da un vecchio manifest:

kubectl describe node <nome-nodo> | grep -i taints

Vincoli di Scheduling Avanzati

Vincoli meno comuni, ma importanti, possono anche bloccare lo scheduling:

Vincoli di Storage del Volume

Se un Pod richiede un PersistentVolumeClaim (PVC) che non può essere attualmente associato a un Nodo disponibile (ad esempio, a causa di requisiti specifici del fornitore di storage o dell'indisponibilità del volume), il Pod potrebbe rimanere in Pending.

Diagnostica: Controlla prima lo stato del PVC (kubectl describe pvc <nome-pvc>). Se il PVC è bloccato in Pending, lo scheduling del Pod viene interrotto fino a quando il volume non è disponibile.

Lo storage può anche essere ritardato intenzionalmente da volumeBindingMode: WaitForFirstConsumer sulla StorageClass. In quella modalità, il binding attende che lo scheduler scelga un nodo adatto, perché il volume potrebbe dover essere creato nella stessa zona del pod. Questo è normale, ma se nessun nodo soddisfa contemporaneamente i vincoli del pod e dello storage, il pod rimane in sospeso.

DaemonSet e Distribuzioni Topologiche

I DaemonSet vengono schedulati solo sui nodi che corrispondono ai loro criteri di selezione (se presenti). Se un cluster è partizionato o un nuovo nodo non corrisponde al selettore del DaemonSet, non verrà eseguito.

Vincoli di Distribuzione Topologica (se definiti) garantiscono una distribuzione uniforme. Se la distribuzione corrente impedisce il posizionamento su qualsiasi nodo rispettando i vincoli di distribuzione, lo scheduling fallirà.

I fallimenti di distribuzione topologica spesso si verificano dopo un'interruzione parziale. Supponiamo che una zona non sia disponibile e un deployment abbia rigidi vincoli di distribuzione tra le zone. Kubernetes potrebbe rifiutarsi di posizionare nuove repliche nelle zone rimanenti perché ciò violerebbe la regola di skew. Questo comportamento protegge gli obiettivi di distribuzione, ma durante un'interruzione potrebbe essere necessario rilassare temporaneamente il vincolo per ripristinare la capacità.

Quote del Namespace e LimitRange

Un pod può anche essere bloccato dalla policy del namespace. ResourceQuota controlla l'utilizzo aggregato in un namespace. LimitRange può impostare valori predefiniti o minimi e massimi per le risorse.

Controllali quando la specifica del pod sembra ragionevole ma la creazione o lo scheduling falliscono ancora:

kubectl get resourcequota -n <namespace>
kubectl describe resourcequota -n <namespace>
kubectl get limitrange -n <namespace>
kubectl describe limitrange -n <namespace>

I problemi di quota sono comuni nei cluster di sviluppo condivisi. Un team potrebbe avere abbastanza capacità fisica del cluster, ma la sua quota del namespace è esaurita da vecchi ambienti di anteprima o job completati che non sono mai stati puliti.

Una Sequenza di Debug Realistica

Quando un pod è in sospeso, usa questo ordine:

Esegui kubectl describe pod e copia l'evento di scheduling più recente.
Controlla la CPU e la memoria richieste rispetto alla capacità allocabile del nodo con kubectl describe node.
Controlla le etichette dei nodi se il pod usa nodeSelector, node affinity o chiavi topologiche.
Controlla i taint sui nodi candidati e le toleration sul pod.
Controlla PVC e StorageClass se il pod monta storage persistente.
Controlla le quote del namespace e i LimitRange.
Se ci si aspetta che Cluster Autoscaler aiuti, ispeziona i suoi log o eventi.

Questo ordine è importante perché un pod in sospeso non è un problema di runtime dell'applicazione. Riavviare il deployment raramente aiuta a meno che il vincolo sottostante non sia cambiato.

Best Practice per uno Scheduling di Successo

Per ridurre al minimo i problemi di scheduling, adotta queste best practice operative:

Definisci Esplicitamente le Richieste di Risorsa: Imposta sempre requests (e limits opzionali) ragionevoli per CPU e memoria. Questo permette allo scheduler di valutare accuratamente la capacità del nodo.
Usa Etichette dei Nodi per la Zonizzazione: Implementa un'etichettatura coerente dei nodi (ad esempio, hardware=gpu, zone=us-east-1a) e usa nodeSelector o nodeAffinity per indirizzare i carichi di lavoro all'hardware appropriato.
Documenta Taint e Toleration: Se i nodi sono tainted per manutenzione o segregazione hardware, documenta questi taint centralmente. Assicurati che i manifest delle applicazioni che richiedono l'accesso a risorse tainted includano le corrispondenti toleration.
Monitora Cluster Autoscaler (se usato): Se ti affidi a soluzioni di scaling, assicurati che siano funzionali. Una mancanza di capacità che dovrebbe attivare lo scaling potrebbe fallire silenziosamente, lasciando i Pod in sospeso.
Rivedi i Log dello Scheduler (Avanzato): Per analisi diagnostiche approfondite, rivedi i log del componente kube-scheduler stesso. Nei cluster gestiti, l'accesso può variare a seconda del fornitore, quindi inizia con gli eventi del pod e i log del piano di controllo specifici del fornitore.

Correggi il Vincolo, Non il Sintomo

La correzione giusta dipende dal fatto che il vincolo sia accidentale o intenzionale. Se il pod richiede 8 CPU perché qualcuno ha copiato un manifest di produzione in un piccolo cluster di staging, riduci la richiesta per quell'ambiente. Se il pod ha bisogno di una GPU e non esiste un nodo GPU, aggiungere una toleration non aiuterà; il cluster ha bisogno dell'hardware giusto. Se un taint protegge i nodi del database dai carichi di lavoro generici, non rimuovere il taint solo per far schedulare un pod non correlato.

Per le modifiche in produzione, rendi il motivo visibile in Git. Le etichette dei nodi, i taint, le regole di affinità e le richieste di risorse sono contratti di posizionamento. I futuri operatori devono sapere se una regola esiste per prestazioni, conformità, accesso hardware, controllo dei costi o semplice incidente storico.

Esempi di Correzioni Rapide Fuorvianti

Diverse correzioni comuni fanno sì che lo stato Pending immediato scompaia creando un problema peggiore in seguito.

Abbassare le richieste di CPU può aiutare se la richiesta originale era gonfiata, ma non è uno strumento di capacità gratuito. Se l'applicazione ha davvero bisogno di quella CPU durante il traffico di picco, il pod potrebbe essere schedulato e poi avere scarse prestazioni sotto carico. Controlla la cronologia di utilizzo e la latenza prima di tagliare le richieste in modo aggressivo.

Aggiungere una toleration ampia può far schedulare un pod, ma potrebbe atterrare su nodi riservati per un altro scopo. Una toleration dice "questo pod è permesso qui." Non dice "questo pod dovrebbe preferire qui." Se hai bisogno sia del permesso che dell'intenzione, combina le toleration con l'affinità del nodo o i selettori del nodo.

Rimuovere una regola di anti-affinità può ripristinare rapidamente le repliche, ma potrebbe posizionare ogni replica su un nodo o una zona. Questo è talvolta accettabile durante un'interruzione, ma dovrebbe essere un cambiamento temporaneo consapevole, non una deriva permanente silenziosa.

Espandere il cluster è spesso la risposta giusta, ma solo dopo aver saputo che il pod in sospeso può utilizzare i nuovi nodi. Se il pod richiede un'etichetta che il gruppo di nodi con auto-scaling non avrà, aggiungere nodi ti dà solo più nodi inadatti.

Controllo Finale

Un pod in sospeso è un fallimento della negoziazione tra il pod e il cluster. Il pod richiede risorse, etichette, storage, topologia e permessi per atterrare su determinati nodi. Il cluster risponde con capacità, taint, etichette, quote e volumi disponibili. kubectl describe pod mostra dove quella negoziazione è fallita. Una volta letto attentamente l'evento, la maggior parte delle correzioni diventa semplice: cambiare i requisiti del pod, cambiare la capacità disponibile del cluster o correggere la policy che non corrisponde più alla realtà.