Upgrade di Knative serving su VMware a parchi risorse

Scopri come eseguire la migrazione di Knative serving su VMware per utilizzare i fleet in modo da poter eseguire l'upgrade ad Anthos versione 1.8.

Importante: Anthos versione 1.8 richiede che tutte le installazioni precedenti di Knative serving su VMware vengano migrate per utilizzare fleet. Devi eseguire la migrazione di Knative Serving prima di eseguire l'upgrade dei cluster GKE alla versione 1.8.

Se scegli di rimanere su Anthos versione 1.7 o precedenti, non è necessario eseguire immediatamente la migrazione dell'installazione. Tuttavia, a partire da Anthos 1.8, le nuove installazioni e gli upgrade di Knative serving sono disponibili solo tramite i fleet.

Knative serving è ora un'esperienza separata dal prodotto Cloud Run gestito e viene fornito come componente del parco risorse nei cluster. L'installazione di Knative serving su VMware come componente del parco risorse consente di gestire e aggiornare l'installazione indipendentemente dagli altri componenti del parco risorse.

A livello generale, per eseguire la migrazione dell'installazione di Knative serving su VMware in modo da utilizzare un parco risorse, devi:

• Configura l'installazione di Knative serving su VMware in modo che soddisfi i requisiti del parco risorse.
• Attiva il componente della funzionalità Knative serving nel tuo parco risorse.

Tieni presente che il server API Kubernetes non è interessato da questa migrazione.

Per informazioni dettagliate su come eseguire una nuova installazione di Knative serving su VMware, consulta Installazione di Knative serving su VMware.

Prima di iniziare

Devi soddisfare i seguenti requisiti:

• Questi passaggi richiedono che il cluster Knative Serving su VMware sia registrato in un parco risorse e sia visibile nella console Google Cloud :

  Vai ai cluster GKE

• L'installazione di Knative serving su VMware si trova su un cluster che esegue Anthos versione 1.7 o precedente.

• Istio non è più supportato in Anthos 1.8. La versione 1.18 di Cloud Service Mesh deve essere installata nel parco risorse e l'installazione di Knative Serving deve essere configurata prima di eseguire l'upgrade del cluster alla versione 1.8.

  Per informazioni dettagliate sull'installazione su Google Distributed Cloud, consulta le istruzioni di Cloud Service Mesh.

  Tieni presente che Cloud Service Mesh richiede che il cluster utilizzi un tipo di macchina con almeno quattro vCPU, ad esempio e2-standard-4. Se devi modificare il tipo di macchina del cluster, consulta Migrazione dei workload in tipi di macchine diversi.

• Esistono due opzioni per la migrazione di Knative serving a Cloud Service Mesh:

  • Ottieni un nuovo indirizzo IP esterno su cui configurare il bilanciatore del carico.

  • Riutilizza l'indirizzo IP del bilanciatore del carico esistente.

    Avviso: il processo di riutilizzo di un indirizzo IP esistente per configurare Cloud Service Mesh causa circa 2 minuti di inattività della connessione. Devi pianificare di tenere conto di questo periodo durante il quale i tuoi servizi Knative serving non possono connettersi.

• Assicurati che l'ambiente a riga di comando sia configurato e aggiornato.

Eseguire la migrazione ai parchi risorse

Per eseguire l'upgrade di Anthos alla versione 1.8, devi prima eseguire i seguenti passaggi per assicurarti che la tua installazione esistente di Knative serving su VMware venga migrata all'utilizzo del componente del parco risorse.

Importante: la maggior parte dei passaggi di questa procedura richiede la configurazione di ciascuno dei cluster di utenti e, pertanto, devi ripetere diversi passaggi per ciascuno di questi cluster.

Accedere al cluster di amministrazione

Ottieni il percorso e il nome file del file kubeconfig del cluster di amministrazione e poi crea la variabile di ambiente ADMIN_KUBECONFIG:

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

Sostituisci [ADMIN_CLUSTER_KUBECONFIG] con il percorso e il nome file del file kubeconfig del cluster di amministrazione.

Configura ogni cluster utente

Importante: se hai più cluster di utenti, devi ripetere i passaggi di questa sezione per ogni cluster di utenti.

