Scopri come eseguire la migrazione di Knative serving su VMware per utilizzare i parchi risorse in modo da poter eseguire l'upgrade ad Anthos versione 1.8.
Knative serving ora è un'esperienza separata dal prodotto gestito Cloud Run e viene fornito come componente del parco risorse nei tuoi cluster. L'installazione di Knative serving sulle funzionalità VMware come componente del tuo parco risorse ti consente di gestire ed eseguire l'upgrade della tua installazione indipendentemente dagli altri componenti del parco risorse.
A livello generale, per eseguire la migrazione della tua installazione di Knative serving su VMware in modo da utilizzare un parco risorse, devi:
- Configura la tua installazione di Knative serving su VMware per soddisfare i 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, consulta Installare 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 GKE Enterprise:
Scopri come registrare un cluster.
L'installazione di Knative serving su VMware è eseguita su un cluster che esegue Anthos versione 1.7 o precedente.
Istio non è più supportato in Anthos 1.8. Cloud Service Mesh versione 1.18 deve essere installato nel 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 maggiori dettagli sull'installazione su GKE su VMware.
Tieni presente che Cloud Service Mesh richiede che il cluster utilizzi un tipo di macchina con almeno quattro vCPU, come
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 di Knative serving in Cloud Service Mesh, tra cui:
Ottieni un nuovo indirizzo IP esterno in cui configurare il bilanciatore del carico.
Riutilizza l'indirizzo IP del bilanciatore del carico esistente.
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 i seguenti passaggi per garantire che l'installazione di Knative serving esistente su VMware venga migrata all'utilizzo del componente del parco risorse.
Accedi al cluster di amministrazione
Ottieni il percorso e il nome file del file kubeconfig del tuo cluster di amministrazione e 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 nel file kubeconfig del tuo 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 file kubeconfig del tuo cluster utente:export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
Sostituisci [USER_CLUSTER_KUBECONFIG] con il percorso e il nome del file nel 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 risorsa personalizzataOnPremUserCluster
del tuo cluster utente:Verifica che
cloudRun
sia impostato inOnPremUserCluster
:$ kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"
Risultato:
{"enabled":true}
Rimuovi
cloudRun
daOnPremUserCluster
: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 daOnPremUserCluster
eseguendo lo stesso comandoget
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:
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"
Apri in un editor il file
${CLUSTER_NAME}_create_secret.yaml
appena creato e rimuovi il campocloudrun
daspec
.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"
Nell'editor, apri il file
.b64
locale che hai appena creato e poi copia la stringa dall'attributodata.cfg
per utilizzarla nel passaggio successivo.Devi assicurarti di copiare solo i contenuti dall'attributo
cfg
. Ad esempio, non includere nuove righe (\n
).Esegui questo comando per modificare il secret sul cluster utente:
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}"
Nell'editor che si apre, sostituisci il campo
data[cfg]
con la stringa che hai copiato dal file.b64
locale, quindi salva le modifiche.Verifica che sia stato eseguito il deployment delle modifiche nel cluster utente e che l'attributo
cloudrun
sia stato rimosso correttamente dai secret dicreate-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 tuo cluster utente:Elimina l'operatore
cloudrun-operator
dallo spazio dei nomiknative-serving
:kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
Applica la patch alla configmap
config-network
nello spazio dei nomiknative-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 del cluster utenteuser-config.yaml
dell'installazione di GKE on VMware.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, viene eseguito il deployment di questa modifica di configurazione.
Se disponi di più cluster utente, devi ripetere tutti i passaggi in questa sezione "Configura ogni cluster utente" per ogni cluster utente.
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, consulta la documentazione di riferimento gcloud container fleet cloudrun Enable.
(Facoltativo) Verifica che il componente della funzionalità Knative serving sia abilitato:
Console
Vedi se il componente Knative serving è abilitato nella console Google Cloud:
Riga di comando
Vedi se lo stato
appdevexperience
èENABLED
:gcloud container fleet features list --project=$PROJECT_ID
Per dettagli e opzioni aggiuntive, consulta la documentazione di riferimento gcloud container Fleet features list.
Risultato:
NAME STATE appdevexperience ENABLED
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 versionelatest
di Knative serving.Esegui questo comando
kubectl apply
per eseguire il deployment della configurazione predefinita della risorsa personalizzataCloudRun
: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 configurando un nuovo indirizzo IP esterno o riutilizzando il tuo indirizzo IP esistente:
Con il nuovo indirizzo IP esterno ottenuto, puoi configurare il bilanciatore del carico seguendo i passaggi nella documentazione di Cloud Service Mesh.
Tieni presente che questa opzione garantisce che i servizi Knative serving vengano riavviati senza interruzioni.
In alternativa: segui questi passaggi per configurare il bilanciatore del carico Cloud Service Mesh per il tuo indirizzo IP esistente.
Configura il gateway dei tuoi servizi in Cloud 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}}"
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 controllare se appdevexperience-operator
è attivo e in esecuzione per verificare che la migrazione di Knative serving su VMware nel tuo parco risorse sia stata eseguita correttamente.
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 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 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 nomigke-system
potrebbe impedire al tuo cluster utente di completare l'upgrade ad Anthos versione 1.8. Il podcluster-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 di deployment a0
. 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 nomigke-system
e tutti i carichi di lavoro nello spazio dei nomiknative-serving
vengono rimossi.Attendi il completamento del processo di upgrade.