API Kubernetes Ingress Beta rimosse in GKE 1.23

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

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

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

In entrata (disponibile fino alla versione 1.23 per i cluster creati con la versione 1.21 o precedente)

Le versioni beta dell'API (extensions/v1beta1 e networking.k8s.io/v1beta1) di Non sono più disponibili Ingress per la versione che è in esecuzione per i cluster GKE 1.22 o successiva se il cluster è stato creato nella versione 1.22 o successiva.

Tuttavia, per i cluster creati su GKE 1.21 o versioni precedenti e sottoposti a upgrade a 1.22 con la versione della patch 1.22.7-gke.300 o successive, puoi comunque utilizzare le versioni beta dell'API fino a quando non viene eseguito l'upgrade del cluster alla versione 1.23. Si tratta di un un'eccezione per i cluster meno recenti in modo da darti più tempo per eseguire ai cluster di utilizzare queste versioni dell'API che vengono rimosse di Kubernetes nella versione 1.22.

Tutti i cluster che eseguono GKE versione 1.23 e successive non supporteranno più le API beta Ingress deprecate. I manifest che utilizzano queste versioni dell'API possono non verranno più applicati. Gli oggetti precedentemente mantenuti in memoria 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 in modo che utilizzino la versione dell'API networking.k8s.io/v1.

  • Per le modifiche importanti della versione dell'API GA, consulta la seguente tabella:

    Campo Cambia
    spec.backend Rinominato in spec.defaultBackend.
    backend serviceName Rinominato in service.name.
    servicePort I campi servicePort di backend numerici vengono rinominati in service.port.number. Backend della stringa servicePort vengono rinominati in service.port.name.
    pathType Ora obbligatoria per ogni percorso specificato. Il valore può essere: Prefix, Exact o ImplementationSpecific. Per corrispondere il comportamento v1beta1 indefinito, usa 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 l'osservabilità di Google Cloud abilitata 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 le API deprecate

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

Puoi anche utilizzare gli audit log per trovare i client che effettuano chiamate alle API ritirate.

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 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 le API ritirate.

Individua 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 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 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 gli agenti di terze parti che effettuano chiamate alle API ritirate nel tuo cluster.

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

  1. Rivolgiti al 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 puoi eseguire l'upgrade devi verificare se è necessario eseguire l'upgrade di GKE con le API deprecate rimosse interrompere il servizio.

Ti consigliamo di eseguire questo upgrade e la versione GKE eseguire l'upgrade di un cluster di gestione temporanea per monitorare le interruzioni prima di eseguire l'upgrade cluster di produzione.

Preparazione all'upgrade alla versione 1.23

Non è necessario eliminare e ricreare gli oggetti API. Tutti gli oggetti API esistenti memorizzati 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 Kubernetes 1.23. Scopri di più nel "Cosa fare" sezione della Guida alla migrazione delle API deprecate di Kubernetes.

Puoi visualizzare approfondimenti e consigli sul ritiro per determinare se il cluster utilizza una funzionalità o un'API Kubernetes che ritirato. Cerca insight e suggerimenti 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 le API per user agent, non per la configurazione degli oggetti Kubernetes.

Aggiorna i cluster interessati dal ritiro

Per eseguire l'upgrade dei cluster interessati dal ritiro, svolgi i seguenti passaggi:

  1. Controlla quali user agent utilizzano le API deprecate nella insight sul ritiro o log.
  2. Aggiorna gli user agent che utilizzano le API deprecate in modo che utilizzino l'API supportata e versioni successive.
  3. Aggiornare all'ultima versione qualsiasi software di terze parti che chiama le API ritirate e versioni successive.
  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 agenti utente, GKE attende 30 giorni senza rilevare l'utilizzo di API ritirate, quindi sblocca gli upgrade automatici. Gli upgrade automatici vengono eseguiti in base programma 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 del servizio. Se l'upgrade non causa e interruzioni, eseguire l'upgrade manuale del cluster.

Risorse

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