Questa pagina spiega come funzionano le deprecazioni di funzionalità e API causate da Kubernetes e altre dipendenze con Google Kubernetes Engine (GKE). Questa pagina include anche tabelle con informazioni su specifiche deprecazioni upstream. Per scoprire come visualizzare la tua esposizione alle prossime deprecazioni, consulta Visualizzare approfondimenti e consigli relativi alle deprecazioni.
Che cosa sono le deprecazioni di Kubernetes?
I cluster GKE sono basati sul sistema open source di gestione dei cluster Kubernetes. Il set di funzionalità di Kubernetes si evolve nel tempo e, proprio come vengono introdotte nuove funzionalità nel tempo, a volte potrebbe essere necessario rimuovere una funzionalità. In alternativa, una funzionalità può passare dalla fase beta alla fase di disponibilità generale. Le norme sul ritiro di Kubernetesprevedono un periodo di ritiro per una funzionalità o un'API deprecata prima della sua rimozione.
Dopo il periodo di deprecazione, quando una funzionalità o un'API viene rimossa, non puoi più utilizzarla a partire dalla versione secondaria GKE corrispondente. Se un cluster dipendeva da una funzionalità o un'API deprecata, la funzionalità potrebbe essere compromessa.
Deprecazioni causate da altre dipendenze upstream
Oltre alle funzionalità e alle API di Kubernetes, GKE fornisce anche funzionalità basate su altri fornitori, come le immagini dei nodi Windows supportate da Microsoft e le immagini dei nodi Ubuntu supportate da Canonical. Quando questi fornitori upstream deprecano o terminano il supporto per una funzionalità, GKE potrebbe dover rimuovere la funzionalità corrispondente. Le tabelle in questa pagina forniscono anche informazioni sulle prossime deprecazioni e rimozioni causate da dipendenze upstream diverse da Kubernetes.
Come funzionano le deprecazioni di Kubernetes con GKE
L'esecuzione delle applicazioni su GKE comporta una responsabilità condivisa tra te e GKE.
Come utente, devi valutare e mitigare qualsiasi esposizione a funzionalità e API deprecate che vengono rimosse nelle prossime versioni secondarie di Kubernetes. Nelle sezioni successive, scopri come GKE semplifica questo processo rilevando l'utilizzo di funzionalità e API Kubernetes deprecate, condividendo approfondimenti su questo utilizzo e fornendo consigli su come eseguire la migrazione a funzionalità e API compatibili con le prossime versioni secondarie.
Se GKE rileva che un cluster utilizza una funzionalità rimossa in una prossima versione secondaria di Kubernetes, gli upgrade automatici del cluster alla versione secondaria successiva vengono messi in pausa e GKE condivide un approfondimento e un consiglio relativi alla deprecazione.
Che cosa succede quando GKE mette in pausa gli upgrade automatici?
Se GKE rileva l'utilizzo di una funzionalità o un'API deprecata, GKE mette in pausa gli upgrade automatici per evitare che il cluster venga sottoposto all'upgrade in uno stato non funzionante. Gli upgrade alla versione secondaria di Kubernetes successiva vengono messi in pausa, ma GKE continua a fornire upgrade delle patch al cluster nella versione secondaria corrente. Ad esempio, se un cluster utilizza la versione 1.21.11-gke.1100 e ha chiamate ad API deprecate rimosse dalla versione 1.22, GKE mette in pausa l'upgrade automatico alla versione 1.22. Tuttavia, GKE non mette in pausa l'upgrade automatico a una nuova versione di patch, 1.21.11-gke.1900.
Poiché GKE non può garantire il rilevamento di tutto l'utilizzo, non può garantire che gli upgrade vengano sempre messi in pausa quando viene utilizzata una funzionalità o un'API deprecata. Per assicurarti che non venga eseguito l'upgrade di un cluster, devi utilizzare le esclusioni dalla manutenzione.
Quando GKE riprende gli upgrade automatici?
Una volta che GKE non ha rilevato l'utilizzo della funzionalità deprecata o le chiamate alle API deprecate per 30 giorni, viene eseguito automaticamente l'upgrade del cluster se la versione secondaria successiva è la destinazione dell'upgrade automatico per il cluster nel canale di rilascio del cluster e se il cluster non presenta altri fattori che impediscono gli upgrade, ad esempio un'esclusione dalla manutenzione attiva. Per scoprire quando la versione secondaria diventa una destinazione dell'upgrade automatico nel canale di rilascio del cluster, consulta la pianificazione dei rilasci per una data stimata e le note di rilascio per l'annuncio specifico. Per ottenere le destinazioni dell'upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster.
Se GKE continua a rilevare l'utilizzo della funzionalità deprecata nel cluster, mantiene il cluster nella versione secondaria corrente fino alla data di fine del supporto della versione.
Le date di fine del supporto delle versioni secondarie sono disponibili nella Pianificazione dei rilasci. Poiché la data di fine del supporto per una versione secondaria dipende dalla registrazione al canale di rilascio, assicurati di fare riferimento alla data corretta che riflette il canale di rilascio del cluster:
- Canali di rilascio diversi da quello esteso: se il cluster è registrato nei canali Rapido, Regolare, Stabile o se non è registrato in un canale di rilascio, questa data è la fine del supporto standard della versione secondaria.
- Canale esteso: se il cluster è registrato nel canale esteso, GKE non eseguirà automaticamente l'upgrade del cluster dalla versione secondaria fino alla fine del supporto esteso.
Una volta raggiunta questa data, viene eseguito automaticamente l'upgrade del cluster alla versione secondaria successiva e l'ambiente del cluster potrebbe essere compromesso perché la funzionalità rimossa è ancora in uso. Per saperne di più, consulta Upgrade automatici alla fine del supporto.
Che cosa sono gli approfondimenti e i consigli relativi alle deprecazioni?
Se GKE rileva che un cluster utilizza una funzionalità rimossa in una prossima versione secondaria di Kubernetes, GKE condivide un approfondimento e un consiglio relativi alla deprecazione, informandoti dell'utilizzo di una funzionalità deprecata da parte del cluster. Questo approfondimento fornisce informazioni sull'ultimo utilizzo rilevato e ulteriori dettagli a seconda del tipo di deprecazione. Per scoprire come visualizzare queste informazioni, consulta Visualizzare approfondimenti e consigli relativi alle deprecazioni.
Valutare e mitigare l'esposizione alle prossime deprecazioni di Kubernetes
GKE fornisce guide alla migrazione che ti spiegano come eseguire la migrazione da funzionalità e API deprecate a quelle compatibili con la prossima versione secondaria. Per un elenco delle prossime deprecazioni e delle relative guide alla migrazione, consulta Informazioni sulle deprecazioni di Kubernetes.
Sebbene GKE condivida approfondimenti sui cluster che ha rilevato essere esposti a una deprecazione, non è garantito il rilevamento di tutte le esposizioni alle prossime deprecazioni. Ad esempio, se una funzionalità deprecata non è stata utilizzata negli ultimi 30 giorni, GKE non rileva alcun utilizzo e non viene generato un approfondimento e un consiglio.
Prima di eseguire l'upgrade del cluster alla versione secondaria successiva, devi valutare in modo indipendente l'esposizione dell'ambiente del cluster a eventuali deprecazioni future. Puoi esercitare il controllo sul processo di upgrade scegliendo un canale di rilascio, utilizzando periodi di manutenzione ed esclusioni, o eseguendo manualmente l'upgrade dei cluster se hai stabilito che non sono esposti a deprecazioni nella versione secondaria successiva.
Risolvere l'esposizione alle deprecazioni di Kubernetes
Puoi intervenire esaminando le prossime deprecazioni. Visualizza gli approfondimenti e i consigli relativi alle deprecazioni, per valutare se il tuo cluster è esposto e utilizza le guide alla migrazione per mitigare l'esposizione prima che l'ultima versione secondaria disponibile che supporta la funzionalità raggiunga la fine del supporto.
Dopo aver apportato modifiche per interrompere l'utilizzo di API o funzionalità deprecate nel cluster, GKE attende 30 giorni senza rilevare l'utilizzo di API o funzionalità deprecate, quindi sblocca gli upgrade automatici. Gli upgrade automatici procedono in base al programma delle pubblicazioni.
Puoi anche eseguire l'upgrade del cluster manualmente se hai confermato che l'upgrade non causa interruzioni all'ambiente del cluster. Per farlo, crea prima un cluster di test e verifica se l'upgrade causa interruzioni. In caso contrario, puoi eseguire manualmente l'upgrade del cluster.
Quando ignori un consiglio, lo nascondi solo per tutti gli utenti. Gli upgrade automatici rimangono in pausa finché non esegui la migrazione dalle funzionalità deprecate e GKE non rileva l'utilizzo delle funzionalità deprecate per 30 giorni consecutivi.
Informazioni sulle deprecazioni di Kubernetes
Le sezioni seguenti forniscono informazioni sulle deprecazioni in corso, incluse le guide che spiegano come eseguire la migrazione a funzionalità o API compatibili con le versioni secondarie di Kubernetes disponibili. Puoi controllare queste tabelle per verificare se GKE rileva e segnala l'utilizzo con approfondimenti e consigli.
Queste tabelle forniscono solo informazioni sulle deprecazioni in corso e omettono le informazioni incluse in precedenza per le funzionalità o le API deprecate con versioni che hanno superato di molto la data di fine del supporto.
Deprecazioni delle funzionalità di Kubernetes
La tabella seguente descrive le deprecazioni delle funzionalità di GKE in corso, nonché la versione in cui queste funzionalità non sono più supportate:
| Nome | Deprecato | Rimosso | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|---|---|
| Container Registry | 15 maggio 2023 | 18 marzo 2025 | Eseguire la transizione da Container Registry ad Artifact Registry in GKE | No |
| Dashboard GKE Compliance (anteprima) | 28 gennaio 2025 | 30 giugno 2025 | Deprecazioni delle funzionalità di gestione della security posture | No |
|
Analisi delle vulnerabilità dei workload Dashboard della security posture di GKE |
|
|
Rimozione dell'analisi delle vulnerabilità dalla versione GKE Standard | Sì |
|
Problemi della catena di fornitura - Autorizzazione binaria (anteprima) Dashboard della security posture di GKE |
28 gennaio 2025 | 31 marzo 2025 | Deprecazioni delle funzionalità di gestione della security posture | No |
|
Security posture di Kubernetes - livello avanzato (anteprima) Dashboard della security posture di GKE |
28 gennaio 2025 | 31 marzo 2025 | Deprecazioni delle funzionalità di gestione della security posture | Sì |
| Funzionalità di containerd 1.7 | Versione 1.32 di GKE | Versione 1.33 di GKE | Eseguire la migrazione dei nodi a containerd 2 | Sì |
| Modalità cgroupv1 di Linux | Versione 1.31 di GKE | Da definire | Eseguire la migrazione dei nodi a cgroupv2 di Linux | No |
| Rimozione dell'analisi delle vulnerabilità dalla versione GKE Standard | 23 luglio 2024 | 31 luglio 2025 | Rimozione dell'analisi delle vulnerabilità dalla versione GKE Standard | No |
| Certificati TLS firmati con l'algoritmo SHA-1 | Versione 1.24 di GKE | Versione 1.29 di GKE | Rimozione del supporto per i certificati TLS SHA-1 | Sì |
| Plug-in di autenticazione integrato per i client Kubernetes | Versione 1.22 di GKE | Versione 1.25 di GKE | Plug-in di autenticazione deprecato per i client Kubernetes | No |
| PodSecurityPolicy | Versione 1.21 di GKE | Versione 1.25 di GKE | Deprecazione di PodSecurityPolicy | Sì |
| Immagini dei nodi basate su Docker | Versione 1.20 di GKE | Versione 1.24 di GKE | Deprecazione delle immagini dei nodi Docker | Sì |
| Campo Common Name X.509 nei certificati webhook | Versione 1.19 di GKE | Versione 1.23 di GKE | Deprecazione del campo CN dei certificati webhook | Sì |
Deprecazioni delle API Kubernetes
La tabella seguente fornisce una panoramica delle API Kubernetes deprecate e non più pubblicate, ordinate per versione di Kubernetes:
| Versione di Kubernetes | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|
| 1.32 | API Kubernetes 1.32 deprecate | Sì |
| 1.29 | API Kubernetes 1.29 deprecate | Sì |
| 1.27 | API Kubernetes 1.27 deprecate | Sì |
| 1.26 | API Kubernetes 1.26 deprecate | Sì |
| 1.25 | API Kubernetes 1.25 deprecate | Sì |
| 1.22 | API Kubernetes 1.22 deprecate, API Ingress Kubernetes beta rimosse in GKE 1.23 |
Sì |
Altre deprecazioni delle funzionalità
La tabella seguente fornisce informazioni sulle deprecazioni e sulle rimozioni causate da altri fornitori upstream che non fanno parte del progetto open source Kubernetes.
| Nome | Deprecato | Rimosso | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|---|---|
| Immagini dei nodi del canale semestrale (SAC) di Windows Server | N/D | 9 agosto 2022 | Fine del servizio SAC di Windows Server | No |
| Saxml per la pubblicazione multi-host su TPU e GKE | N/D | 24 aprile 2025 | Nota di rilascio | No |