Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Cloud de Confiance di S3NS. Per maggiori dettagli, consulta Differenze rispetto a Google Cloud.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

API Kubernetes 1.26 deprecate

Autopilot Standard

Questa pagina spiega come preparare i cluster per gli upgrade a GKE versione 1.26. Puoi trovare i client API che effettuano chiamate alle API obsolete rimosse nella versione 1.26 e aggiornarli in modo che utilizzino le API GA. Per informazioni più dettagliate, consulta la guida alla migrazione delle API deprecate di Kubernetes.

API rimosse nella versione 1.26

Le API deprecate nella versione 1.26 di Kubernetes sono API beta che sono state promosse alla disponibilità generale (ad esempio v2) o da una versione beta a un'altra (ad esempio, da v1beta1 a v1beta2). Le API GA offrono garanzie di compatibilità a lungo termine e devono essere utilizzate al posto delle API beta deprecate.

È possibile interagire con tutti gli oggetti esistenti per le API di cui è stato eseguito l'upgrade alle nuove versioni utilizzando le API aggiornate.

Risorse per il controllo del flusso

La versione flowcontrol.apiserver.k8s.io/v1beta1 dell'API di FlowSchema e PriorityLevelConfiguration non viene più pubblicata a partire dalla v1.26.

Esegui la migrazione dei manifest e dei client API per utilizzare la versione dell'API flowcontrol.apiserver.k8s.io/v1beta3, disponibile dalla versione 1.26. Tutti gli oggetti persistenti esistenti sono accessibili utilizzando la nuova API.

HorizontalPodAutoscaler

La versione autoscaling.apiserver.k8s.io/v2beta2 dell'API HorizontalPodAutoscaler non viene più servita a partire dalla v1.26.

Esegui la migrazione dei manifest e dei client API per utilizzare la versione autoscaling.apiserver.k8s.io/v2 dell'API, disponibile dalla versione 1.23. Tutti gli oggetti persistenti esistenti sono accessibili utilizzando la nuova API.

Preparazione dell'upgrade alla versione 1.26 in corso…

Non è necessario eliminare e ricreare nessuno degli oggetti API. Tutti gli oggetti API persistenti esistenti per le API di cui è stata eseguita la transizione alla disponibilità generale possono già essere letti e aggiornati utilizzando le nuove versioni dell'API.

Tuttavia, ti consigliamo di eseguire la migrazione dei client e dei manifest prima di eseguire l'upgrade a Kubernetes 1.26. Per saperne di più, consulta la guida alla migrazione delle API deprecate di Kubernetes.

Puoi visualizzare approfondimenti e consigli sul ritiro per determinare se il tuo cluster utilizza API deprecate di Kubernetes 1.26. GKE genera approfondimenti sul ritiro quando gli user agent chiamano API ritirate, non dalla configurazione degli oggetti Kubernetes.

Trovare cluster che utilizzano API ritirate

Puoi scoprire quali cluster utilizzano API obsolete dagli approfondimenti sul ritiro. Gli approfondimenti sull'obsolescenza forniscono anche informazioni quali i client API che chiamano le API obsolete nel tuo cluster.

Puoi anche utilizzare i log di controllo per scoprire quali client effettuano chiamate alle API ritirate.

Individuare i client API che effettuano chiamate di scrittura alle API deprecate

Per i cluster con Google Cloud Observability abilitato, puoi utilizzare la seguente query Log di controllo dell'attività di amministrazione per mostrare l'utilizzo delle API ritirate da user agent non gestiti da Google:

resource.type="k8s_cluster"
labels."k8s.io/removed-release"="DEPRECATED_API_MINOR_VERSION"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")

Sostituisci DEPRECATED_API_MINOR_VERSION con la versione secondaria in cui viene rimossa l'API deprecata, ad esempio 1.22.

Gli audit log delle attività di amministrazione vengono attivati automaticamente per i cluster GKE. Con questa query, i log mostrano gli user agent che effettuano chiamate di scrittura alle API ritirate.

Individuare i client API che effettuano chiamate di lettura alle API deprecate

Per impostazione predefinita, i log di controllo mostrano solo le chiamate di scrittura alle API ritirate. Per visualizzare anche le chiamate di lettura alle API ritirate, configura gli audit log di accesso ai dati.

Segui le istruzioni per configurare gli audit log di accesso ai dati con la console Cloud de Confiance . Nella console Cloud de Confiance , seleziona l'API Kubernetes Engine. Nella scheda Tipi di log del riquadro delle informazioni, seleziona Admin Read e Data Read.

Con questi log abilitati, ora puoi utilizzare la query originale per visualizzare sia le chiamate di lettura sia le chiamate di scrittura alle API ritirate.

Aggiornamento dei componenti di terze parti

Approfondimenti sul ritiro potrebbero mostrare risultati per agenti di terze parti che effettuano chiamate ad API ritirate nel tuo cluster.

Per risolvere il problema degli agenti di terze parti che chiamano API ritirate, ti consigliamo di seguire le seguenti best practice:

Rivolgiti al fornitore del software di terze parti per una versione aggiornata.
Esegui l'upgrade del software di terze parti all'ultima versione. Se non riesci ad eseguire l'upgrade del software, devi verificare se l'upgrade di GKE alla versione con le API ritirate rimosse interromperebbe il tuo servizio.

Ti consigliamo di eseguire questo upgrade e l'upgrade della versione GKE su un cluster di staging per monitorare eventuali interruzioni prima di eseguire l'upgrade dei cluster di produzione.

Aggiorna i cluster interessati dai ritiri

Per eseguire l'upgrade dei cluster interessati dai ritiri, segui questi passaggi:

Controlla quali user agent utilizzano le API ritirate nei log.
Aggiorna gli user agent che utilizzano le API ritirate in modo che utilizzino le versioni API supportate.
Aggiorna all'ultima versione qualsiasi software di terze parti che chiama API ritirate.
Esegui l'upgrade di un cluster di test e testa l'applicazione in un ambiente di test prima di eseguire l'upgrade del cluster di produzione per ridurre il rischio di interruzioni quando le API ritirate non sono più disponibili.
Se non riesci ad aggiornare uno user agent interessato, esegui l'upgrade di un cluster di test separato per verificare se l'upgrade causa interruzioni. Se l'upgrade non causa interruzioni, puoi eseguire l'upgrade del cluster manualmente.
Dopo aver aggiornato tutti gli user agent, GKE attende 30 giorni senza osservare l'utilizzo di API ritirate, quindi sblocca gli upgrade automatici. Gli upgrade automatici vengono eseguiti in base al programma delle pubblicazioni.

Risorse

Per saperne di più, consulta la documentazione OSS Kubernetes: