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

Più recente
Archivia

Questa pagina è stata tradotta dall'API Cloud Translation.

Upgrade di Knative serving su VMware ai parchi risorse

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

Knative serving ora è un'esperienza separata dalla versione gestita Cloud Run ed è ora fornito come componente del parco risorse in nei cluster. Installazione di Knative serving su funzionalità VMware come del tuo parco risorse ti consente di gestire ed eseguire l'upgrade indipendentemente dagli altri componenti del parco risorse.

A livello generale, per eseguire la migrazione della tua installazione di Knative serving su VMware per utilizzare un'istanza devi:

Configura la tua installazione di Knative serving su VMware per soddisfare le requisiti del parco risorse.
Abilita il componente della funzionalità Knative serving nel tuo parco risorse.

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

Per maggiori dettagli su come eseguire una nuova installazione di Knative serving su VMware, vedi 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 è su un che esegue Anthos versione 1.7 o precedente.
Istio non è più supportato in Anthos 1.8. Versione Cloud Service Mesh La versione 1.18 deve essere installata nel tuo parco risorse e la tua installazione di Knative serving deve essere configurato prima di eseguire l'upgrade del cluster a Versione 1.8.

Consulta le istruzioni di Cloud Service Mesh per maggiori dettagli su installazione su Google Distributed Cloud.

Tieni presente che Cloud Service Mesh richiede che il cluster utilizzi un tipo di macchina con almeno quattro vCPU, come e2-standard-4. Per modificare il tipo di macchina del cluster, Migrazione dei carichi di lavoro a tipi di macchine diversi.
Esistono due opzioni per eseguire la migrazione di Knative serving Cloud Service Mesh, puoi:
- Ottieni un nuovo indirizzo IP esterno in cui configurare il bilanciatore del carico.
- Riutilizza l'indirizzo IP del bilanciatore del carico esistente.
  
  Avviso: la procedura per riutilizzare un indirizzo IP esistente per configurare Cloud Service Mesh causa circa 2 minuti di connessione o un tempo di inattività. Dovresti pianificare di supportare questo periodo durante il quale i tuoi I servizi Knative serving non riescono a connettersi.
Assicurati che il tuo ambiente a 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 per assicurare che la tua Knative serving esistente su VMware viene migrata l'installazione utilizzando il componente del parco risorse.

Accedi al cluster di amministrazione

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

Configura ogni cluster utente

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

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

Crea variabili di ambiente per le seguenti configurazioni:

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

Rimuovi la configurazione cloudrun dalla personalizzazione OnPremUserCluster risorsa 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 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.

Aggiorna il secret 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 appena creato in un editor, quindi rimuovi il campo cloudrun da spec.
3. Base64 codifica 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 dall'attributo data.cfg per utilizzarla nel prossimo passaggio.
  
  Devi assicurarti di copiare solo i contenuti dall'attributo cfg. Ad esempio, non includere nuove righe (\n).
5. Esegui questo comando per modificare il secret sul tuo cluster utente:
```
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace "${CLUSTER_NAME}"
```
6. Nell'editor visualizzato, sostituisci il campo data[cfg] con il la stringa che hai copiato dal file .b64 locale e poi salva modifiche.
7. Verifica che sia stato eseguito il deployment delle modifiche nel cluster utente e che l'attributo cloudrun è stato rimosso dal create-config secret:
```
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 tuo cluster utente:

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

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

Applica la patch alla 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 cluster utente file di configurazione user-config.yaml della tua installazione di Google Distributed Cloud.

I seguenti attributi devono essere eliminati all'interno di user-config.yaml file:
```
cloudRun:
  enabled: true
```
Quando esegui l'upgrade del cluster ad Anthos versione 1.8, del deployment di una modifica alla configurazione.
Se disponi di più cluster utente, devi ripetere tutti i passaggi in questa "Configura ogni cluster utente" per ogni utente in un cluster Kubernetes.

Configura il componente del parco risorse

Abilita il componente Knative serving nel tuo parco risorse:
```
gcloud container fleet cloudrun enable --project=$PROJECT_ID
```
Per dettagli e opzioni aggiuntive, vedi gcloud container Fleet Cloudrun Enable riferimento.
(Facoltativo) Verifica che il componente della funzionalità Knative serving sia attivato:
Console
Controlla se il componente Knative serving è impostato su Abilitato nella Console Google Cloud:

Vai a Gestore funzionalità
Riga di comando
Vedi se lo stato appdevexperience è ENABLED:
```
gcloud container fleet features list --project=$PROJECT_ID
```
Per dettagli e opzioni aggiuntive, vedi Elenco delle funzionalità del parco risorse gcloud container riferimento.

Risultato:
```
NAME               STATE
appdevexperience   ENABLED
```
Esegui il deployment della risorsa personalizzata CloudRun da installare Knative serving su VMware su ciascuno dei tuoi cluster utente. Per impostazione predefinita, È stato eseguito il deployment di latest versione di Knative serving.

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

Esegui questo comando kubectl apply per eseguire il deployment dell'impostazione predefinita configurazione 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.

Puoi configurare il gateway in entrata di Cloud Service Mesh tramite per configurare un nuovo indirizzo IP esterno o riutilizzare un indirizzo IP esistente:

Con il nuovo indirizzo IP esterno che hai ottenuto, configuri il carico seguendo i passaggi nella sezione Documentazione di Cloud Service Mesh.

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

Alternativa: segui questi passaggi per configurare Cloud Service Mesh al tuo indirizzo IP esistente.

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

Rimuovi le impostazioni di configurazione 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}}'

Verifica migrazione

Puoi verificare se appdevexperience-operator sia attivo e in esecuzione per verificare che Knative serving su VMware sia stato migrazione al parco risorse completata.

Per ogni cluster utente, esegui questo comando:

 kubectl get deployment -n appdevexperience appdevexperience-operator

appdevexperience-operator operatore 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 carichi di lavoro 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 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 viene completato

Il pod cluster-local-gateway nello spazio dei nomi gke-system potrebbe impedire del tuo cluster utente dal completamento dell'upgrade ad Anthos versione 1.8. Il pod cluster-local-gateway non è più necessario e può essere rimosso in sicurezza.

Per facilitare manualmente il processo di upgrade, puoi rimuovere manualmente il cluster-local-gateway pod eseguendo lo scale down delle repliche di deployment a 0. Ad esempio:

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 nello spazio dei nomi knative-serving vengono rimossi.
Attendi il completamento del processo di upgrade.

Scopri di più sulla scalabilità dei deployment.