Kubernetes Tolerations: esempi, casi d'uso e best practice

Gli effect dei taint di Kubernetes

Vediamo gli effect dei taint offerti da Kubernetes, che le tolerations possono scavalcare.

NoSchedule

L'effect NoSchedule impedisce che nuovi pod vengano schedulati su un nodo, a meno che non abbiano una toleration corrispondente. I pod già in esecuzione sul nodo al momento dell'aggiunta del taint non vengono espulsi. Questo rende NoSchedule utile per riservare nodi a workloads specifici senza interrompere i pod esistenti.

Ad esempio, l'aggiunta di un taint hardware=gpu:NoSchedule impedisce ai pod privi di una toleration corrispondente di essere schedulati ex novo sul nodo GPU. I pod già in esecuzione possono continuare a funzionare.

PreferNoSchedule

L'effect PreferNoSchedule è una restrizione di scheduling di tipo soft. Kubernetes cerca di evitare di collocare sul nodo con taint i pod privi di una toleration corrispondente, ma può comunque schedularli lì quando necessario. A differenza di NoSchedule, non blocca rigidamente lo scheduling.

Questo effect è utile quando gli amministratori preferiscono riservare i nodi a determinati workloads, ma vogliono comunque che lo scheduler possa usarli quando le altre opzioni di posizionamento sono limitate. I pod esistenti non vengono espulsi quando viene aggiunto un taint PreferNoSchedule.

NoExecute

L'effect NoExecute incide sia sullo scheduling sia sui pod già in esecuzione su un nodo. I nuovi pod privi di una toleration corrispondente non possono esservi schedulati, mentre i pod esistenti che non tollerano il taint vengono espulsi.

Una toleration può includere tolerationSeconds per permettere a un pod di rimanere temporaneamente sul nodo dopo la comparsa di un taint NoExecute corrispondente. Allo scadere di quel periodo, il pod viene espulso se il taint è ancora presente. Se tolerationSeconds viene omesso, una toleration corrispondente consente al pod di rimanere finché il taint è presente.

Esempi di tolerations in Kubernetes

Esempio 1: toleration NoSchedule di base

Supponiamo che un nodo abbia il taint workload=analytics:NoSchedule. Un pod ha bisogno di una toleration corrispondente per diventare idoneo allo scheduling su quel nodo. Il pod seguente tollera questo taint specifico:

apiVersion: v1
kind: Pod
metadata:
  name: analytics-pod
spec:
  containers:
    - name: web
      image: nginx:latest
  tolerations:
    - key: "workload"
      operator: "Equal"
      value: "analytics"
      effect: "NoSchedule"

L'operatore Equal richiede che sia la key sia il value corrispondano al taint. Questa toleration consente al pod di accedere ai nodi con il taint specificato, ma non obbliga lo scheduler a collocare il pod su uno di quei nodi.

Esempio 2: tollerare qualsiasi valore di un taint

L'operatore Exists può essere usato quando un pod deve tollerare una chiave di taint indipendentemente dal valore. Ad esempio, la configurazione seguente tollera qualsiasi taint NoSchedule con chiave workload:

apiVersion: v1
kind: Pod
metadata:
  name: compute-pod
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "workload"
      operator: "Exists"
      effect: "NoSchedule"

Quando si usa Exists non viene specificato alcun valore. Di conseguenza, questo pod può tollerare taint come workload=database:NoSchedule e workload=batch:NoSchedule. Altre chiavi o effect di taint richiedono comunque tolerations corrispondenti separate.

Esempio 3: NoExecute con tolerationSeconds

Una toleration NoExecute può includere tolerationSeconds per controllare per quanto tempo un pod rimane su un nodo dopo l'applicazione di un taint corrispondente. Il pod seguente tollera un taint maintenance-window=active:NoExecute per 100 secondi:

apiVersion: v1
kind: Pod
metadata:
  name: maintenance-worker
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "maintenance-window"
      operator: "Equal"
      value: "active"
      effect: "NoExecute"
      tolerationSeconds: 100

Se il taint viene aggiunto mentre il pod è in esecuzione, il pod può rimanere sul nodo fino a 100 secondi. Se dopo quel periodo il taint è ancora presente, Kubernetes espelle il pod. Se il taint viene rimosso prima della scadenza, il pod può continuare a funzionare.

Best practice per le tolerations di Kubernetes

Usare le tolerations solo per i workloads che ne hanno bisogno

Le tolerations vanno aggiunte solo quando un workload ha un motivo chiaro per essere eseguito su nodi con taint. Tolerations troppo ampie o superflue indeboliscono l'isolamento che i taint dovrebbero garantire e possono far finire i workloads su nodi riservati ad altri scopi. Questo può generare contesa delle risorse e rendere meno prevedibile il posizionamento sui nodi.

È opportuno rivedere le tolerations man mano che i requisiti dei workloads cambiano. Meglio evitare tolerations Exists generiche, a meno che il pod non debba davvero tollerare un'ampia gamma di taint. Preferire key, value ed effect con ambito ristretto, in modo che ogni workload riceva solo le autorizzazioni di scheduling di cui ha effettivamente bisogno.

È inoltre utile gestire le tolerations a livello di controller del workload, ad esempio in un Deployment, StatefulSet o DaemonSet. In questo modo il comportamento di scheduling resta coerente quando i pod vengono ricreati o scalati.

Abbinare le tolerations alla node affinity

Una toleration rende un pod idoneo a essere eseguito su un nodo con taint, ma non lo indirizza verso quel nodo. Se un workload deve girare specificamente su un determinato node pool, è consigliabile combinare le tolerations con la node affinity o i node selector.

Ad esempio, un workload GPU può tollerare il taint dei nodi GPU e al tempo stesso usare la node affinity per richiedere nodi etichettati con il tipo di GPU appropriato. Il taint tiene lontani i workloads ordinari, mentre l'affinity indirizza il workload GPU verso i nodi compatibili.

La scelta tra node affinity required e preferred dipende da quanto deve essere rigido il posizionamento. L'affinity required impedisce lo scheduling sui nodi che non corrispondono, mentre quella preferred lascia allo scheduler maggiore flessibilità quando non sono disponibili nodi adatti.

Mantenere taint e tolerations coerenti tra i node pool

Adottare uno schema di denominazione coerente per chiavi e valori dei taint in tutti i node pool. Valori incoerenti come workload=gpu, type=gpu e node=gpu per lo stesso scopo rendono le configurazioni dei pod più difficili da mantenere e aumentano il rischio di errori di scheduling.

Definire taint standard per i ruoli di nodo più comuni e applicarli tramite l'automazione del cluster o dell'infrastruttura. I manifest dei workloads potranno così usare tolerations prevedibili in sviluppo, staging e produzione, senza differenze di configurazione superflue.

La coerenza è particolarmente importante quando i nodi vengono creati o sostituiti automaticamente da sistemi di autoscaling del cluster. I nuovi nodi dovrebbero ricevere i taint e le label previsti durante il provisioning, così che i workloads si comportino allo stesso modo indipendentemente dall'istanza di nodo in esecuzione.

Proteggere i nodi specializzati e costosi

Usare i taint per impedire ai pod generici di consumare risorse specializzate come GPU, istanze ad alta memoria o altro hardware costoso. Solo i workloads progettati per utilizzare tali risorse dovrebbero ricevere le tolerations corrispondenti.

Le tolerations da sole non garantiscono che un pod richieda effettivamente la risorsa specializzata. Per i workloads GPU, ad esempio, oltre alla toleration vanno configurati gli opportuni resource request o limit. La node affinity può offrire un ulteriore controllo sul posizionamento quando sono disponibili più tipi di hardware.

Questo approccio aiuta a evitare che workloads a bassa priorità occupino capacità necessaria alle applicazioni specializzate. Può inoltre ridurre i costi di infrastruttura, mantenendo i nodi costosi disponibili per i workloads in grado di sfruttarne l'hardware.

Monitorare gli esiti dello scheduling, non solo la configurazione

Una toleration valida non garantisce che un pod venga schedulato con successo. Disponibilità delle risorse, node affinity, vincoli di topologia, pod affinity e anti-affinity e altre regole dello scheduler possono comunque impedirne il posizionamento.

Monitorare i pod in stato pending, gli eventi dello scheduler, i taint dei nodi e il posizionamento effettivo dei pod per verificare che le policy di scheduling si comportino come previsto. Comandi come kubectl describe pod e kubectl describe node aiutano a identificare le mancate corrispondenze dei taint e altri vincoli di scheduling.

Il monitoraggio dovrebbe rilevare anche i posizionamenti imprevisti, non solo i pod che restano in pending. Un workload in esecuzione sul node pool sbagliato può indicare tolerations troppo ampie o regole di affinity mancanti. Controlli periodici aiutano a garantire che le policy di scheduling continuino a funzionare man mano che il cluster e i suoi workloads evolvono.

FAQ

Che cos'è una toleration in Kubernetes? Una toleration è un'impostazione nella spec di un pod che consente al pod di essere schedulato su nodi con taint corrispondenti. Si limita a consentire lo scheduling: non garantisce che il pod finisca su un nodo con taint, perché resource request e node affinity restano comunque valide.

Qual è la differenza tra un taint e una toleration? I taint vengono applicati ai nodi e respingono i pod privi di una toleration corrispondente. Le tolerations vengono applicate ai pod e consentono, senza imporlo, lo scheduling su nodi con taint corrispondenti.

Qual è la differenza tra gli operatori Equal ed Exists? Equal richiede che key, value ed effect della toleration corrispondano al taint, ed è l'operatore predefinito quando non ne viene impostato uno. Exists effettua la corrispondenza solo sulla chiave, quindi il valore deve essere omesso, e tollera qualsiasi valore per quella chiave.

Che cosa fanno gli effect NoSchedule, PreferNoSchedule e NoExecute? NoSchedule blocca i nuovi pod privi di una toleration corrispondente, ma non tocca i pod in esecuzione. PreferNoSchedule è una versione soft in cui lo scheduler cerca di evitare il nodo. NoExecute espelle anche i pod in esecuzione che non tollerano il taint.

A cosa serve tolerationSeconds? In una toleration NoExecute, tolerationSeconds stabilisce per quanto tempo un pod può rimanere su un nodo dopo la comparsa di un taint corrispondente. Trascorso quel tempo, se il taint è ancora presente, Kubernetes espelle il pod. Se viene omesso, il pod rimane finché il taint è presente.

Una toleration fa sì che un pod venga eseguito su un nodo con taint? No. Una toleration rende il pod soltanto idoneo. Per indirizzare un pod verso un node pool specifico, occorre abbinare la toleration a una node affinity o a un node selector.

Uno scheduling basato sulle tolerations più efficiente con PerfectScale

Taint e tolerations stabiliscono dove i pod possono essere eseguiti, ma non dicono nulla sul corretto dimensionamento di quei nodi né sul fatto che i workloads che vi approdano richiedano la giusta quantità di CPU e memoria. PerfectScale è una piattaforma di ottimizzazione e governance per Kubernetes che si installa con un singolo comando Helm e fornisce poi insight concreti e ottimizzazione autonoma sull'intero stack K8s, workloads, nodi e autoscaler, affinché i node pool riservati, specializzati e costosi vengano davvero utilizzati in modo efficiente.

Le funzionalità chiave di PerfectScale:

• Right-sizing autonomo dei workloads: Podfit offre una vista granulare dello stato di salute e dei costi del cluster, evidenzia risorse sprecate e problemi di resilienza e ottimizza i workloads in autonomia con raccomandazioni di right-sizing basate sui dati, che è possibile automatizzare.
• Insight sull'utilizzo a livello di nodo: Infrafit fa emergere la capacità inutilizzata dei nodi e consiglia i tipi di nodo giusti per i workloads, così che i node pool dedicati, GPU e con altri taint offrano le massime prestazioni senza pagare capacità inutilizzata.
• Ottimizzazione degli autoscaler: PerfectScale si integra con HPA, KEDA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning e Google Autopilot, massimizzando l'efficacia dei sistemi che effettuano il provisioning e la sostituzione dei nodi con taint.
• Avvisi in tempo reale con prioritizzazione automatica: i rischi di resilienza e le anomalie di costo vengono evidenziati con una prioritizzazione basata sull'impatto e recapitati direttamente su Slack, Datadog, MS Teams o PagerDuty, prima che raggiungano gli utenti o la fattura cloud.
• Trend, governance e previsioni: il report Trends offre una visibilità approfondita nel tempo sulle metriche di costo, spreco e rischio su cluster, gruppi di nodi, namespace e workloads, supportando l'analisi delle cause e una pianificazione accurata dei budget.
• Qualsiasi ambiente Kubernetes: PerfectScale funziona su cluster on-premise e cloud, inclusi OpenShift, EKS, GKE, AKS e configurazioni ibride, con supporto per container Windows e workloads effimeri o di ML come i job Airflow e Spark.

Maggiori informazioni sulla piattaforma PerfectScale