API Kubernetes Ingress beta rimosse in GKE 1.23

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

Le API Ingress beta deprecate e rimosse in Kubernetes versione 1.22 sono API beta precedenti che sono passate da beta (v1beta1) a GA (v1). Le API GA offrono garanzie di compatibilità a lungo termine e dovrebbero 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 in data 1.21 o versioni precedenti)

Le versioni beta dell'API (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 nella versione 1.22 o successive.

Tuttavia, per i cluster creati in GKE versione 1.21 o precedenti e con upgrade alla versione 1.22 nella versione patch 1.22.7-gke.300 o successive, puoi comunque utilizzare le versioni beta dell'API fino a quando il cluster non viene aggiornato alla versione 1.23. Questa è un'eccezione una tantum per i cluster meno recenti per darti più tempo per eseguire la migrazione dei tuoi cluster dall'utilizzo di queste versioni API, che sono state rimosse da Kubernetes open source nella versione 1.22.

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

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

  • Fai riferimento alla seguente tabella che descrive le modifiche significative nella versione dell'API GA:

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

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

File 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

File 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 in cui è abilitata l'osservabilità di Google Cloud 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")

Trova i cluster utilizzando API deprecate

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

Puoi utilizzare gli audit log per individuare i client che effettuano chiamate alle API deprecate.

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

Per i cluster in cui è abilitata l'Observabilità di Google Cloud, puoi utilizzare la seguente query del log di controllo dell'attività di amministrazione per mostrare l'utilizzo di API deprecate da user agent non gestite 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 l'API deprecata viene rimossa, ad esempio 1.22.

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

Individua i client API che effettuano chiamate di lettura ad API deprecate

Per impostazione predefinita, i log di controllo mostrano solo le chiamate di scrittura alle API deprecate. Per mostrare anche le chiamate di lettura alle API deprecate, 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 nel 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 deprecate.

Upgrade dei componenti di terze parti

Gli approfondimenti sul ritiro potrebbero mostrare risultati per gli agenti di terze parti che effettuano chiamate alle API deprecate nel tuo cluster.

Per risolvere questi approfondimenti, prova a svolgere i seguenti passaggi:

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

Ti consigliamo di eseguire questo upgrade e la versione di GKE su un cluster di gestione temporanea 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 gli 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 di client e manifest prima di eseguire l'upgrade a Kubernetes 1.23. Scopri di più nella sezione"Cosa fare" della guida alla migrazione delle API deprecate da Kubernetes.

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

Gli insight sul ritiro si basano sulle chiamate API osservate alle API deprecate dagli user agent, non sulla configurazione degli oggetti Kubernetes.

Aggiorna i cluster interessati da deprecazioni

Per eseguire l'upgrade dei cluster interessati da deprecazioni, segui questi passaggi:

  1. Controlla quali user agent utilizzano le API deprecate negli insight sul ritiro o nei log.
  2. Aggiorna gli user agent che utilizzano le API deprecate in modo che utilizzino le versioni delle API supportate.
  3. Aggiorna qualsiasi software di terze parti che chiama le API deprecate 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. Dopo aver aggiornato tutti gli user agent, GKE attende finché non ha più osservato l'utilizzo di API deprecate per 30 giorni, quindi sblocca gli upgrade automatici. Gli upgrade automatici procedino in base alla pianificazione delle release.
  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 manuale del cluster.

Risorse

Ulteriori informazioni sono disponibili nella documentazione del software open source Kubernetes: