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 ritirazioni specifiche a monte. Per scoprire come visualizzare la tua esposizione ai ritiri imminenti, consulta Visualizzare approfondimenti e consigli sul ritiro.
Che 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, così come vengono introdotte nuove funzionalità, a volte è necessario rimuoverne una. In alternativa, una funzionalità può passare dalla fase beta alla fase GA. I criteri di ritiro di Kubernetes garantiscono agli utenti una procedura prevedibile per eseguire la migrazione da una funzionalità o API ritirata prima che venga rimossa.
Al termine del periodo di ritiro, quando una funzionalità o un'API viene rimossa, non potrai più utilizzarla a partire dalla versione minore di GKE corrispondente. Se un cluster dipendeva da una funzionalità o API ritirata, la funzionalità potrebbe essere compromessa.
Ritiro causato da altre dipendenze a monte
Oltre alle API e alle funzionalità di 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 fornitori upstream ritirano o interrompono il supporto di una funzionalità, GKE potrebbe dover rimuovere la funzionalità corrispondente. Le tabelle in questa pagina forniscono anche informazioni sulle deprecazioni e le rimozioni imminenti causate da dipendenze a monte diverse da Kubernetes.
Come funzionano i ritiri 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 l'eventuale esposizione alle funzionalità e alle API obsolete che verranno rimosse nelle prossime versioni secondarie di Kubernetes. Nelle sezioni seguenti scoprirai in che modo GKE semplifica questo processo rilevando l'utilizzo di API e funzionalità Kubernetes ritirate, condividendo approfondimenti su questo utilizzo e fornendo consigli su come eseguire la migrazione a funzionalità e API compatibili con le versioni minori imminenti.
Se GKE rileva che un cluster utilizza una funzionalità che verrà rimossa in una versione secondaria imminente di Kubernetes, gli upgrade automatici del cluster alla versione secondaria successiva vengono messi in pausa e GKE condivide un'informazione e un consiglio sulla ritiro.
Che cosa succede quando GKE mette in pausa gli upgrade automatici?
Se GKE rileva l'utilizzo di un'API o di una funzionalità deprecata, mette in pausa gli upgrade automatici per impedire che venga eseguito l'upgrade del cluster 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 corrente. Ad esempio, se un cluster è in versione 1.21.11-gke.1100 e contiene 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 con patch, 1.21.11-gke.1900.
Poiché GKE non può garantire che tutto l'utilizzo venga rilevato, non può garantire che gli upgrade vengano sempre messi in pausa quando viene utilizzata una funzionalità o un'API ritirata. Per assicurarti che non venga eseguito l'upgrade di un cluster, devi utilizzare le esclusioni dalla manutenzione.
Quando GKE riprende gli upgrade automatici?
Se per 30 giorni GKE non rileva l'utilizzo della funzionalità ritirata o delle chiamate alle API ritirate, viene eseguito l'upgrade automatico del cluster se la versione secondaria successiva è il target di upgrade automatico per il cluster nel canale di rilascio del cluster e il cluster non presenta altri fattori che impediscono gli upgrade, ad esempio un'esclusione dalla manutenzione attiva. Per sapere quando la versione minore diventa un obiettivo 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 i target di upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster (anteprima).
Se GKE continua a rilevare l'utilizzo della funzionalità ritirata nel cluster, mantiene il cluster nella versione secondaria corrente fino alla data di ritiro del supporto della versione.
Le date di fine del supporto delle versioni secondarie sono disponibili nel Piano di rilascio. Poiché la data di fine dell'assistenza per una versione secondaria dipende dall'iscrizione al canale di rilascio, assicurati di fare riferimento alla data corretta che rispecchi il canale di rilascio del tuo cluster:
- Canali di rilascio diversi da quello esteso: se il cluster è registrato nei canali Rapido, Regolare e Stabile o non è registrato in un canale di rilascio, questa data indica il termine del supporto standard della versione secondaria.
- Canale esteso: se il cluster è registrato nel canale esteso, GKE non eseguirà l'upgrade automatico 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 la sezione sugli upgrade automatici al termine del supporto.
Che cosa sono gli approfondimenti e i consigli relativi al ritiro?
Se GKE rileva che un cluster utilizza una funzionalità rimossa in una versione secondaria futura di Kubernetes, condivide un approfondimento e un consiglio sulla ritirata, avvisandoti dell'utilizzo da parte del cluster di una funzionalità ritirata. Questa informazione fornisce informazioni sull'ultimo utilizzo rilevato e su ulteriori dettagli a seconda del tipo di ritiro. Per scoprire come visualizzare queste informazioni, consulta Visualizzare approfondimenti e consigli sulla deprecazione.
Valutare e mitigare l'esposizione alle prossime deprecazioni di Kubernetes
GKE fornisce guide alla migrazione che spiegano come eseguire la migrazione dalle API e dalle funzionalità ritirate a quelle compatibili con la versione minore imminente. Per un elenco delle deprecazioni imminenti e delle relative guide alla migrazione, consulta Informazioni sulle deprecazioni di Kubernetes.
Sebbene GKE condivida informazioni sui cluster che ha rilevato essere 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.
Prima di eseguire l'upgrade del cluster alla versione secondaria successiva, devi valutare in modo indipendente l'esposizione del tuo ambiente cluster a eventuali ritiri imminenti. Puoi esercitare il controllo sulla procedura 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 versione minore successiva.
Risolvere l'esposizione ai ritiri di Kubernetes
Puoi intervenire esaminando le ritiri previsti. Visualizza approfondimenti e suggerimenti sul ritiro per valutare se il tuo cluster è esposto e utilizza le guide alla migrazione per mitigare l'esposizione prima che l'ultima versione minore disponibile che supporta la funzionalità raggiunga il termine del supporto.
Dopo che hai apportato modifiche per interrompere l'utilizzo di API o funzionalità ritirate nel tuo cluster, GKE attende 30 giorni senza rilevare l'utilizzo di API o funzionalità ritirate, quindi sblocca gli upgrade automatici. Gli upgrade automatici vengono eseguiti in base alla pianificazione dei rilasci.
Puoi anche eseguire l'upgrade del cluster manualmente se hai verificato che l'upgrade non causa interruzioni nell'ambiente del cluster. Per farlo, crea prima un cluster di test e controlla 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 aggiornamenti 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 sul ritiro di Kubernetes
Le sezioni seguenti forniscono informazioni sui ritiri in corso, incluse le guide che spiegano come eseguire la migrazione a funzionalità o API compatibili con le versioni minori di Kubernetes disponibili. Puoi controllare queste tabelle per verificare se GKE rileva e registra l'utilizzo con approfondimenti e consigli.
Queste tabelle forniscono informazioni solo sui ritiri in corso e omettono le informazioni precedentemente incluse per le funzionalità o le API ritirate con le versioni che hanno superato ampiamente la data di fine del supporto.
Ritiro delle funzionalità di Kubernetes
La tabella seguente illustra il ritiro delle funzionalità di GKE in corso, nonché la versione in cui queste funzionalità non sono più supportate:
| Nome | Ritirato | Rimossa | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|---|---|
| Modalità cgroupv1 di Linux | Versione GKE 1.31 | 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 algoritmo SHA-1 | Versione GKE 1.24 | Versione GKE 1.29 | I certificati TLS SHA-1 supportano la rimozione | Sì |
| Plug-in di autenticazione integrato per i client Kubernetes | Versione GKE 1.22 | Versione GKE 1.25 | Plugin di autenticazione deprecato per i client Kubernetes | No |
| PodSecurityPolicy | Versione GKE 1.21 | Versione GKE 1.25 | Ritiro di PodSecurityPolicy | Sì |
| Immagini dei nodi basate su Docker | Versione GKE 1.20 | Versione GKE 1.24 | Deprecation delle immagini dei nodi Docker | Sì |
| Campo Common Name X.509 nei certificati webhook | Versione GKE 1.19 | Versione GKE 1.23 | Ritiro del campo CN dei certificati Webhook | Sì |
Ritiro delle API Kubernetes
La tabella seguente fornisce una panoramica delle API Kubernetes deprecate e non più pubblicate, ordinate in base alla versione di Kubernetes:
| Versione di Kubernetes | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|
| 1,29 | API deprecate di Kubernetes 1.29 | Sì |
| 1,27 | API deprecate di Kubernetes 1.27 | Sì |
| 1,26 | API deprecate di Kubernetes 1.26 | Sì |
| 1,25 | API Kubernetes 1.25 deprecate | Sì |
| 1,22 | API deprecate di Kubernetes 1.22, API beta di Kubernetes Ingress rimosse in GKE 1.23 |
Sì |
Altre funzionalità ritirate
La seguente tabella fornisce informazioni sulle deprecazioni e sulle rimozioni causate da altri provider a monte che non fanno parte del progetto open source Kubernetes.
| Nome | Ritirato | Rimossa | 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 |