Questa documentazione riguarda la versione più recente di Knative serving, che utilizza i parchi risorse e Anthos Service Mesh. Scopri di più.

La versione precedente (Cloud Run for Anthos) è stata archiviata, ma la documentazione rimane disponibile per gli utenti esistenti.

Versioni disponibili

Ultimi
Archivia

Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire l'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 alla versione 1.8 di Anthos.

Knative serving è ora un'esperienza separata dal prodotto gestito Cloud Run e viene fornito come componente del parco nei tuoi cluster. L'installazione di Knative serving sulle funzionalità VMware come componente del tuo parco risorse ti consente di gestire e eseguire l'upgrade della tua installazione indipendentemente da altri componenti del parco risorse.

A grandi linee, 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 per soddisfare 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 servizio Knative sul cluster VMware sia registrato a un parco e sia visibile nella console Google Cloud :

Vai ai cluster GKE
L'installazione di Knative serving su VMware si trova in 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 tuo parco risorse e l'installazione di Knative serving deve essere configurata prima di eseguire l'upgrade del cluster alla versione 1.8.

Consulta le istruzioni di Cloud Service Mesh per informazioni dettagliate sull'installazione su Google Distributed Cloud.

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 cambiare il tipo di macchina del cluster, consulta la sezione Eseguire la migrazione dei carichi di lavoro in tipi di macchine diversi.
Esistono due opzioni per eseguire la migrazione di Knative serving in Cloud Service Mesh:
- Ottieni un nuovo indirizzo IP esterno a 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 tempo di riposo della connessione. Dovresti prevedere 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 migrazione dell'installazione esistente di Knative serving su VMware venga eseguita utilizzando il componente del parco risorse.

Accedere al cluster di amministrazione

Ottieni il percorso e il nome del file kubeconfig del 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 del file del file kubeconfig del tuo cluster di amministrazione.

Configurare ogni cluster utente

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

Crea la variabile di ambiente USER_KUBECONFIG con il percorso del file kubeconfig del cluster dell'utente:
```
export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
```
Sostituisci [USER_CLUSTER_KUBECONFIG] con il percorso e il nome del file del file kubeconfig del cluster utente.

Crea variabili di ambiente per le seguenti configurazioni:

ID del tuo progetto Google Cloud .
Posizione delle risorse Google Cloud .
Nome del cluster di utenti.

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']}")

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

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}

Rimuovi cloudRun da OnPremUserCluster:

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

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 deve essere presente alcun output nel terminale.

Aggiorna il segreto create-config del tuo 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 sotto spec.
3. Codifica in Base64 il 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 sotto l'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 il seguente comando per modificare il segreto 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
```

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

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

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

Esegui la patch del 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}}}'

Rimuovi la configurazione cloudrun.enabled dal file di configurazione user-config.yaml del cluster utente della tua 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 alla versione 1.8 di Anthos, questa modifica alla configurazione viene implementata.
Se hai più cluster di utenti, devi ripetere tutti i passaggi descritti in questa sezione "Configurare ogni cluster di utenti" per ogni cluster di utenti.

Configura il componente del parco risorse

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.
(Facoltativo) Verifica che il componente della funzionalità Knative serving sia attivo:
Console
Controlla se il componente di pubblicazione Knative è Abilitato nella consoleGoogle Cloud :

Vai a Gestore funzionalità
Riga di comando
Visualizza se lo stato appdevexperience è ENABLED:
```
gcloud container fleet features list --project=$PROJECT_ID
```
Per dettagli e opzioni aggiuntive, consulta il elenco delle funzionalità di gcloud container fleet informazioni di riferimento.

Risultato:
```
NAME               STATE
appdevexperience   ENABLED
```
Esegui il deployment della risorsa personalizzata CloudRun per installare Knative serving su VMware su ciascun cluster utente. Per impostazione predefinita, viene eseguita il deployment della versione latest di Knative serving.

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

Esegui il seguente 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 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 servizi di pubblicazione Knative vengano riavviati senza interruzioni.

Alternativa: segui i passaggi che seguono per configurare il bilanciatore del carico Cloud Service Mesh con il tuo indirizzo IP esistente.

Configura il gateway dei tuoi servizi per 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}}"

Rimuovi le impostazioni di configurazione Istio correnti:

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 controllare se appdevexperience-operator è attivo per verificare che la migrazione di Knative serving su VMware sia stata eseguita correttamente nel tuo parco risorse.

Per ogni cluster utente, esegui il seguente 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 di disponibilità, puoi visualizzare la pagina dei workload del cluster nella console Google Cloud per identificare i problemi relativi alle risorse:

Vai ai carichi di lavoro 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 alla versione 1.8 di Anthos. Segui le istruzioni dettagliate riportate in Eseguire l'upgrade di GKE On-Prem.

Risoluzione dei problemi

Il processo di upgrade del cluster utente non riesce a completarsi

Il pod cluster-local-gateway nello spazio dei nomi gke-system potrebbe impedire al tuo 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:

Riduci 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.
Attendi il completamento del processo di upgrade.

Scopri di più sul ridimensionamento dei deployment.