Questa pagina spiega in che modo le deprecazioni di funzionalità e API causate da Kubernetes e altre dipendenze funzionano con Google Kubernetes Engine (GKE). Questa pagina include anche tabelle con informazioni su ritiri upstream specifici. Per scoprire come visualizzare la tua esposizione ai prossimi ritiri, consulta Visualizzare gli approfondimenti e i suggerimenti sul ritiro.
Cosa sono le deprecazioni 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, potrebbe essere necessario rimuovere una funzionalità. In alternativa, una funzionalità può passare dalla fase beta alla fase GA. Il criterio di ritiro di Kubernetes garantisce che gli utenti dispongano di un processo prevedibile in modo da poter eseguire la migrazione da una funzionalità o un'API deprecata prima della rimozione.
Dopo il periodo di deprecazione, quando una funzionalità o un'API viene rimossa, non puoi 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, ad esempio immagini dei nodi Windows supportate da Microsoft e immagini dei nodi Ubuntu supportate da Canonical. Quando questi provider upstream ritirano o terminano il supporto per una funzionalità, GKE potrebbe dover rimuovere la funzionalità corrispondente. Le tabelle in questa pagina forniscono anche informazioni sulle imminenti rimozioni e rimozioni causate da dipendenze upstream diverse da Kubernetes.
Funzionamento dei ritiri di Kubernetes con GKE
L'esecuzione delle applicazioni su GKE prevede una responsabilità condivisa tra te e GKE.
In qualità di utente, devi valutare e mitigare qualsiasi esposizione a funzionalità e API deprecate che verranno rimosse nelle future versioni secondarie di Kubernetes. Nelle prossime sezioni scoprirai in che modo GKE semplifica questo processo rilevando l'utilizzo di funzionalità e API Kubernetes deprecate, condividendo insight su questo utilizzo e fornendo consigli 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 è stata rimossa in una versione secondaria imminente 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 una funzionalità o di un'API deprecata, GKE mette in pausa gli upgrade automatici per evitare che venga eseguito l'upgrade del cluster a uno stato non funzionante. Gli upgrade alla prossima versione secondaria di Kubernetes vengono messi in pausa, ma GKE continua a fornire upgrade delle patch al cluster nell'attuale versione secondaria. Ad esempio, se un cluster si trova nella versione 1.21.11-gke.1100 e include chiamate alle 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 della patch, 1.21.11-gke.1900.
Poiché GKE non può garantire che venga rilevato tutto l'utilizzo, GKE 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 di manutenzione.
Quando GKE riprende gli upgrade automatici?
Se GKE non ha rilevato l'utilizzo della funzionalità deprecata o delle chiamate alle API deprecate per 30 giorni, 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à deprecata nel cluster, GKE mantiene il cluster sulla versione secondaria attuale fino alla data di fine del ciclo di vita della versione. Una volta raggiunta questa data, disponibile nella pianificazione delle release, 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 ulteriori informazioni, leggi le Domande frequenti sul supporto delle versioni.
Che cosa sono gli approfondimenti e i consigli sul ritiro?
Se GKE rileva che un cluster utilizza una funzionalità che è stata rimossa in una versione secondaria imminente di Kubernetes, GKE condivide un approfondimento e un consiglio sul ritiro, che ti informano dell'utilizzo di una funzionalità deprecata da parte del tuo cluster. Questo insight fornisce informazioni sull'ultimo utilizzo rilevato e ulteriori dettagli, a seconda del tipo di ritiro. Per scoprire di più sulla visualizzazione di queste informazioni, consulta Visualizzare gli insight e i suggerimenti sul ritiro.
Valutare e mitigare l'esposizione alle imminenti deprecazioni di Kubernetes
GKE fornisce guide alla migrazione che spiegano come eseguire la migrazione dalle funzionalità e dalle API deprecate a quelle compatibili con la prossima versione secondaria. Per un elenco dei prossimi ritiri e delle relative guide alla migrazione, consulta Informazioni sui ritiri di Kubernetes.
Sebbene GKE condivida insight sui cluster che ha rilevato sono esposti a un ritiro, il rilevamento di tutte le esposizioni a imminenti deprecazioni 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 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 oppure eseguire l'upgrade manuale dei cluster se hai stabilito che non sono esposti a deprecazioni nella versione secondaria successiva.
Risolvere l'esposizione alle deprecazioni di Kubernetes
Per intervenire, esamina 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 ciclo di vita.
Dopo aver apportato modifiche per interrompere l'utilizzo delle API o delle funzionalità deprecate nel cluster, GKE attende fino a quando non ha osservato più l'utilizzo di API o funzionalità deprecate per 30 giorni, quindi sblocca gli upgrade automatici. Gli upgrade automatici procedino in base alla pianificazione delle release.
Puoi anche eseguire l'upgrade manuale del cluster se hai verificato che l'upgrade non causa interruzioni dell'ambiente del cluster. Per farlo, crea innanzitutto 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 delle funzionalità deprecate e GKE non rileva l'utilizzo di queste funzionalità per 30 giorni consecutivi.
Informazioni sui ritiri di Kubernetes
Le seguenti sezioni 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 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 che sono state deprecate con versioni che hanno superato in maniera significativa la fine del ciclo di vita.
Ritiri delle funzionalità di Kubernetes
La seguente tabella descrive i ritiri in corso delle funzionalità GKE, nonché la versione in cui queste funzionalità non sono più supportate:
| Nome | Deprecata | Elemento rimosso | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|---|---|
| Certificati TLS firmati con algoritmo SHA-1 | GKE versione 1.24 | GKE versione 1.29 | I certificati TLS SHA-1 supportano la rimozione | Sì |
| Plug-in di autenticazione integrato per i client Kubernetes | GKE versione 1.22 | GKE versione 1.25 | Plug-in di autenticazione obsoleto 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 dei campi CN dei certificati webhook | Sì |
Deprecazioni dell'API Kubernetes
La seguente tabella offre 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 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ì |
Altre funzionalità non più disponibili
La seguente tabella fornisce informazioni su deprecazioni e rimozioni causate da altri provider upstream che non fanno parte del progetto open source Kubernetes.
| Nome | Deprecata | Elemento rimosso | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|---|---|
| Immagini dei nodi del canale semestrale (SAC) di Windows Server | N/A | 9 agosto 2022 | Fine servizio SAC di Windows Server | No |