1. Crea le seguenti variabili di ambiente locali per il cluster utente:

   1. Crea la variabile di ambiente USER_KUBECONFIG con il percorso del file kubeconfig del cluster utente:

      export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
      

      Sostituisci [USER_CLUSTER_KUBECONFIG] con il percorso e il nome file del file kubeconfig del cluster utente.

   2. Crea variabili di ambiente per le seguenti configurazioni:

      • ID del tuo progetto Google Cloud .
      • Posizione delle risorse Google Cloud .
      • Nome del cluster utente.

      export PROJECT_ID=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-project-id']}")
      export CLUSTER_LOCATION=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-gcp-location']}")
      export CLUSTER_NAME=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-cluster-name']}")
      

2. Rimuovi la configurazione cloudrun dalla risorsa personalizzata OnPremUserCluster del cluster utente:

   1. Verifica che cloudRun sia impostato in OnPremUserCluster:

      $ kubectl get onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --output=jsonpath="{.spec.cloudRun}"
      

      Risultato:

      {"enabled":true}
      

   2. Rimuovi cloudRun da OnPremUserCluster:

      kubectl patch onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --type="merge" \
        --patch '{"spec": {"cloudRun": null}}'
      

   3. Verifica che cloudRun sia stato rimosso correttamente da OnPremUserCluster eseguendo lo stesso comando get e verificando che non venga restituita alcuna configurazione:

      kubectl get onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --output=jsonpath="{.spec.cloudRun}"
      

      Non dovrebbe essere presente alcun output nel terminale.

3. Aggiorna il secret create-config del cluster utente:

   1. Crea una copia YAML locale del file create-config:

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}" \
        --output=jsonpath={.data.cfg} \
        | base64 -d > "${CLUSTER_NAME}_create_secret.yaml"
      

   2. Apri il file ${CLUSTER_NAME}_create_secret.yaml che hai appena creato in un editor e poi rimuovi il campo cloudrun da spec.

   3. Codifica Base64 del file ${CLUSTER_NAME}_cluster_create_secret.yaml in un file .b64:

      cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
      

   4. Nell'editor, apri il file .b64 locale che hai appena creato e poi copia la stringa dall'attributo data.cfg per utilizzarla nel passaggio successivo.

      Devi assicurarti di copiare solo i contenuti dell'attributo cfg. Ad esempio, non includere interruzioni di riga (\n).

   5. Esegui questo comando per modificare il secret nel cluster utente:

      kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}"
      

   6. Nell'editor che si apre, sostituisci il campo data[cfg] con la stringa che hai copiato dal file .b64 locale e poi salva le modifiche.

   7. Verifica che le modifiche siano state implementate nel cluster di utenti e che l'attributo cloudrun sia stato rimosso correttamente dai segreti create-config:

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace ${CLUSTER_NAME} \
        --output=jsonpath={.data.cfg} \
        | base64 -d
      

4. Configura lo spazio dei nomi knative-serving nel cluster utente:

   1. Elimina l'operatore cloudrun-operator dallo spazio dei nomi knative-serving:

      kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
      

   2. Applica la patch a configmap config-network nello spazio dei nomi knative-serving:

      kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
      

5. Rimuovi la configurazione cloudrun.enabled dal file di configurazione user-config.yaml del cluster utente dell'installazione di Google Distributed Cloud.

   I seguenti attributi devono essere eliminati dal file user-config.yaml:

   cloudRun:
     enabled: true
   

   Quando esegui l'upgrade del cluster ad Anthos versione 1.8, questa modifica della configurazione viene implementata.

6. Se hai più cluster utente, devi ripetere tutti i passaggi di questa sezione "Configurare ogni cluster utente" per ogni cluster utente.

Configura il componente del parco risorse

1. Attiva il componente Knative serving nel tuo parco risorse:

   gcloud container fleet cloudrun enable --project=$PROJECT_ID
   

   Per dettagli e opzioni aggiuntive, consulta il riferimento gcloud container fleet cloudrun enable.

2. (Facoltativo) Verifica che il componente della funzionalità Knative serving sia attivato:

   Console

   Verifica se il componente Knative serving è abilitato nella consoleGoogle Cloud :

   Vai a Gestore funzionalità

   Riga di comando

   Visualizza se lo stato di appdevexperience è ENABLED:

   gcloud container fleet features list --project=$PROJECT_ID
   

   Per dettagli e opzioni aggiuntive, consulta il riferimento all'elenco delle funzionalità di gcloud container fleet.

   Risultato:

   NAME               STATE
   appdevexperience   ENABLED
   

