Questa pagina spiega come funzionano i ritiri di funzionalità e API causati da Kubernetes e altre dipendenze con Google Kubernetes Engine (GKE). Questo include anche tabelle con informazioni specifici ritiri upstream. 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 su Kubernetes di gestione dei cluster open source. L'insieme di funzionalità di Kubernetes si evolve nel tempo e proprio come nel tempo vengono introdotte nuove funzioni, a volte un potrebbe essere necessario rimuovere la funzionalità. In alternativa, una funzionalità può passare dalla fase beta alla fase GA. I criteri di ritiro di Kubernetes garantiscono agli utenti una procedura prevedibile in modo che possano 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 funzionalità e alle API Kubernetes, GKE offre anche Funzionalità basate su altri provider, come le immagini dei nodi Windows supportate 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 delle applicazioni su GKE prevede una responsabilità condivisa tra te e GKE.
Come utente, devi valutare e mitigare l'esposizione a funzionalità deprecate e API 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 una funzionalità o un'API deprecata, GKE mette in pausa gli upgrade automatici per impedire l'upgrade del cluster a uno stato non funzionante. Upgrade al successiva Versione secondaria di Kubernetes sono in pausa, ma GKE continua a fornire upgrade delle patch al cluster nella versione secondaria attuale. 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 patch versione, 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 di manutenzione.
Quando GKE ripristina gli upgrade automatici?
Se per 30 giorni GKE non rileva l'utilizzo della funzionalità deprecata o delle chiamate alle API deprecate, viene eseguito automaticamente l'upgrade del cluster se la versione secondaria successiva è la versione predefinita nel canale di rilascio del cluster. Per vedere quando la versione secondaria diventa predefinita nel canale di rilascio del cluster, consulta la pianificazione delle release.
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 per la fine del supporto delle versioni secondarie sono disponibili nella sezione Pianificazione. Poiché la data di fine del supporto per una versione minore 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 Esteso: se il cluster è registrato nella Canali rapidi, regolari e stabili oppure il cluster non è registrato in una release questo canale, questa data rappresenta la fine dello standard assistenza.
- Canale esteso: se il cluster è registrato nella sezione canale, GKE non eseguirà automaticamente l'upgrade del cluster dall'account fino alla fine dell'estensione assistenza.
Una volta raggiunta questa data, verrà eseguito automaticamente l'upgrade del cluster alla data e l'ambiente del cluster potrebbero essere compromessi man mano che è 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 sul 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. Questo approfondimento fornisce informazioni sull'ultimo utilizzo rilevato e ulteriori dettagli a seconda sul 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 ti spiegano come eseguire la migrazione. da funzionalità e API deprecate a quelle compatibili con il passaggio successivo completamente gestita. Per un elenco dei ritiri imminenti e delle relative guide alla migrazione, vedi Informazioni sui ritiri 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 funzione deprecata non è stata utilizzata nella ultimi 30 giorni, GKE non rileva alcun utilizzo, fornisce un insight non viene generato un suggerimento.
Devi valutare in modo indipendente l'esposizione del tuo ambiente cluster a qualsiasi i ritiri imminenti prima di eseguire l'upgrade del cluster alla versione secondaria successiva. 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.
Risoluzione dell'esposizione ai deprecazioni di Kubernetes
Puoi intervenire esaminando le ritiri imminenti. 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 che vengano utilizzate API o funzionalità ritirate, quindi sblocca gli upgrade automatici. Gli upgrade automatici vengono eseguiti in base alla pianificazione dei rilasci.
Puoi anche eseguire manualmente l'upgrade del cluster se hai verificato che l'upgrade non provoca interruzioni del dell'ambiente cluster Kubernetes. Puoi farlo creando prima un cluster di test per verificare se l'upgrade causa interruzioni del servizio. 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 vedere se GKE rileva e segnala l'utilizzo tramite approfondimenti e consigli.
Queste tabelle forniscono solo informazioni sui ritiri in corso e omettono in precedenza includevano informazioni su funzionalità o API deprecate con versioni che hanno superato di molto la data di fine del supporto.
Ritiro delle funzionalità di Kubernetes
La seguente tabella illustra i ritiri in corso delle funzionalità GKE, nonché la versione in cui queste funzionalità non sono più supportate:
| Nome | Ritirato | Rimossa | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|---|---|
| Modalità cgroupv1 su 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 l'algoritmo SHA-1 | Versione GKE 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 | Plugin di autenticazione deprecato per i client Kubernetes | No |
| PodSecurityPolicy | GKE versione 1.21 | Versione GKE 1.25 | Ritiro di PodSecurityPolicy | Sì |
| Immagini dei nodi basate su Docker | GKE versione 1.20 | GKE versione 1.24 | Deprecation delle immagini dei nodi Docker | Sì |
| Campo Common Name X.509 nei certificati webhook | GKE versione 1.19 | Versione GKE 1.23 | Ritiro dei campi CN dei certificati webhook | Sì |
Ritiri dell'API Kubernetes
La tabella seguente fornisce una panoramica delle API Kubernetes deprecate e non più pubblicati, ordinati per versione 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 di 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 deprecate di Kubernetes 1.22, API beta di Kubernetes Ingress rimosse in GKE 1.23 |
Sì |
Ritiri di altre funzionalità
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 |