API beta di Kubernetes Ingress rimosse in GKE 1.23

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 Ingress v1 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.

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

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 nella versione 1.21 di GKE 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é non viene eseguito l'upgrade del cluster 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 vengono rimosse da Kubernetes open source nella versione 1.22.

I cluster che eseguono GKE versione 1.23 e successive non serviranno più le API beta Ingress deprecate. I manifest che utilizzano queste versioni dell'API non possono più essere applicati. Gli oggetti precedentemente persistenti 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 seguente tabella 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 del 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 non definito di v1beta1, 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 obsolete

Puoi scoprire quali cluster utilizzano API ritirate dagli insight sul ritiro. Gli approfondimenti sull'obsolescenza forniscono anche informazioni, ad esempio quali client API chiamano le API obsolete nel tuo cluster.

Puoi anche utilizzare gli audit log 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 del 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 abilitati 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 Google Cloud . Nella console Google Cloud , seleziona l'API Kubernetes Engine. Nella scheda Tipi di log del pannello 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.

Eseguire l'upgrade dei componenti di terze parti

Gli 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 i seguenti 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 puoi 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 di 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

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 consigli 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.

Aggiornamento dei 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 dell'API supportate.
  3. Aggiorna all'ultima versione qualsiasi software di terze parti che chiama API obsolete.
  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 di rilascio.
  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 di Kubernetes OSS: