Questa pagina spiega come le funzionalità e i ritiri delle API causati da Kubernetes e altre dipendenze funzionano con Google Kubernetes Engine (GKE). Questa pagina include anche tabelle con informazioni su ritiri specifici a monte. Per scoprire come visualizzare la tua esposizione ai ritiri imminenti, consulta Visualizzare insight e suggerimenti relativi al ritiro.
Che cosa sono i ritiri 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 una funzionalità potrebbe dover essere rimossa. In alternativa, una funzionalità può passare dalla fase beta alla fase GA. Norme di ritiro di Kubernetes una funzionalità o un'API ritirata prima della rimozione.
Al termine del periodo di ritiro, 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 ritirata, 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 provider, come le immagini dei nodi Windows supportate da Microsoft e le immagini dei nodi Ubuntu supportate da Canonical. Quando questi fornitori upstream ritirano o terminano il supporto di una funzionalità, GKE potrebbe dover rimuovere la funzionalità corrispondente. Le tabelle in questa pagina forniscono anche informazioni su deprecazioni e rimozioni imminenti causate da dipendenze upstream diverse da Kubernetes.
Come funzionano le deprecazioni di Kubernetes con GKE
L'esecuzione di applicazioni su GKE comporta una responsabilità condivisa tra te e GKE.
In qualità di utente, devi valutare e mitigare qualsiasi esposizione a funzionalità e API obsolete che vengono rimosse nelle prossime versioni secondarie di Kubernetes. Nelle sezioni successive, scopri come GKE semplifica questo processo rilevando l'utilizzo di API e funzionalità di Kubernetes deprecate, condividendo approfondimenti su questo utilizzo e fornendo consigli su come eseguire la migrazione ad API e funzionalità compatibili con le prossime versioni secondarie.
Se GKE rileva che un cluster utilizza una funzionalità rimossa in una versione secondaria di Kubernetes imminente, gli upgrade automatici del cluster alla versione secondaria successiva vengono sospesi e GKE condivide un approfondimento e un consiglio sul ritiro.
Che cosa succede quando GKE mette in pausa gli upgrade automatici?
Se GKE rileva l'utilizzo di un'API o una funzionalità deprecata, GKE mette in pausa gli upgrade automatici per evitare che il cluster venga aggiornato in 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 nella versione secondaria attuale. Ad esempio, se un cluster utilizza la versione 1.21.11-gke.1100 e ha chiamate ad API ritirate 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 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 sospesi quando viene utilizzata un'API o una funzionalità ritirata. Per assicurarti che un cluster non venga sottoposto a upgrade, 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 chiamate alle API deprecate per 30 giorni, il cluster viene aggiornato automaticamente se la versione secondaria successiva è il target di upgrade automatico per il cluster nel canale di rilascio e il cluster non presenta altri fattori che impediscono gli upgrade, ad esempio un'esclusione dalla manutenzione attiva. Per sapere quando la versione secondaria diventa una destinazione di upgrade automatico nel canale di rilascio del cluster, consulta il programma di rilascio per una data stimata e le note di rilascio per l'annuncio specifico. Per ottenere le destinazioni 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, 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 nel programma di rilascio. 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 tuo cluster:
- Canali di rilascio diversi da Extended: se il cluster è registrato nei canali Rapid, Regular o Stable oppure non è registrato in un canale di rilascio, questa data corrisponde alla fine del supporto standard della versione secondaria.
- Canale esteso: se il cluster è registrato nel canale esteso, GKE non esegue automaticamente l'upgrade del cluster dalla versione secondaria fino alla fine del supporto esteso.
Una volta raggiunta questa data, il cluster viene automaticamente sottoposto all'upgrade alla versione secondaria successiva e l'ambiente del cluster potrebbe essere danneggiato perché la funzionalità rimossa è ancora in uso. Per saperne di più, leggi l'articolo sugli upgrade automatici alla fine del supporto.
Che cosa sono gli approfondimenti e i consigli sul ritiro?
Se GKE rileva che un cluster utilizza una funzionalità rimossa in una versione secondaria futura di Kubernetes, GKE condivide un insight e un consiglio sul deprecamento, comunicandoti l'utilizzo di una funzionalità deprecata nel cluster. Questo approfondimento fornisce informazioni sull'ultimo utilizzo rilevato e ulteriori dettagli a seconda del tipo di ritiro. Per informazioni su come visualizzare queste informazioni, consulta Visualizzare approfondimenti e consigli sulla deprecazione.
Valutare e mitigare l'esposizione ai prossimi ritiri di Kubernetes
GKE fornisce guide alla migrazione che ti spiegano come eseguire la migrazione dalle funzionalità e dalle API deprecate a quelle compatibili con la prossima versione secondaria. Per un elenco delle prossime deprecazioni e delle relative guide alla migrazione, vedi Informazioni sulle deprecazioni di Kubernetes.
Anche se GKE condivide informazioni sui cluster che ha rilevato sono esposti a un ritiro, il rilevamento di tutte le esposizioni ai ritiri imminenti non è garantito. Ad esempio, se una funzionalità ritirata non è stata utilizzata negli ultimi 30 giorni, GKE non rileva alcun utilizzo e non vengono generati approfondimenti e consigli.
Devi valutare in modo indipendente l'esposizione dell'ambiente del cluster a eventuali deprecazioni 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 o eseguendo manualmente l'upgrade dei cluster se hai stabilito che non sono esposti a ritiri nella prossima versione secondaria.
Risoluzione dell'esposizione ai ritiri di Kubernetes
Puoi intervenire esaminando le ritiri imminenti. Visualizza approfondimenti e consigli sul ritiro, 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 osservare l'utilizzo di API o funzionalità deprecate, quindi sblocca gli upgrade automatici. Gli upgrade automatici vengono eseguiti in base al programma di rilascio.
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 l'upgrade manuale del cluster.
Quando ignori un suggerimento, lo nascondi solo per tutti gli utenti. Gli upgrade automatici rimangono in pausa finché non esegui la migrazione dalle funzionalità ritirate e GKE non rileva l'utilizzo delle funzionalità ritirate per 30 giorni consecutivi.
Informazioni sui ritiri di Kubernetes
Le sezioni seguenti forniscono informazioni sui ritiri in corso, incluse 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 suggerimenti.
Queste tabelle forniscono solo informazioni sui ritiri in corso e omettono le informazioni precedentemente incluse per le funzionalità o le API ritirate con versioni che hanno superato di molto la data di fine del supporto.
Funzionalità di Kubernetes ritirate
La seguente tabella descrive i ritiri delle funzionalità di GKE in corso, nonché 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 delle funzionalità di gestione della postura di sicurezza | No |
|
Analisi delle vulnerabilità dei workload Dashboard della strategia di sicurezza di GKE |
|
|
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 delle funzionalità di gestione della postura di sicurezza | No |
|
Strategia di sicurezza per Kubernetes - livello avanzato (anteprima) Dashboard della strategia di sicurezza di GKE |
28 gennaio 2025 | 31 marzo 2025 | Ritiri delle funzionalità di gestione della postura di sicurezza | Sì |
| Funzionalità di containerd 1.7 | GKE versione 1.32 | Versione GKE 1.33 | Esegui la migrazione dei nodi a containerd 2 | Sì |
| Modalità cgroupv1 di Linux | GKE versione 1.31 | Da definire | Esegui 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 | 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 | Plugin di autenticazione ritirato per i client Kubernetes | No |
| PodSecurityPolicy | GKE versione 1.21 | GKE versione 1.25 | Ritiro di PodSecurityPolicy | Sì |
| Immagini dei nodi basate su Docker | Versione GKE 1.20 | Versione 1.24 di GKE | Deprecazione delle immagini dei nodi Docker | Sì |
| Campo Common Name X.509 nei certificati webhook | GKE versione 1.19 | GKE versione 1.23 | Ritiro del campo CN dei certificati webhook | Sì |
Deprecazioni delle API Kubernetes
La seguente tabella fornisce una panoramica delle API Kubernetes deprecate e non più servite, 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 beta di Kubernetes Ingress rimosse in GKE 1.23 |
Sì |
Altre funzionalità deprecate
La seguente tabella fornisce informazioni su deprecazioni e rimozioni causate da altri fornitori 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 il servizio multi-host su TPU e GKE | N/D | 24 aprile 2025 | Nota di rilascio | No |