La più grande migrazione nella storia di Kubernetes: le integrazioni ai cloud provider sono oggi plugin esterni

Uno dei segreti del successo di Kubernetes risiede senz’altro nel suo essere una piattaforma multi provider. Ciascuno dei vari vendor presenti sul mercato infatti possiede il “proprio” Kubernetes che il cliente può utilizzare in maniera perfettamente integrata nell’ambiente circostante.

Il codice che consente tutto questo era da sempre integrato nell’orchestrator e pur contribuendo fortemente alla sua crescita è finito oggi per diventare un problema in termini di mantenimento.

Infatti man mano che il tempo è passato e le tecnologie sono diventate sempre più complesse, la possibilità di continuare a mantenere questi elementi direttamente nel codice principale di K8s è diventata insostenibile. Basti pensare a come siano essenzialmente cinque i cloud provider integrati in Kubernetes:

• Google Cloud
• AWS
• Azure
• OpenStack
• vSphere

E ciascuno di questi aveva porzioni di codice ad esso dedicate all’interno delle componenti di Kubernetes:

1. Cloud controller manager (KEP-2392)
2. API server network proxy (KEP-1281)
3. kubelet credential provider plugins (KEP-2133)
4. Storage migration to use CSI (KEP-625)

Si fa presto ad immaginare come in termini di mero codice l’esborso gestionale appaia decisamente proibitivo.

Da qui l’idea di trovare una soluzione definitiva: rendere ciò che era integrato una serie di plugin esterni.

I numeri che si vedono tra parentesi nell’elenco soprastante si riferiscono ai KEP (Kubernetes Enhancement Proposal), che fanno capo al principale, ossi KEP-2395, dal titolo Removing In-Tree Cloud Provider Code, nei quali è partito un effort molto importante che ha richiesto lungo tempo per essere completato ed è stato indicato come la più grande migrazione mai effettuata in Kubernetes.

Il lavoro di alleggerimento è prima di tutto fisico, e da la misura di quanto epica sia stata questa operazione, infatti la rimozione di queste componenti integrate ha comportato un milione e mezzo di linee di codice sorgente in meno ed un alleggerimento dei binari relativi al progetto di circa il 40%.

Ma questa titanica impresa, che ha richiesto anni per essere completata, rappresenta anche e soprattutto un momento epocale nell’evoluzione dell’orchestrator di container più utilizzato al mondo, poiché di fatto gli consente di diventare una piattaforma realmente neutrale nei confronti dei vendor.

Ed avere un progetto che possa essere installato con solamente le componenti e funzionalità realmente utilizzate. Mica male!

A partire da Kubernetes v1.31 (la prossima release del progetto) tutto questo sarà effettivo, e quindi bisognerà prepararsi. Fortunatamente e come sempre, la questione è stata già affrontata all’interno di un lungo ed esaustivo articolo, che dovrebbe aiutare quanti ancora non hanno le idee chiare: Kubernetes 1.29: Cloud Provider Integrations Are Now Separate Components.