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 nel tempo vengono introdotte nuove funzionalità, a volte potrebbe essere necessario rimuovere una caratteristica. In alternativa, una funzionalità può passare dalla fase beta alla fase GA. I criteri di ritiro di Kubernetes garantiscono che gli utenti abbiano un processo prevedibile che consenta loro di migrare da un'API o una funzionalità 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 inoltre 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 che venga eseguito 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?
Una volta che GKE non rileva l'utilizzo della funzionalità deprecata o 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 sul cluster, GKE mantiene il cluster nella versione secondaria attuale fino alla data di fine del ciclo di vita della versione. Una volta raggiunta questa data, disponibile nella pianificazione del rilascio, viene eseguito automaticamente l'upgrade del cluster alla versione secondaria successiva e l'ambiente cluster potrebbe essere compromesso poiché la funzionalità rimossa è ancora in uso. Per saperne di più, consulta Domande frequenti sul supporto della versione.
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 o eseguire l'upgrade manuale dei cluster se hai stabilito che non sono esposti a ritiri nella versione secondaria successiva.
Risolvere l'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 ciclo di vita.
Dopo aver apportato modifiche per interrompere l'utilizzo di API o funzionalità deprecate nel tuo cluster, GKE attende per 30 giorni fino a quando non rileva più l'utilizzo di API o 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 confermato 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, 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 deprecate con versioni che hanno superato in modo significativo la data di fine del ciclo di vita.
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 | Deprecato | Rimossa | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|---|---|
| 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 | Deprecato | Rimossa | Ulteriori informazioni | GKE rileva e segnala l'utilizzo? |
|---|---|---|---|---|
| Immagini dei nodi del canale semestrale (SAC) di Windows Server | N/A | 9 agosto 2022 | Fine del servizio SAC di Windows Server | No |