Fedora 41 sarà una release entusiasmante, soprattutto per coloro che sono coinvolti nei settori enterprise e cloud computing. La containerizzazione gioca un ruolo cruciale in questo campo, con Kubernetes che è di fatto lo standard per l’orchestrazione dei servizi containerizzati oggigiorno. La distribuzione ha annunciato cambiamenti significativi alla sua strategia di packaging di Kubernetes per offrire agli amministratori di K8s che utilizzano Fedora maggiore flessibilità e controllo. Fedora 41 segna un passaggio dall’offerta di una singola versione di Kubernetes per release a più versioni supportate contemporaneamente.
Tradizionalmente, ogni release di Fedora era legata a una specifica versione di Kubernetes. Ciò creava una dipendenza che a volte complicava gli aggiornamenti e la manutenzione del sistema. Tuttavia, le cose stanno per cambiare. Con l’imminente Fedora 41, gli utenti possono accedere alle versioni 1.31, 1.30 e 1.29 di Kubernetes, tutte confezionate come RPM individuali. Questa iniziativa separa gli aggiornamenti di Fedora dagli upgrade di Kubernetes, consentendo agli amministratori una maggiore libertà di aggiornare i propri sistemi o Kubernetes in modo indipendente.
Fedora 41: i dettagli dei quattro pacchetti di Kubernetes
La versione iniziale di questi RPM (package manager) con versione apparirà nel ramo Rawhide di Fedora (attuale versione di sviluppo della distribuzione), con Kubernetes 1.31, Kubernetes 1.30 e Kubernetes 1.29. È importante riconoscere che questa strategia riguarda l’aggiunta di flessibilità e l’estensione del ciclo di vita delle installazioni di Kubernetes. Alla luce di ciò, gli RPM senza versione per Kubernetes riceveranno aggiornamenti fino a febbraio 2025. Ciò garantisce continuità e supporto anche quando verranno implementati nuovi RPM. Con le sue tre release annuali e patch mensili, Kubernetes vedrà la versione 1.28 avvicinarsi alla fine del ciclo di vita e la 1.27 non più supportata quando Fedora 41 sarà disponibile.
Ogni release di Kubernetes includerà quattro RPM specifici. Si tratta di “kubernetes1.31“, “kubernetes1.31-client“, “kubernetes1.31-kubeadm” e “kubernetes1.31-systemd“. I nuovi RPM apportano diverse modifiche interne che potrebbero influire sul modo in cui gli amministratori configurano i cluster. Ad esempiogli RPM ora allineano la proprietà predefinita dell’utente e del gruppo dei file kubelet con gli standard degli sviluppatori Kubernetes, rimuovendo la precedente identità kube sysuser. Inoltre, utilizzando kubeadm, kubelet viene ora configurato tramite un file anziché tramite parametri della riga di comando. Infine, le impostazioni predefinite dei file di servizio systemd nei nuovi RPM sono state standardizzate in base alle linee guida degli sviluppatori Kubernetes. Infine, allineandosi a Kubernetes, gli RPM per CRI-O e CRI-Tools aderiscono anche alla corrispondenza delle versioni di livello minore. Ciò garantisce coerenza tra i componenti del sistema, facilitando aggiornamenti e compatibilità più fluidi.
fonte: punto-informatico