Questa pagina spiega in che modo i ritiri di funzionalità e API sono causati da Kubernetes e altre dipendenze funzionano con Google Kubernetes Engine (GKE). Questo include anche tabelle con informazioni specifici ritiri upstream. Per scoprire come visualizzare la tua esposizione a prossimi ritiri, vedere Visualizzazione di approfondimenti e consigli sul ritiro.
Cosa sono i ritiri di Kubernetes?
I cluster GKE sono basati su Kubernetes di gestione dei cluster open source. Il set di funzionalità di Kubernetes si evolve nel tempo e proprio come nel tempo vengono introdotte nuove funzioni, a volte un potrebbe dover essere rimossa. In alternativa, una funzionalità può migliorare dalla fase beta a quella GA. Criteri di ritiro di Kubernetes assicura che gli utenti abbiano un processo prevedibile, in modo da poter abbandonare la una funzionalità o un'API ritirata prima della rimozione.
Dopo il periodo di ritiro, quando una funzione o un'API viene rimossa, non potrai più lo userai 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 Microsoft e le immagini dei nodi Ubuntu supportate da Canonical. Quando questi upstream ritirano o interrompono il supporto di una funzionalità, GKE potrebbe per rimuovere la funzionalità corrispondente. Le tabelle in questa pagina forniscono inoltre informazioni su ritiri e rimozioni imminenti causati da upstream senza 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. Nei prossimi scoprirai come GKE semplifica questo processo rilevamento dell'utilizzo di funzionalità e API Kubernetes deprecate, condivisione di insight sull'utilizzo e fornendo consigli su come eseguire la migrazione alle funzionalità compatibili con le versioni secondarie future.
Se GKE rileva che un cluster sta utilizzando una funzionalità che rimosso in un'imminente versione secondaria di Kubernetes, gli upgrade automatici del cluster le versioni secondarie successive sono in pausa e GKE condivide un ritiro insight e suggerimenti.
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 è versione 1.21.11-gke.1100 e include chiamate alle API deprecate che vengono rimosse da 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 vengano rilevati tutti gli utilizzi, non possiamo garantire che gli upgrade vengano sempre messi in pausa quando una funzionalità deprecata o dell'API. Per assicurarti che non venga eseguito l'upgrade di un cluster, devi utilizzare le esclusioni di manutenzione.
Quando GKE ripristina gli upgrade automatici?
Quando GKE non rileva l'utilizzo della funzionalità deprecata o 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 fine del ciclo di vita della versione data. Dopo questa data, disponibile nella Pianificazione delle release, sarà viene eseguito automaticamente l'upgrade del cluster alla versione secondaria successiva dell'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 informazioni e consigli sul ritiro, che ti informa dell'utilizzo di una funzionalità deprecata da parte del tuo cluster. Questo approfondimento fornisce informazioni sull'ultimo utilizzo rilevato e ulteriori dettagli a seconda sul tipo di ritiro. Per scoprire come visualizzare queste informazioni, consulta Visualizzazione di approfondimenti e consigli sul ritiro.
Valutare e mitigare l'esposizione ai prossimi ritiri di Kubernetes
GKE fornisce guide alla migrazione che ti spiegano come eseguire la migrazione. da funzionalità e API deprecate a quelle compatibili con il minore successivo completamente gestita. Per un elenco dei ritiri imminenti e delle relative guide alla migrazione, vedi Informazioni sui ritiri di Kubernetes.
GKE condivide insight sui cluster che ha rilevato soggetti a un ritiro, il rilevamento di tutte le esposizioni a 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 sul processo di upgrade scegliendo un canale di rilascio, tramite periodi di manutenzione ed esclusioni. o eseguire l'upgrade manuale dei cluster se hai stabilito che non sono esposte a ritiri alla prossima una versione secondaria.
Risolvere l'esposizione ai deprecazioni di Kubernetes
Puoi prendere provvedimenti esaminando i prossimi ritiri. Visualizza approfondimenti e consigli sul ritiro. per valutare se il cluster è esposto e utilizza le guide alla migrazione per mitigare di esposizione prima che l'ultima versione secondaria disponibile che supporta la funzionalità raggiunga alla fine del ciclo di vita.
Dopo aver apportato modifiche per interrompere l'utilizzo di API o funzionalità deprecate in cluster, GKE attende fino a quando non ha più osservato l'uso le API o le funzionalità ritirate per 30 giorni e poi sblocca gli upgrade automatici. Gli upgrade automatici vengono eseguiti in base programma delle release.
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. Automatica gli upgrade rimangono in pausa finché non esegui la migrazione dalle funzionalità deprecate e GKE non rileva l'utilizzo delle funzionalità deprecate per 30 giorni consecutivi.
Informazioni sui ritiri di Kubernetes
Le seguenti sezioni forniscono informazioni sui ritiri in corso, tra cui: guide che spiegano come eseguire la migrazione a funzionalità o API compatibili con Versioni secondarie di Kubernetes. 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 ciclo di vita.
Ritiri 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? |
|---|---|---|---|---|
| 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ù 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 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 che sono causata da altri provider upstream che non fanno parte del provider progetto di origine.
| 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 |