Kubernetes è open source e gestire un proprio cluster è una scelta legittima. Ciò che vale la pena esaminare nel dettaglio è che cosa chiede un cluster di produzione, nel tempo, a chi lo gestisce: usando come fonte la documentazione e la release policy del progetto Kubernetes stesso, non affermazioni di marketing.
Ogni versione di Kubernetes ha una data di scadenza
Il progetto Kubernetes mantiene i branch di rilascio per le tre release minor più recenti. Ogni release minor riceve circa quattordici mesi di supporto con patch: dodici mesi di supporto standard, poi un periodo di manutenzione di due mesi, al termine del quale la serie raggiunge la fine del ciclo di vita e non riceve più correzioni.
A settembre 2026 le release minor mantenute attivamente sono la 1.37, la 1.36 e la 1.35. La versione 1.34 è nella sua ultima finestra di manutenzione e raggiunge la fine del ciclo di vita il 27 ottobre 2026. La versione 1.33 ha già raggiunto la fine del ciclo di vita il 28 giugno 2026.
Restare indietro costa caro, perché gli aggiornamenti non possono saltare le versioni minor. La version-skew policy richiede che kube-apiserver avanzi di una versione minor alla volta, anche nei cluster con una sola istanza. Un cluster ancora alla 1.33 richiede quindi quattro aggiornamenti consecutivi del control plane (1.34, 1.35, 1.36 e 1.37) per tornare aggiornato, e ognuno richiede una propria preparazione, per esempio verificare che i tuoi admission webhook gestiscano le versioni delle API che il nuovo server invia loro.
I nodi aggiungono lavoro proprio. Gli aggiornamenti in-place delle versioni minor di kubelet non sono supportati: ogni nodo deve prima essere svuotato (drain). Un kubelet può restare indietro rispetto all'API server fino a tre versioni minor, ma la documentazione avverte che un cluster con kubelet costantemente indietro di tre versioni deve aggiornarli prima che il control plane possa avanzare.
L'alta disponibilità è un progetto di cui sei responsabile
Un singolo nodo di control plane è un single point of failure. La guida all'alta disponibilità di kubeadm descrive due topologie. Nella topologia stacked predefinita, ogni nodo di control plane esegue anche un membro etcd, quindi perdere un nodo significa perdere sia un'istanza di control plane sia un membro etcd; la documentazione indica di eseguire almeno tre nodi di control plane stacked. L'alternativa, etcd esterno, separa le due componenti ma richiede un minimo di tre host di control plane più tre host etcd.
etcd ha bisogno di un quorum, cioè della maggioranza dei suoi membri, per accettare le modifiche. Un cluster a tre membri tollera il guasto di un membro e un cluster a cinque membri ne tollera due, mentre aggiungere un quarto membro non offre alcuna tolleranza ai guasti in più. La documentazione di Kubernetes raccomanda un numero dispari di membri e, per la produzione, un cluster a cinque membri.
etcd è inoltre sensibile all'ambiente in cui viene eseguito:
- Disco e rete. Le prestazioni di etcd dipendono dall'I/O di disco e rete. La mancanza di risorse può causare timeout degli heartbeat e lasciare il cluster senza leader, e un cluster senza leader non può cambiare stato, il che significa che non è possibile pianificare nuovi pod.
- Risorse dedicate. La documentazione consiglia di eseguire etcd su macchine dedicate o ambienti isolati, in modo che i suoi requisiti di risorse siano garantiti, e le FAQ di etcd stesso raccomandano caldamente gli SSD.
- L'accesso equivale a root. L'accesso a etcd equivale ai permessi di root nel cluster, quindi idealmente solo l'API server dovrebbe poterlo raggiungere, protetto con certificati TLS x509.
Un backup conta solo dopo che ne hai fatto il ripristino
La documentazione di Kubernetes è diretta: se il tuo cluster usa etcd come backing store, assicurati di avere un piano di backup dei dati. In pratica significa snapshot pianificati con etcdctl, conservati in un luogo che non condivide un dominio di guasto con il cluster, e una procedura di ripristino con etcdutl che qualcuno abbia effettivamente provato.
Gli snapshot richiedono inoltre una gestione attenta, perché contengono tutto ciò che l'API server conosce. Per impostazione predefinita l'API server archivia le risorse in etcd in chiaro, senza cifratura a riposo, a meno che tu non la configuri. Lo snapshot di un cluster non cifrato può quindi contenere i tuoi Secret.
I certificati scadono secondo un calendario
I certificati client generati da kubeadm scadono dopo un anno. kubeadm li rinnova automaticamente quando esegui un aggiornamento del control plane, quindi un cluster aggiornato almeno una volta all'anno è tutelato, mentre un cluster che resta più di un anno senza aggiornamenti no. Puoi controllare la scadenza con kubeadm certs check-expiration e rinnovare manualmente con kubeadm certs renew all, comando che in un control plane replicato va eseguito su ogni nodo di control plane.
Gli add-on sono progetti separati con cicli di vita separati
Un cluster è più del suo control plane. Rete, ingress o Gateway API, driver di storage, gestione dei certificati, metriche e monitoraggio sono progetti distinti, ciascuno con il proprio ciclo di rilascio, le proprie versioni e le proprie date di fine ciclo di vita. In un cluster self-hosted, tenerli tutti sotto controllo è compito tuo.
A novembre 2025 il progetto Kubernetes ha annunciato la dismissione di Ingress NGINX, uno degli ingress controller più diffusi. La manutenzione best-effort è terminata a marzo 2026: non ci sono più rilasci, correzioni di bug né aggiornamenti di sicurezza. Le distribuzioni esistenti continuano a funzionare e gli artefatti restano disponibili, ma qualsiasi vulnerabilità scoperta in seguito non verrà corretta. A gennaio 2026 i comitati Kubernetes Steering e Security Response lo hanno descritto come infrastruttura critica per circa metà degli ambienti cloud native e hanno sollecitato la migrazione a Gateway API o a un altro controller.
La guida alla migrazione del progetto aggiunge un avvertimento: Ingress NGINX ha comportamenti impliciti, e una traduzione che sembra corretta può comunque causare interruzioni. Nulla di tutto questo è un difetto di Kubernetes. È la normale vita di un grande ecosistema open source, ed è esattamente il lavoro che un cluster self-hosted scarica sul tuo team.
Un confronto diretto
| Categoria | Self-hosted | Kube-DC Managed Cluster |
|---|---|---|
| Ciclo di vita delle versioni | Tieni traccia delle date di rilascio e di fine ciclo di vita e aggiorni una versione minor alla volta, con circa quattordici mesi di supporto per ogni release minor | Aggiornamenti graduali e controllati dal tenant: il control plane e i worker pool avanzano separatamente, per fasi. Scegli comunque tu la versione di destinazione e i tempi |
| Control plane | Tre o più nodi di control plane da progettare, proteggere e aggiornare in autonomia | I control plane ospitati funzionano come pod gestiti sulla piattaforma: ottieni la tua API Kubernetes e una PKI per cluster senza gestire i master |
| etcd | Dimensionamento del quorum, dischi dedicati, TLS, deframmentazione e monitoraggio sono a tuo carico | Un datastore dedicato o condiviso gestito dalla piattaforma, con autoscaling verticale di control plane ed etcd attivo per impostazione predefinita |
| Backup | Progetti tu la pianificazione degli snapshot, lo storage e le esercitazioni di ripristino | Snapshot etcd pianificati, configurati per cluster, con cifratura envelope opzionale, e ripristino: in autonomia per i datastore a singola replica, assistito per quelli multi-replica. Gli snapshot sono archiviati nello storage S3 del progetto sulla piattaforma, quindi conserva una tua copia fuori dalla piattaforma se ne hai bisogno al di fuori del dominio di guasto dello storage della piattaforma |
| Certificati | Certificati kubeadm di un anno, rinnovati all'aggiornamento o da te | PKI per cluster e certificati TLS etcd forniti automaticamente insieme al cluster |
| Nodi worker | Sei tu a fornire, creare le immagini, aggiornare e sostituire i nodi | Worker pool dimensionati per pool (CPU, memoria, disco, immagine), con limiti di autoscaling per pool |
| Metrics API | Sei tu a installare e mantenere metrics-server | Preinstallato e funzionante nel nostro test end-to-end di agosto 2026 |
| Tempo al primo cluster | Da ore a giorni di configurazione, più manutenzione continua | Creato da un progetto nel portale o con un singolo manifest; la documentazione della piattaforma descrive un provisioning in pochi minuti |
| Reperibilità | Il tuo team | Supporto 24/7 via email e ticket con un obiettivo di risoluzione di 4 ore (MTTR), incluso nel prezzo |
| Cosa resta a tuo carico | Tutto, dall'hardware ai carichi di lavoro | I tuoi carichi di lavoro, il controllo degli accessi e gli add-on che installi all'interno del tuo cluster: è un cluster Kubernetes completo, amministrato dal tenant |
Quando il self-hosting è la scelta giusta
Se il tuo team già gestisce etcd in produzione, segue le note di rilascio di Kubernetes e degli add-on, prova i ripristini e ha una copertura di reperibilità, il self-hosting è un'estensione ragionevole della prassi esistente. È anche la scelta giusta quando serve un controllo che un servizio gestito non può dare, come una configurazione personalizzata del control plane o un ambiente completamente isolato. Per un team senza questa capacità già in atto, ogni sezione qui sopra diventa lavoro nuovo e continuo.
Fonti
- Kubernetes releases and patch support policy
- Kubernetes patch releases: support period
- Kubernetes version skew policy
- kubeadm: options for highly available topology
- Operating etcd clusters for Kubernetes
- etcd FAQ: cluster size and failure tolerance
- Encrypting confidential data at rest
- Certificate management with kubeadm
- Ingress NGINX retirement: what you need to know
- Ingress NGINX: statement from the Steering and Security Response Committees
- Kube-DC platform datasheet
Scopri la piattaforma
Cloud Acropolis Kube-DC ti offre i tuoi cluster Kubernetes amministrati dal tenant (control plane ospitati, worker pool e aggiornamenti graduali) su vCPU dedicate, storage NVMe basato su Ceph, un IPv4 pubblico dedicato e object storage compatibile S3. Ordini e gestisci tutto in un portale self-service, con supporto 24/7 via email e ticket e un obiettivo di risoluzione di 4 ore incluso. Ogni pacchetto include cluster Kubernetes annidati e la GPU condivisa è disponibile come opzione.
Scopri Kube-DC Kubernetes