API beta Ingress di Kubernetes rimosse in GKE 1.23

Autopilot Standard

Questa pagina fornisce informazioni sul ritiro e sulla rimozione delle versioni beta dell'API Ingress nella release open source di Kubernetes 1.22. GKE ha concesso un'eccezione una tantum per i cluster creati nella versione 1.21 o precedenti per continuare a utilizzare le API fino alla versione 1.23 per avere più tempo per la migrazione. Devi eseguire la migrazione dei cluster alle API v1 di Ingress prima che la versione 1.22 raggiunga la fine del ciclo di vita.

Le API beta Ingress deprecate rimosse nella versione 1.22 di Kubernetes sono ex API beta che sono state promosse da beta (v1beta1) a GA (v1). Le API GA forniscono garanzie di compatibilità a lungo termine e devono essere utilizzate al posto delle API beta deprecate.

È possibile interagire con tutti gli oggetti esistenti utilizzando le API GA.

Importante: prima di eseguire l'upgrade alla versione in cui vengono rimosse le API Ingress, devi aggiornare i client API e i manifest per utilizzare le API GA.

Ingress (disponibile fino alla versione 1.23 per i cluster creati sulla versione 1.21 o precedenti)

Le versioni API beta (extensions/v1beta1 e networking.k8s.io/v1beta1) di Ingress non vengono più pubblicate per i cluster GKE che eseguono la versione 1.22 o successive se il cluster è stato creato sulla versione 1.22 o successive.

Tuttavia, per i cluster creati su GKE 1.21 o versioni precedenti ed eseguiti l'upgrade alla versione 1.22 nella versione patch 1.22.7-gke.300 o successive, puoi comunque utilizzare le versioni API beta finché il cluster non viene aggiornato alla versione 1.23. Si tratta di un'eccezione una tantum per i cluster meno recenti per darti più tempo per eseguire la migrazione dei cluster dall'utilizzo di queste versioni API che sono state rimosse da Kubernetes open source nella versione 1.22.

I cluster che eseguono GKE versione 1.23 e successive non gestiranno più le API beta Ingress deprecate. I manifest che utilizzano queste versioni dell'API non possono più essere applicati. Gli oggetti persistenti precedenti rimangono funzionali e possono essere visualizzati e aggiornati utilizzando le nuove versioni dell'API, prima e dopo l'upgrade alla versione 1.23.

• Esegui la migrazione dei manifest e dei client API per utilizzare la versione API networking.k8s.io/v1.

• Consulta la tabella seguente, che descrive le modifiche più importanti nella versione dell'API GA:

  Campo	Cambia
  spec.backend	Rinominato in spec.defaultBackend.
  backend serviceName	Rinominato in service.name.
  servicePort	I campi numerici di backend servicePort vengono rinominati in service.port.number. I campi del backend stringa servicePort sono stati rinominati in service.port.name.
  pathType	Ora obbligatorio per ogni percorso specificato. Il valore può essere: Prefix, Exact o ImplementationSpecific. Per corrispondere al comportamento v1beta1 non definito, utilizza ImplementationSpecific.

I seguenti manifest descrivono lo stesso Ingress in v1 e v1beta1:

Manifest v1beta1

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example
spec:
  backend:
    serviceName: default-backend
    servicePort: 80
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80

Manifest v1

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example
spec:
  defaultBackend:
    service:
      name: default-backend
      port:
        number: 80
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: ImplementationSpecific
        backend:
          service:
            name: test
            port:
              number: 80

Puoi utilizzare la seguente query per i cluster con Google Cloud Observability abilitato per identificare i client che accedono alle API Ingress v1beta1:

resource.type="k8s_cluster"
resource.labels.cluster_name="$CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.request.apiVersion=("extensions/v1beta1" OR "networking.k8s.io/v1beta1")
protoPayload.request.kind="Ingress"
NOT ("kube-system")

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.

Attenzione :se abiliti log di controllo aggiuntivi, potresti incorrere in costi di logging aggiuntivi. Il volume degli audit log di accesso ai dati inseriti viene conteggiato ai fini della quota di inserimento dei log di Cloud Logging.

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 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 questi problemi, prova a seguire questi passaggi:

1. Rivolgiti al fornitore del software di terze parti per una versione aggiornata.
2. 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.

Preparazione dell'upgrade alla versione 1.23 in corso…

Non è necessario eliminare e ricreare nessuno degli oggetti API. Tutti gli oggetti API persistenti esistenti 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.23. Scopri di più nella sezione "Cosa fare" della guida alla migrazione dell'API Kubernetes deprecata.

Puoi visualizzare approfondimenti e consigli sul ritiro per determinare se il tuo cluster utilizza una funzionalità o un'API Kubernetes ritirata. Cerca approfondimenti e suggerimenti sull'utilizzo dell'API beta Ingress con il sottotipo DEPRECATION_K8S_1_22_V1BETA1_API.

Gli approfondimenti sul ritiro si basano sulle chiamate API osservate alle API ritirate da user agent, non sulla configurazione degli oggetti Kubernetes.

Avviso: se non aggiorni un client o un manifest prima dell'upgrade alla versione 1.23, non sarà in grado di leggere/modificare gli oggetti esistenti o crearne di nuovi. Il client o il manifest potrà leggere, modificare o creare oggetti solo dopo che lo avrai aggiornato.

Aggiorna i cluster interessati dai ritiri

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

1. Controlla quali user agent utilizzano le API ritirate nell'approfondimento sul ritiro o nei log.
2. Aggiorna gli user agent che utilizzano le API ritirate in modo che utilizzino le versioni API supportate.
3. Aggiorna all'ultima versione qualsiasi software di terze parti che chiama API ritirate.
4. 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.
5. 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.
6. 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.

Risorse

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

• Blog di Kubernetes: rimozioni di API per Kubernetes versione 1.22
• Note di rilascio di Kubernetes 1.22
• Guida alla migrazione delle API Kubernetes ritirate