La funzionalità GKE che la maggior parte dei cluster ancora non usa: le custom ComputeClasses

Vedo lo stesso schema in quasi tutte le review di cluster GKE che conduco: un lungo elenco di node pool statici, ciascuno legato a un singolo tipo di macchina. Un pool n2-standard-8 per i workloads generici, un pool n2-highmem-16 per i servizi più esigenti in termini di memoria, un pool Spot creato da qualcuno durante una campagna di riduzione dei costi l'anno scorso e magari un pool GPU. I workloads vengono schedulati sui nodi tramite nodeSelector, taint, toleration e regole di node affinity stratificate negli anni.

Tutto regge finché qualcosa non cambia, e di solito si tratta di una di queste tre situazioni.

• Stockout zonali: una zona esaurisce la serie di macchine che avete scelto. Il Cluster Autoscaler può scalare solo i pool specifici che gli avete assegnato, lasciando i pod bloccati in Pending anche quando famiglie di macchine simili restano inutilizzate nella stessa zona.

• Trappole da preemption Spot: preemption Spot massicce riversano i workloads su pool di fallback on-demand. Una volta ripristinata la capacità, non c'è nulla che riporti attivamente i workloads al punto di partenza, quindi i risparmi pianificati non compaiono mai in fattura.

• Upgrade generazionali: passare da N2 a N4 o C4 diventa un calvario operativo di diverse settimane: provisioning di nuovi pool, aggiornamento dei valori Helm in decine di repository, drain dei vecchi nodi e la speranza che nessun manifest abbia le vecchie label hardcoded.

GKE ha una risposta a tutti e tre i problemi già da un po': le custom ComputeClasses. I clienti con cui parlo o non ne hanno mai sentito parlare o danno per scontato che siano riservate ad Autopilot. Non è così. Le custom ComputeClasses sono disponibili sia in modalità Autopilot sia Standard a partire da GKE 1.30.3-gke.1451000 e sono abilitate di default in tutti i cluster idonei.

Le novità recenti più rilevanti

La funzionalità si è evoluta rapidamente nelle ultime minor version di GKE. Questi sono i cambiamenti che segnalerei a chi aveva valutato le ComputeClasses un anno fa ed era passato oltre.

Punteggi di priorità ponderati (1.35.2-gke.1842000+)

Invece di affidarsi solo all'ordine dell'elenco, le regole possono definire un priorityScore esplicito da 1 a 1000. È tutto o niente: o ogni regola della classe ha un punteggio o nessuna lo ha. Fino a tre regole possono condividere lo stesso punteggio e GKE valuta insieme le regole a pari merito, lasciando al Cluster Autoscaler la scelta tra di esse.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: e2
    spot: true
    priorityScore: 30
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

Qui N2 e T2D Spot contano come seconde scelte equivalenti. Le regole raggruppate possono aggiungere latenza all'autoscaling, più per le regole machineFamily ampie che per quelle machineType ristrette, perché GKE deve eseguire più simulazioni.

Selezione automatica dello storage (1.35.3-gke.1290000+)

Mescolare generazioni di macchine comportava un rischio lato storage, perché ogni serie supporta tipi di disco specifici (ad esempio, N4 supporta Hyperdisk, mentre N2 si basa sui PD standard). Ora potete usare una StorageClass con selezione automatica del tipo di disco e GKE crea un tipo di disco compatibile con qualunque tipo di macchina su cui finisce il Pod. Questo rende le catene di fallback multi-generazione molto più sicure per i workloads che usano il provisioning dinamico. I dischi preesistenti richiedono comunque un tipo di disco supportato da tutte le serie di macchine della classe.

Shape di macchina custom (1.33.2-gke.1111000+)

Potete definire shape custom come n4-custom-8-20480 direttamente in machineType, per i workloads il cui rapporto CPU/memoria non rientra nelle shape predefinite.

Impostazioni del boot disk sulle regole machineFamily (1.34.1-gke.1431000+)

Definite storage.bootDiskType e storage.bootDiskSize sulle regole flessibili machineFamily invece che solo sulle regole machineType specifiche:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100

Label e taint nella classe (da 1.33.2 a 1.34.1)

Dichiarate nodeLabels e taints per singola regola di priorità (le label da 1.33.2-gke.1111000, i taint da 1.33.4-gke.1350000) o globalmente sotto nodePoolConfig (da 1.34.1-gke.3084002). I valori a livello di regola e quelli globali non devono sovrapporsi. Così etichettatura e isolamento restano nello stesso oggetto della decisione hardware.

Classi di default per i workloads di sistema (1.33.1-gke.1788000+)

I namespace possono ricevere una classe di default che si applica solo ai Pod non DaemonSet, tramite la label cloud.google.com/default-compute-class-non-daemonset. GKE la usa per eseguire i Pod di sistema in namespace come kube-system e gmp-system separatamente dai vostri workloads, mentre ai Pod DaemonSet non viene assegnato il selector della classe.

