Questa pagina spiega come funzionano i ritiri di funzionalità e API causati da Kubernetes e altre dipendenze con Google Kubernetes Engine (GKE). Questa pagina include anche tabelle con informazioni su ritiri specifici di upstream. Per scoprire come visualizzare la tua esposizione a prossimi ritiri, consulta Visualizzazione di informazioni e consigli sul ritiro.
Cosa sono i ritiri di Kubernetes?
I cluster GKE sono basati sul sistema open source di gestione dei cluster Kubernetes. L'insieme di funzionalità di Kubernetes si evolve nel tempo e proprio come vengono introdotte nuove funzionalità nel tempo, a volte potrebbe essere necessario rimuovere una caratteristica. In alternativa, una funzionalità può passare dalla fase beta alla fase GA. Criterio di ritiro di Kubernetes: una funzionalità o un'API deprecata prima che venga rimossa.
Dopo il periodo di deprecazione, quando una funzionalità o un'API viene rimossa, non potrai più utilizzarla a partire dalla versione secondaria di 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 Kubernetes, GKE offre anche funzionalità basate su altri provider, come le immagini dei nodi Windows supportate da Microsoft e le immagini dei nodi Ubuntu supportate da Canonical. Quando questi provider upstream ritirano il supporto per una funzionalità, GKE potrebbe dover rimuovere la funzionalità corrispondente. Le tabelle in questa pagina forniscono anche informazioni su ritiri e ritiri imminenti causati da dipendenze upstream oltre a Kubernetes.
Come funzionano i ritiri di Kubernetes con GKE
L'esecuzione delle applicazioni su GKE comporta una responsabilità condivisa tra te e GKE.
Come utente, devi valutare e mitigare l'esposizione a funzionalità e API deprecate che verranno rimosse nelle prossime versioni secondarie di Kubernetes. Nelle sezioni successive, scoprirai in che modo GKE semplifica questo processo rilevando l'utilizzo di API e funzionalità Kubernetes deprecate, condividendo insight su questo utilizzo e fornendo suggerimenti su come eseguire la migrazione a funzionalità e API compatibili con le versioni secondarie future.
Se GKE rileva che un cluster utilizza una funzionalità che viene rimossa in un'imminente versione secondaria di Kubernetes, gli upgrade automatici del cluster alla versione secondaria successiva vengono messi in pausa e GKE condivide informazioni e suggerimenti sul ritiro.
Cosa succede quando GKE mette in pausa gli upgrade automatici?
Se GKE rileva l'utilizzo di un'API o funzionalità deprecata, mette in pausa gli upgrade automatici per impedire l'upgrade del cluster a uno stato non funzionante. Gli upgrade alla versione secondaria di Kubernetes successiva sono in pausa, ma GKE continua a fornire upgrade delle patch al cluster per la versione secondaria attuale. Ad esempio, se un cluster si trova alla versione 1.21.11-gke.1100 e presenta chiamate ad API deprecate che vengono 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 che vengano rilevati tutti gli utilizzi, GKE non può garantire che gli upgrade siano sempre in pausa quando vengono utilizzate funzionalità o API deprecate. Per assicurarti che non venga eseguito l'upgrade di un cluster, devi utilizzare le esclusioni di manutenzione.
Quando GKE ripristina gli upgrade automatici?
Quando GKE non rileva l'utilizzo della funzionalità deprecata o le chiamate alle API deprecate per 30 giorni, viene eseguito automaticamente l'upgrade del cluster se la successiva versione secondaria è la destinazione dell'upgrade automatico del cluster nel canale di rilascio del cluster e il cluster non ha altri fattori che impediscono gli upgrade, come un'esclusione di manutenzione attiva. Per vedere quando la versione secondaria diventa un target dell'upgrade automatico nel canale di rilascio del cluster, consulta la pianificazione di rilascio per una data stimata e le note di rilascio per l'annuncio specifico. Per ottenere i target di upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster.
Se GKE continua a rilevare l'utilizzo della funzionalità deprecata sul cluster, GKE mantiene il cluster nella versione secondaria attuale fino alla data di fine del supporto della versione.
Le date per il termine del supporto delle versioni secondarie sono disponibili nella pianificazione delle release. 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 rifletta il canale di rilascio del cluster:
- Canali di rilascio diversi da Esteso: se il cluster è registrato nei canali Rapido, Regolare e Stabile o se il cluster non è registrato in un canale di rilascio, questa data rappresenta la fine del supporto standard per la 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 poiché la funzionalità rimossa è ancora in uso. Per scoprire di più, consulta la sezione Upgrade automatici alla fine del supporto.
Che cosa sono gli approfondimenti e i consigli sul ritiro?
Se GKE rileva che un cluster sta utilizzando una funzionalità che è stata rimossa in un'imminente versione secondaria di Kubernetes, GKE condivide un'informazioni e un suggerimento sul ritiro, che ti informano dell'utilizzo di una funzionalità deprecata da parte del cluster. Questo insight fornisce informazioni sull'ultimo utilizzo rilevato e ulteriori dettagli in base al tipo di ritiro. Per scoprire come visualizzare queste informazioni, consulta Visualizzazione di informazioni e consigli sul ritiro.
Valutare e mitigare l'esposizione ai prossimi ritiri di Kubernetes
GKE fornisce guide alla migrazione che spiegano come eseguire la migrazione dalle API e dalle funzionalità deprecate a quelle compatibili con la versione secondaria successiva. Per un elenco dei ritiri imminenti e delle relative guide alla migrazione, consulta Informazioni sui ritiri di Kubernetes.
Sebbene GKE condivida insight sui cluster che ha rilevato vengono esposti a un ritiro, il rilevamento di tutte le esposizioni a ritiri imminenti non è garantito. Ad esempio, se una funzionalità deprecata non è stata utilizzata negli ultimi 30 giorni, GKE non rileva alcun utilizzo e non vengono generati insight e suggerimenti.
Devi valutare in modo indipendente l'esposizione dell'ambiente del cluster a eventuali ritiri imminenti prima di eseguire l'upgrade del cluster alla versione secondaria successiva. Puoi esercitare il controllo sul processo di upgrade scegliendo un canale di rilascio, utilizzando periodi di manutenzione ed esclusioni oppure eseguire l'upgrade manuale dei cluster se hai stabilito che non sono esposti a ritiri nella versione secondaria successiva.
Risoluzione dell'esposizione ai deprecazioni di Kubernetes
Puoi prendere provvedimenti esaminando i prossimi ritiri. Visualizza insight e suggerimenti sul ritiro per valutare se il 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 tuo cluster, GKE attende per 30 giorni l'utilizzo delle API o delle funzionalità deprecate, quindi sblocca gli upgrade automatici. Gli upgrade automatici vengono eseguiti in base alla programmazione delle release.
Puoi anche eseguire l'upgrade del cluster manualmente se hai verificato che l'upgrade non causa interruzioni dell'ambiente cluster. Per farlo, crea prima un cluster di test e controlla se l'upgrade causa interruzioni. In caso contrario, puoi eseguire l'upgrade manuale 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 di queste funzionalità per 30 giorni consecutivi.
Informazioni sui ritiri di Kubernetes
Le sezioni seguenti forniscono informazioni sui ritiri in corso, tra cui 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 vedere se GKE rileva e segnala l'utilizzo con insight e suggerimenti.
Queste tabelle forniscono solo informazioni sui ritiri in corso e omettono le informazioni incluse in precedenza per le funzionalità o le API deprecate con versioni che hanno superato in modo significativo la data di fine del supporto.
Ritiri delle funzionalità di Kubernetes
La tabella seguente illustra i ritiri delle funzionalità GKE in corso, e la versione in cui queste funzionalità non sono più supportate:
| Nome | Ritirato | Rimosso | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|---|---|
| Container Registry | 15 maggio 2023 | 18 marzo 2025 | Transizione da Container Registry ad Artifact Registry in GKE | No |
| Dashboard di conformità GKE (anteprima) | 28 gennaio 2025 | 30 giugno 2025 | Ritiri della funzionalità di gestione della postura | No |
|
Analisi delle vulnerabilità dei workload Dashboard della strategia di sicurezza di GKE |
Versione GKE Standard: 23 luglio 2024 | Versione GKE Standard: 31 luglio 2025 | Rimozione dell'analisi delle vulnerabilità dalla versione GKE Standard | Sì |
|
Problemi della catena di fornitura - Autorizzazione binaria (anteprima) Dashboard della strategia di sicurezza di GKE |
28 gennaio 2025 | 31 marzo 2025 | Ritiri della funzionalità di gestione della postura | No |
|
Strategia di sicurezza per Kubernetes - Livello avanzato (anteprima) Dashboard della strategia di sicurezza di GKE |
28 gennaio 2025 | 31 marzo 2025 | Ritiri della funzionalità di gestione della postura | Sì |
| Funzionalità di containerd 1.7 | GKE versione 1.32 | GKE versione 1.33 | Esegui la migrazione dei nodi a containerd 2 | Sì |
| Modalità cgroupv1 su Linux | GKE versione 1.31 | Da definire | Esegui la migrazione dei nodi a Linux cgroupv2 | 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 | GKE versione 1.24 | GKE versione 1.29 | Rimozione del supporto dei certificati TLS SHA-1 | Sì |
| Plug-in di autenticazione integrato per i client Kubernetes | GKE versione 1.22 | GKE versione 1.25 | Plug-in di autenticazione deprecato per i client Kubernetes | No |
| PodSecurityPolicy | GKE versione 1.21 | GKE versione 1.25 | Ritiro di PodSecurityPolicy | Sì |
| Immagini dei nodi basate su Docker | GKE versione 1.20 | GKE versione 1.24 | Ritiro dell'immagine del nodo Docker | Sì |
| Campo Nome comune X.509 nei certificati webhook | GKE versione 1.19 | GKE versione 1.23 | Ritiro del campo CN dei certificati webhook | Sì |
Ritiri dell'API Kubernetes
La tabella seguente fornisce una panoramica delle API Kubernetes deprecate e non più gestite, ordinate per versione di Kubernetes:
| Versione di Kubernetes | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|
| 1,29 | API deprecate per Kubernetes 1.29 | Sì |
| 1,27 | API deprecate per Kubernetes 1.27 | Sì |
| 1,26 | API deprecate per Kubernetes 1.26 | Sì |
| 1,25 | API deprecate per Kubernetes 1.25 | Sì |
| 1,22 | API Kubernetes 1.22 deprecate, API Kubernetes Ingress beta rimosse in GKE 1.23 |
Sì |
Ritiri di altre funzionalità
La tabella seguente fornisce informazioni su ritiri e rimozioni causati da altri provider upstream che non fanno parte del progetto open source Kubernetes.
| Nome | Ritirato | 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 gestione multi-host su TPU e GKE | N/D | 24 aprile 2025 | Nota di rilascio | No |