3. Esegui il deployment della risorsa personalizzata CloudRun per installare Knative serving su VMware su ciascuno dei tuoi cluster utente. Per impostazione predefinita, viene eseguito il deployment della versione latest di Knative serving.

   Importante: se hai più cluster utente, devi ripetere questo passaggio per ogni cluster utente.

   Esegui questo comando kubectl apply per eseguire il deployment della configurazione predefinita della risorsa personalizzata CloudRun:

   cat <<EOF | kubectl apply -f -
   apiVersion: operator.run.cloud.google.com/v1alpha1
   kind: CloudRun
   metadata:
     name: cloud-run
   spec:
     metricscollector:
       stackdriver:
         projectid: $PROJECT_ID
         gcpzone: $CLUSTER_LOCATION
         clustername: $CLUSTER_NAME
         secretname: "stackdriver-service-account-key"
         secretkey: "key.json"
   EOF
   

Configura Cloud Service Mesh

Configura il bilanciatore del carico Cloud Service Mesh per ciascuno dei tuoi cluster utente.

Importante: se hai più cluster di utenti, devi ripetere i passaggi di questa sezione per ogni cluster di utenti.

Puoi configurare il gateway in entrata di Cloud Service Mesh configurando un nuovo indirizzo IP esterno o riutilizzando l'indirizzo IP esistente:

• Con il nuovo indirizzo IP esterno ottenuto, configura il bilanciatore del carico seguendo i passaggi descritti nella documentazione di Cloud Service Mesh.

  Tieni presente che questa opzione garantisce che i tuoi servizi Knative siano riavviati senza interruzioni.

• Alternativa: segui questi passaggi per configurare il bilanciatore del carico Cloud Service Mesh con il tuo indirizzo IP esistente.

  Avviso :la migrazione a Cloud Service Mesh utilizzando l'indirizzo IP esistente causa circa 2 minuti di inattività della connessione. Devi pianificare di tenere conto di questo periodo durante il quale i tuoi servizi Knative serving non sono in grado di connettersi.

  1. Configura il gateway dei tuoi servizi in Cloud Service Mesh eseguendo i seguenti comandi:

     export CURRENT_INGRESS_IP=$(kubectl get service --namespace gke-system istio-ingress --output jsonpath='{.spec.loadBalancerIP}')
     kubectl patch service --namespace istio-system istio-ingressgateway --patch "{\"spec\":{\"loadBalancerIP\": \"$CURRENT_INGRESS_IP\"}}"
     kubectl patch service --namespace gke-system istio-ingress --patch "{\"spec\":{\"loadBalancerIP\": null}}"
     

  2. Rimuovi le impostazioni di configurazione di Istio attuali:

     kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"local-gateway.cluster-local-gateway": null}}'
     kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"gateway.gke-system-gateway": null}}'
     

Verificare la migrazione

Puoi verificare se appdevexperience-operator è attivo e in esecuzione per verificare che Knative Serving su VMware sia stato migrato correttamente al tuo parco macchine.

Per ogni cluster utente, esegui questo comando:

 kubectl get deployment -n appdevexperience appdevexperience-operator

L'operatore appdevexperience-operator dovrebbe mostrare 1/1 come pronto, ad esempio:

 NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
 appdevexperience-operator   1/1     1            1           1h

Se l'operatore non riesce a raggiungere lo stato pronto, puoi visualizzare la pagina dei workload del cluster nella console Google Cloud per identificare i problemi relativi alle risorse:

Vai ai carichi di lavoro di Google Kubernetes Engine

Esegui l'upgrade del cluster

Ora che hai eseguito la migrazione dell'installazione di Knative serving su VMware per utilizzare il componente del parco risorse, puoi eseguire l'upgrade del cluster ad Anthos versione 1.8. Segui le istruzioni dettagliate riportate in Eseguire l'upgrade di GKE On-Prem.

Risoluzione dei problemi

Il processo di upgrade del cluster utente non viene completato

Il pod cluster-local-gateway nello spazio dei nomi gke-system potrebbe impedire al cluster utente di completare l'upgrade ad Anthos versione 1.8. Il pod cluster-local-gateway non è più necessario e può essere rimosso in sicurezza.

Per assistere manualmente la procedura di upgrade, puoi rimuovere manualmente il pod cluster-local-gateway riducendo le repliche del deployment a 0. Ad esempio:

1. Ridimensiona cluster-local-gateway:

   kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
   

   Il pod cluster-local-gateway nello spazio dei nomi gke-system e tutti i carichi di lavoro nello spazio dei nomi knative-serving vengono rimossi.

2. Attendi il completamento del processo di upgrade.

Scopri di più sul ridimensionamento dei deployment.