Il compute di Autopilot accanto a un default custom (1.34.1-gke.1829001+)

Se impostate una classe custom come default del cluster in un cluster Autopilot, i Pod smettono di girare di default sulla piattaforma container-optimized di Autopilot. Ora potete far girare Pod specifici sulla piattaforma di compute di Autopilot aggiungendo a quei Pod il node selector cloud.google.com/compute-class: autopilot.

Alcune aggiunte minori

priorityDefaults (1.32.1-gke.1729000) permette di impostare valori condivisi una sola volta invece di ripeterli in ogni regola. nodeSystemConfig porta il tuning di kubelet e sysctl dentro la classe. Compact placement e workload policy sono disponibili per Autopilot da 1.33.2-gke.1335000.

Caveat di produzione e casi limite

Le ComputeClasses hanno dei limiti, ed è meglio scoprirli in una design review, non in produzione.

• kube-scheduler non conosce le regole di priorità: le ComputeClasses influenzano l'autoscaling, ma kube-scheduler non le considera. Se i nodi di fallback hanno già capacità disponibile, i nuovi Pod possono finirci prima che sui nodi preferiti. Abilitare activeMigration.optimizeRulePriority sostituisce quei nodi di fallback nel tempo, e una consolidationThreshold più restrittiva aiuta a svuotare prima i nodi di fallback sottoutilizzati.

• Le modifiche valgono solo per il futuro: modificare una ComputeClass non altera i nodi in esecuzione. Eseguite cordon e drain dei nodi esistenti durante una finestra di manutenzione, così vengono sostituiti secondo le nuove regole.

• Tenete i workloads stateful lontani dalla migrazione attiva: la migrazione attiva esegue l'eviction dei Pod e non sposta i dati. La guida alle best practice indica di disabilitarla per le classi usate da workloads stateful. Mettete quei workloads in una classe dedicata e usate la selezione automatica del tipo di disco oppure limitate la classe alle serie di macchine che supportano tutte il vostro tipo di disco.

• I default di namespace non migrano i Pod esistenti: GKE inietta il selector della classe solo nei Pod creati dopo aver etichettato il namespace, quindi i Pod già in esecuzione non vengono toccati. Riavviate i workloads nel namespace dopo aver impostato un default, così i Pod ricreati ricevono il selector e la migrazione attiva. Un default a livello di cluster può invece migrare direttamente i Pod esistenti.

• Attenzione al churn elevato di Pod: nei cluster con tassi molto alti di creazione ed eliminazione di Pod, il Cluster Autoscaler potrebbe non riuscire a valutare le regole inferiori prima che scada il backoff su quelle superiori, e i Pod restano in Pending. Se incappate in questo caso limite, riducete la frequenza di consolidamento o disabilitate la migrazione attiva.

• Comportamento di fallback delle reservation: con AnyBestEffort, se nessuna reservation corrispondente ha capacità, GKE prova un nodo on-demand per la stessa regola prima di passare alla successiva. Per passare direttamente alla regola successiva quando la capacità riservata è esaurita, usate affinity: Specific (per le reservation con nome) o affinity: AnyThenFail.

Vincoli minori

Un workload può selezionare una sola ComputeClass e ogni node pool creato manualmente può appartenere a una sola classe. Su Autopilot, bootDiskType supporta solo pd-balanced. I nomi delle classi non possono iniziare con gke o autopilot. Molte delle funzionalità descritte sopra richiedono patch version recenti, quindi verificate il vostro release channel prima di basarvi il vostro design.

Conclusione

Se i vostri cluster girano ancora su node pool fissi legati a tipi di macchina, iniziate con un namespace stateless. Assegnategli una catena di fallback Spot-first, poi osservate quanto spesso i Pod finiscono sulle regole di fallback e se la migrazione attiva li riporta indietro.

Tenete presente che una ComputeClass decide che tipo di nodo creare, ma la dimensione del nodo dipende dalle resource request dei vostri Pod. Per le regole machineFamily, il Cluster Autoscaler sceglie una dimensione di macchina in base alle request aggregate dei Pod in pending. Request sovradimensionate significano macchine più grandi, bin packing peggiore e un footprint di fallback più ampio.

È qui che il right-sizing ripaga. PerfectScale esegue in modo continuo il right-sizing delle request dei workloads, così i nodi creati dalle vostre ComputeClasses corrispondono a ciò che i Pod usano davvero. La sua funzionalità Node Recommendations vi aiuta a scegliere le famiglie di macchine più convenienti da inserire nelle regole di priorità. Se state analizzando la spesa dei cluster e volete vedere come questi setup di fallback si comportano nella pratica, prenotate una demo con il team.

Riferimenti

• Informazioni sulle ComputeClasses di GKE
• Informazioni sulle custom ComputeClasses
• Informazioni sulle ComputeClasses integrate
• Applicare le ComputeClasses ai Pod di default
• Best practice per le ComputeClasses
• Documentazione di PerfectScale