Upgrade della pubblicazione di Knative su VMware nei parchi risorse

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

La pubblicazione Knative ora è un'esperienza separata dal prodotto gestito Cloud Run e viene ora fornita come componente del parco risorse nei tuoi cluster. L'installazione di Knative pubblicazione su funzionalità VMware come componente del tuo parco risorse consente di gestire ed eseguire l'upgrade dell'installazione indipendentemente dagli altri componenti del parco risorse.

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

  • Configura la tua installazione di Knative su VMware per soddisfare i requisiti del parco risorse.
  • Attiva il componente della funzionalità di pubblicazione di Knative nel tuo parco risorse.

Tieni presente che la migrazione non ha alcun impatto sul server API Kubernetes.

Per maggiori dettagli su come eseguire una nuova installazione di Knative Serving su VMware, consulta Installazione di Knative pubblicazione su VMware.

Prima di iniziare

Devi soddisfare i seguenti requisiti:

  • Questi passaggi richiedono che il cluster di gestione di Knative su VMware sia registrato in GKE Enterprise:

    Vai ai cluster GKE Enterprise

    Scopri come registrare un cluster.

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

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

    Per maggiori dettagli sull'installazione su GKE su VMware, consulta le istruzioni di Anthos Service Mesh.

    Tieni presente che Anthos 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 carichi di lavoro a tipi di macchine diversi.

  • Esistono due opzioni per eseguire la migrazione del servizio Knative ad Anthos Service Mesh, puoi:

    • Ottieni un nuovo indirizzo IP esterno in cui configurerai il bilanciatore del carico.

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

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

Esegui la migrazione ai parchi risorse

Per eseguire l'upgrade di Anthos alla versione 1.8, devi prima eseguire i passaggi seguenti per assicurarti che venga eseguita la migrazione dell'installazione di Knative su VMware per l'utilizzo del componente del parco risorse.

Accedi al cluster di amministrazione

Recupera il percorso e il nome file del file kubeconfig del tuo cluster di amministrazione, quindi crea la variabile di ambiente ADMIN_KUBECONFIG:

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

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

Configura ogni cluster utente

  1. Crea le seguenti variabili di ambiente locale 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 nel file kubeconfig del cluster utente.

    2. Crea variabili di ambiente per le configurazioni seguenti:

      • ID del tuo progetto Google Cloud.
      • Località 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 su 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 generato alcun output per il terminale.

  3. Aggiorna il secret di 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 rimuovi il campo cloudrun da spec.

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

      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, quindi copia la stringa sotto l'attributo data.cfg per utilizzarla nel passaggio successivo.

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

    5. Esegui questo comando per modificare il secret sul 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, quindi salva le modifiche.

    7. Verifica che sia stato eseguito il deployment delle modifiche nel cluster utente e che l'attributo cloudrun sia stato rimosso correttamente dai create-config secret:

      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 una patch alla configurazione di 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 del cluster utente user-config.yaml della tua installazione di GKE su VMware.

    I seguenti attributi devono essere eliminati all'interno del file user-config.yaml:

    cloudRun:
      enabled: true
    

    Quando esegui l'upgrade del cluster ad Anthos versione 1.8, viene eseguito il deployment di questa modifica della configurazione.

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

Configura il componente del parco risorse

  1. Attiva il componente di pubblicazione Knative nel tuo parco risorse:

    gcloud container fleet cloudrun enable --project=$PROJECT_ID
    

    Per dettagli e opzioni aggiuntive, consulta la pagina di riferimento gcloud container Flex cloudrunenable.

  2. (Facoltativo) Verifica che il componente della funzionalità di pubblicazione Knative sia abilitato:

    Console

    Controlla se il componente di pubblicazione Knative è impostato su Abilitato nella console Google Cloud:

    Vai alle funzionalità di GKE Enterprise

    Riga di comando

    Visualizza se lo stato di appdevexperience è ENABLED:

    gcloud container fleet features list --project=$PROJECT_ID
    

    Per dettagli e opzioni aggiuntive, consulta la documentazione sull'elenco delle funzionalità del parco risorse di container di gcloud.

    Risultato:

    NAME               STATE
    appdevexperience   ENABLED
    
  3. Esegui il deployment della risorsa personalizzata CloudRun per installare la gestione di Knative su VMware su ciascuno dei tuoi cluster utente. Per impostazione predefinita, viene eseguito il deployment della versione latest della pubblicazione di Knative.

    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 Anthos Service Mesh

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

Puoi configurare il gateway in entrata di Anthos Service Mesh configurando un nuovo indirizzo IP esterno o riutilizzando il tuo indirizzo IP esistente:

  • Con il nuovo indirizzo IP esterno che hai ottenuto, configurerai il bilanciatore del carico seguendo i passaggi nella documentazione di Anthos Service Mesh.

    Tieni presente che questa opzione garantisce che i servizi di gestione di Knative vengano riavviati senza interruzioni.

  • In alternativa: utilizza questi passaggi per configurare il bilanciatore del carico di Anthos Service Mesh sul tuo indirizzo IP esistente.

    1. Configura il gateway dei tuoi servizi ad Anthos Service Mesh eseguendo questi 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 attuali impostazioni di configurazione di Istio:

      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}}'
      

Verifica migrazione

Puoi controllare se appdevexperience-operator è in esecuzione per verificare che la pubblicazione di Knative su VMware sia stata eseguita correttamente nel parco risorse.

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 carichi di lavoro del cluster nella console Google Cloud per identificare i problemi delle 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 su VMware per l'utilizzo del componente del parco risorse, puoi eseguire l'upgrade del cluster ad Anthos versione 1.8. Segui le istruzioni dettagliate in Upgrade di GKE On-Prem.

Risoluzione dei problemi

Il processo di upgrade del cluster utente non è riuscito

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 il processo di upgrade, puoi rimuovere manualmente il pod cluster-local-gateway facendo lo scale down delle repliche del deployment a 0. Ad esempio:

  1. Fai lo scale down di 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ù sulla scalabilità dei deployment.