Se una cosa abbiamo imparato di Kubernetes è che si tratta di una tecnologia complicata. Purtroppo però se si opera in contesti cloud, e ormai anche AI, non si può prescindere dal comprenderla e conoscerla.

Un’altra cosa che chiunque abbia seguito un minimo lo sviluppo di Kubernetes ha compreso è che si tratta di una tecnologia in costante evoluzione. Ciascuna release, che lo ricordiamo esce ogni circa 4 mesi, porta sempre con se un bel quantitativo di aggiunte, deprecazioni e, a volte, nuovi formati che gli utenti devono sempre misurare a dovere, per rispondere alla fatidica domanda: “il prossimo update spaccherà tutto?“.

La scorsa settimana il progetto ha pubblicato l’annuncio di Kubernetes 1.37, nome in codice Garhwal, che rispetto a quanto descritto sinora non smentisce il trend.

Queste le novità più rilevanti, la maggioranza delle quali, manco a dirlo, è incentrata sull’AI:

• HPA scale-to-zero in Beta: l’HorizontalPodAutoscaler (vera anima della scalabilità automatica di Kubernetes) può ora portare a zero i Pod di workload che utilizzano metriche object o external, una possibilità particolarmente interessante per workload batch, queue worker e applicazioni AI/GPU che possono rimanere completamente inattive quando non c’è lavoro da svolgere.
• Gang scheduling in Beta: Kubernetes migliora la gestione dei workload composti da gruppi di Pod che devono essere schedulati insieme, una necessità sempre più importante per AI/ML e HPC. L’obiettivo è evitare che solo una parte del workload venga avviata, rimanendo poi bloccata in attesa delle risorse necessarie al resto.
• Resilient watchcache Initialization diventa Stable: l’inizializzazione della cache del control plane viene resa più resiliente, evitando picchi di richieste verso etcd durante l’avvio o il recupero dell’API server e riducendo il rischio di sovraccarichi del control plane.
• Storage Version Migrator diventa Stable: Kubernetes può gestire in maniera nativa la migrazione dei dati memorizzati da una versione di storage a un’altra, evitando agli amministratori di dover ricorrere a procedure e script manuali.
• L’API metrics.k8s.io diventa Stable: dopo quasi nove anni (!) in Beta, l’API utilizzata, tra le altre cose, da kubectl top e dall’HorizontalPodAutoscaler raggiunge finalmente la maturità.
• Migliora la gestione delle risorse per AI e acceleratori: diverse funzionalità del Dynamic Resource Allocation (DRA) raggiungono lo stato Stable, rendendo più sofisticata la gestione e l’assegnazione di risorse specializzate come GPU e dispositivi di rete.
• KYAML diventa Stable: ed è probabilmente questa la novità più curiosa per chi passa buona parte delle proprie giornate a scrivere manifest Kubernetes.

Proprio quest’ultima aggiunta, l’introduzione del formato KYAML, rappresenta la vera novità. Le specifiche sono presentate nella loro interessa all’interno del sito dedicato https://kyaml.com, ma nella sostanza ecco come si presenta:

KYAML, acronimo di Kubernetes YAML, non è in realtà un nuovo linguaggio che sostituisce YAML, bensì un sottoinsieme più restrittivo e meno ambiguo di YAML, pensato espressamente per i manifest Kubernetes. La cosa interessante è che ogni documento KYAML rimane perfettamente valido YAML: non c’è quindi bisogno di buttare via i manifest esistenti, né di cambiare gli strumenti che già si utilizzano.

La differenza principale sta nel modo in cui KYAML decide di sacrificare una parte della flessibilità di YAML in cambio di maggiore prevedibilità. Le stringhe vengono esplicitamente racchiuse tra virgolette, mentre oggetti e array possono essere rappresentati utilizzando una sintassi più simile a quella che conosciamo dal JSON. In questo modo vengono eliminati alcuni dei comportamenti più sorprendenti di YAML, come la conversione automatica di determinati valori nel tipo sbagliato.

Prendiamo un banalissimo manifest Kubernetes. In YAML tradizionale potremmo scrivere:

spec:
  containers:
    - name: app
      image: nginx
  country: NO
  version: 3.10

La versione KYAML diventa invece:

spec: {
  containers: [
    { name: "app", image: "nginx" }
  ]
}
country: "NO"
version: "3.10"

A prima vista può sembrare quasi una bestemmia: abbiamo passato anni a raccontare quanto YAML fosse più leggibile del JSON e ora Kubernetes ci propone qualcosa che, almeno visivamente, gli assomiglia parecchio. Il punto però non è tanto rendere il file più bello da leggere, quanto renderne il comportamento più prevedibile.

Il problema è infatti proprio nella libertà concessa da YAML. Un valore che per noi è evidentemente una stringa può essere interpretato dal parser come booleano, numero o altro tipo. Il famigerato caso del codice paese NO, ad esempio, può essere interpretato come un valore booleano in determinate implementazioni YAML. Allo stesso modo, un valore come 3.10 rischia di essere trattato come un numero e quindi perdere lo zero finale. KYAML impone invece che una stringa sia dichiarata esplicitamente come tale.

C’è poi un’altra differenza importante: KYAML è insensibile all’indentazione. Chiunque abbia passato mezz’ora a cercare quel singolo spazio mancante in un manifest YAML può intuire immediatamente perché questa caratteristica possa essere interessante. La sintassi permette inoltre le virgole finali, mantenendo i commenti con #, quindi senza rinunciare completamente alla comodità che ha reso YAML così popolare.

Il progetto Kubernetes ha introdotto KYAML come funzionalità Alpha nella versione 1.34, l’ha portato in Beta con la 1.35 e ora, con la 1.37, lo promuove a Stable dopo il completamento dei test di conformità. Anche il comando kubectl get -o kyaml è ora Stable.

Pronti ad imparare a padroneggiare anche questo indispensabile formato?