Apriamo questo articolo con il mea culpa per non aver ancora coperto l’uscita della nuova versione di Kubernetes, la v1.33, nome in codice Octarine. L’annuncio infatti è stato dato a fine aprile, ed ha portato con sé la consueta dose di novità, deprecazioni, aggiunte e rimozioni che sono parte di ciascuna release e che troverete descritte nel dettaglio ovunque.

A parte quindi il logo, che mostriamo:

Vale la pena citare tra le aggiunte solo una funzionalità molto attesa, ossia il passaggio a stable dei Sidecar Containers, che consentirà di aggiungere la sezione initContainers nei Deployment per affiancare ai container applicativi altri container “di supporto” destinati a scopi diversi rispetto all’applicazione principale.

Ma l’occasione è ghiotta per parlare di un progetto parallelo relativo a Kubernetes ed avviato nel progetto Debian da parte del maintainer Arthur Diniz, che lo descrive nell’articolo Bringing Kubernetes Back to Debian.

Partiamo quindi da qui: se c’è bisogno di “riportare” Kubernetes in Debian, dove era finito?

Dal 2020 infatti la presenza di Kubernetes nei repository ufficiali di Debian è rimasta congelata. L’ultima versione pacchettizzata è stata la 1.20.2-1, e da allora — come ben riassunto in questo articolo di LWN — una serie di ostacoli tecnici (e politici) hanno impedito ulteriori aggiornamenti.

È importante notare come la questione riguardi unicamente Debian, e non ad esempio derivate come Ubuntu e le ragioni di tutto questo ci sono state spiegate proprio da Arthur, disponibilissimo nel raccontare come stia riportando i pacchetti in vita con un approccio pratico e sostenibile.

È una storia che parla di open-source molto interessante.

Il problema

Il nodo principale a proposito dell’assenza di aggiornamenti per i pacchetti Kubernetes riguarda l’enorme quantità di dipendenze esterne che il progetto incorpora. Il codice sorgente contiene una directory vendor/ con centinaia di moduli Go inclusi direttamente nel progetto. Una convinzione diffusa, derivante da quella che avevamo descritto come la più grande migrazione della storia di Kubernetes nel maggio 2024, era che tale directory fosse stata rimossa, ma in realtà essa è tuttora presente nella versione upstream, vedi github.com/kubernetes/kubernetes/tree/master/vendor.

Debian, per sua natura, evita il vendoring: ogni libreria dovrebbe essere impacchettata separatamente e mantenuta come dipendenza a sé stante. Questo però, nel caso di Kubernetes, avrebbe significato impacchettare e manutenere centinaia di moduli Go.

Un lavoro colossale.

A rendere il tutto ancora più complicato, ci sono le policy Debian, che richiedono di dichiarare in maniera esplicita le licenze di ogni singolo file incluso nel pacchetto, attraverso il file debian/copyright.

Debian utilizza un sistema chiamato dh-golang per la build dei pacchetti scritti in Go (vedi manpages.debian.org: dh-golang) e questo strumento automatizza la compilazione usando go build, ma pretende che tutte le dipendenze siano già disponibili nel GOPATH del sistema.

Se manca anche solo una libreria, la compilazione fallisce.

Immaginate cosa può significare tutto questo nel contesto di Kubernetes: mantenere sincronizzate centinaia di dipendenze, solo per ottenere un pacchetto funzionante.

Nemmeno l’uso di variabili come DH_GOLANG_EXCLUDES (che permettono di escludere moduli inutili dalla build) era sufficiente a semplificare la situazione.

La soluzione

La soluzione è arrivata grazie alla strategia di repackaging, una pratica supportata e documentata da Debian, che ha consentito a Diniz ed agli altri manutentori di creare una versione ridotta del tarball originale, rimuovendo cartelle e file non necessari prima dell’importazione nel sistema di build Debian.

Questo ha portato a un enorme vantaggio: i file esclusi non devono più essere elencati nel debian/copyright, riducendo drasticamente la complessità della manutenzione.

Il risultato? Un pacchetto Debian focalizzato esclusivamente su kubectl, il client a linea di comando di Kubernetes, senza portarsi dietro tutto il resto del codice non necessario.

Per vedere chiaramente la differenza tra il codice upstream e quello mantenuto da Debian, ecco i due repository di riferimento:

• Codice upstream.
• Pacchetto Debian in Salsa (il GitLab ufficiale di Debian).

E per chi vuole dare uno sguardo al nuovo file debian/copyright, ora molto più leggibile e gestibile: salsa.debian.org: debian/copyright.

Chiaramente il progetto non si limita a kubectl, ma anche alle altre componenti fondamentali di Kubernetes:

• kubelet: l’agente principale che gira su ogni nodo del cluster.
• kubeadm: lo strumento per inizializzare e gestire cluster Kubernetes.
• helm: il gestore di pacchetti per Kubernetes.
• kompose: il convertitore da docker-compose a manifest Kubernetes.

Il lavoro attuale riguarda la versione 1.32.3 di kubectl, e verrà incluso in Debian 13 “Trixie”, e quindi è plausibile che le altre componenti possano essere incluse per la nuova versione 1.33, poiché oggi è stato dimostrato che “si può fare!“.

Conclusione

Il ritorno di Kubernetes nei repository Debian è un esempio perfetto di come problemi apparentemente insormontabili possano essere affrontati con pazienza, strategia e competenza.

Il lavoro di Arthur Diniz non solo riporta uno strumento chiave nel mondo DevOps dentro l’ecosistema Debian, ma dimostra anche che sì, con le giuste scelte, si può trovare un equilibrio tra rigore e praticità.

Ben fatto, Arthur, ben fatto Debian.