API Kubernetes 1.29 deprecate

Questa pagina spiega come preparare i cluster per gli upgrade a GKE Versione 1.29. Puoi trovare i client API che effettuano chiamate alle API deprecate rimosse in 1.29 e aggiornare questi client in modo che utilizzino le API GA. Per informazioni più dettagliate, consulta Migrazione delle API deprecate per Kubernetes .

API rimosse nella versione 1.29

Le API deprecate in Kubernetes versione 1.29 sono API beta che hanno a GA (ad esempio v2) o da una versione Beta a un'altra (per esempio, da v1beta1 a v1beta2). Le API GA offrono compatibilità a lungo termine garanzie e devono essere utilizzate al posto delle API beta ritirate.

Tutti gli oggetti esistenti per le API che sono passate a nuove versioni possono essere ha interagito utilizzando le API aggiornate.

Risorse di controllo del flusso

La versione API flowcontrol.apiserver.k8s.io/v1beta2 di FlowSchema e La gestione di PriorityLevelConfiguration non è più disponibile a partire dalla versione 1.29.

Esegui la migrazione dei manifest e dei client API per utilizzare flowcontrol.apiserver.k8s.io/v1 API, disponibile a partire dalla v1.29, oppure Versione API flowcontrol.apiserver.k8s.io/v1beta3, disponibile dalla v1.26.

Tutti gli oggetti persistenti esistenti sono accessibili con la nuova API.

La versione API flowcontrol.apiserver.k8s.io/v1 ha i seguenti elementi modifiche:

  • Il campo PriorityLevelConfiguration spec.limited.assuredConcurrencyShares viene rinominata in spec.limited.nominalConcurrencyShares e il valore predefinito è solo 30 se non specificato e il valore esplicito pari a 0 non viene modificato in 30.

La versione API flowcontrol.apiserver.k8s.io/v1beta3 ha i seguenti elementi modifiche:

  • Il campo PriorityLevelConfiguration spec.limited.assuredConcurrencyShares viene rinominato in spec.limited.nominalConcurrencyShares.

Preparazione dell'upgrade alla versione 1.29

Non è necessario eliminare e ricreare gli oggetti API. Tutti quelli esistenti gli oggetti API persistenti per le API passate a GA possono già essere letti aggiornate 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.29. Per saperne di più, consulta API Kubernetes deprecata Migrazione Google Cloud.

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

Trova i cluster utilizzando le API deprecate

Puoi trovare quali cluster utilizzano API deprecate dagli insight sul ritiro. Gli approfondimenti sulla ritiro forniscono anche informazioni quali i client API che chiamano le API ritirate nel tuo cluster.

Puoi anche utilizzare i log di controllo per sapere quali client effettuano chiamate all'ambiente deprecato su quelle di livello inferiore.

Individua client API che effettuano chiamate di scrittura ad API deprecate

Per i cluster in cui è attivata l'osservabilità di Google Cloud, puoi utilizzare la seguente query del log di controllo delle attività amministrative per mostrare l'utilizzo di API ritirate da agenti utente 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 minore in cui l'API obsoleta è stata rimossa, ad esempio 1.22.

Gli audit log per le attività di amministrazione vengono abilitati automaticamente per GKE cluster. Con questa query, i log mostrano gli agenti utente che eseguono chiamate di scrittura alle API ritirate.

Individuare i client API che effettuano chiamate di lettura ad API ritirate

Per impostazione predefinita, i log di controllo mostrano solo le chiamate di scrittura alle API deprecate. 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 Google Cloud. Nella console Google Cloud, 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 letture e scrivere chiamate alle API ritirate.

Eseguire l'upgrade dei componenti di terze parti

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

Per risolvere i problemi relativi agli agenti di terze parti che richiamano API ritirate, consigliamo di seguire le seguenti best practice:

  1. Rivolgiti al tuo fornitore del software di terze parti per una versione aggiornata.
  2. Esegui l'upgrade del software di terze parti alla versione più recente. Se non riesci eseguire l'upgrade del software, devi verificare se l'upgrade di GKE alla versione con le API deprecate rimosse, il tuo servizio verrà interrotto.

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 dal ritiro, svolgi i seguenti passaggi:

  1. Controlla quali user agent utilizzano le API obsolete nei log.
  2. Aggiorna gli user agent che utilizzano le API deprecate in modo che utilizzino l'API supportata e versioni successive.
  3. Aggiorna il software di terze parti che chiama le API ritirate alle versioni più recenti.
  4. Esegui l'upgrade di un cluster di test e testa la tua applicazione in un ambiente di test prima di eseguire l'upgrade del cluster di produzione per ridurre il rischio di interruzioni quando le API deprecate non sono più disponibili.

  5. 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 del servizio. Se l'upgrade non causa interruzione del servizio, puoi eseguire l'upgrade del cluster manualmente.

  6. Dopo aver aggiornato tutti gli user agent, GKE attende che non ha più osservato l'utilizzo di API deprecate per 30 giorni e poi sblocca upgrade automatici. Gli upgrade automatici vengono eseguiti in base alla pianificazione delle release.

Risorse

Ulteriori informazioni sono disponibili nella documentazione di Kubernetes sul software open source: