Hier erfahren Sie, wie Sie Knative serving auf VMware migrieren, um Flotten zu verwenden, Upgrade auf Anthos Version 1.8 durchführen.
Knative serving ist jetzt getrennt vom verwalteten Dienst Cloud Run verfügbar und wird jetzt als Flottenkomponente in für Ihre Cluster. Features von Knative serving on VMware installieren Komponente Ihrer Flotte ermöglicht es Ihnen, Ihre unabhängig von anderen Flottenkomponenten.
So migrieren Sie Ihre Knative serving on VMware-Installation zur Verwendung eines müssen Sie Folgendes tun:
- Konfigurieren Sie Ihre Knative serving on VMware-Installation so, dass sie den Anforderungen für Ihren Gerätepool.
- Aktivieren Sie die Funktionskomponente von Knative serving in der Flotte.
Beachten Sie, dass der Kubernetes API-Server von der Migration nicht betroffen ist.
Weitere Informationen zum Ausführen einer Neuinstallation von Knative serving auf VMware finden Sie hier: Siehe Knative serving auf VMware installieren
Hinweise
Es müssen die folgenden Anforderungen erfüllt sein:
Für diese Schritte muss Ihr Knative serving on VMware-Cluster in einer Flotte registriert und in der Google Cloud Console angezeigt werden:
Ihre Installation von Knative serving auf VMware befindet sich auf einem Cluster mit Anthos Version 1.7 oder niedriger.
Istio wird in Anthos 1.8 nicht mehr unterstützt. Cloud Service Mesh-Version 1.18 muss in Ihrem Gerätepool installiert sein und Ihre Installation von Knative serving muss konfiguriert werden, bevor Sie diesen Cluster upgraden auf Version 1.8
Weitere Informationen finden Sie in der Anleitung zu Cloud Service Mesh: Installation in Google Distributed Cloud.
Für Cloud Service Mesh muss Ihr Cluster einen Maschinentyp verwenden mit mindestens vier vCPUs, z. B.
e2-standard-4
. Wenn Sie den Maschinentyp Ihres Clusters ändern müssen, lesen Sie die Informationen unter Arbeitslasten zu anderen Maschinentypen migrieren.Es gibt zwei Möglichkeiten, Knative serving zu migrieren, Cloud Service Mesh haben Sie folgende Möglichkeiten:
Rufen Sie eine neue externe IP-Adresse ab, für die Sie den Load-Balancer konfigurieren.
Verwenden Sie die vorhandene IP-Adresse des Load-Balancers.
Ihre Befehlszeilenumgebung muss konfiguriert und auf dem neuesten Stand sein.
Zu Flotten migrieren
Um Anthos auf Version 1.8 zu aktualisieren, müssen Sie zuerst die die folgenden Schritte, um sicherzustellen, dass Ihr vorhandenes Knative serving auf VMware wird die Installation mithilfe der Flottenkomponente migriert.
Auf Ihren Administratorcluster zugreifen
Rufen Sie den Pfad und den Dateinamen der kubeconfig-Datei Ihres Administratorclusters ab und erstellen Sie dann die Umgebungsvariable ADMIN_KUBECONFIG
:
export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]
Ersetzen Sie dabei [ADMIN_CLUSTER_KUBECONFIG] durch den Pfad und den Dateinamen der kubeconfig-Datei Ihres Nutzerclusters.
Nutzercluster konfigurieren
Erstellen Sie die folgenden lokalen Umgebungsvariablen für den Nutzercluster:
Erstellen Sie die
USER_KUBECONFIG
-Umgebungsvariable mit dem Pfad der kubeconfig-Datei Ihres Nutzerclusters:export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
Ersetzen Sie dabei [USER_CLUSTER_KUBECONFIG] durch den Pfad und den Dateinamen der kubeconfig-Datei Ihres Nutzerclusters.
Erstellen Sie Umgebungsvariablen für die folgenden Konfigurationen:
- ID Ihres Google Cloud-Projekts.
- Speicherort Ihrer Google Cloud-Ressourcen.
- Name des Nutzerclusters.
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']}")
Entfernen Sie die Konfiguration
cloudrun
aus der benutzerdefinierten RessourceOnPremUserCluster
Ihres Administratorclusters:Prüfen Sie, ob
cloudRun
inOnPremUserCluster
festgelegt ist:$ kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"
Ergebnis:
{"enabled":true}
Entfernen Sie
cloudRun
ausOnPremUserCluster
:kubectl patch onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --type="merge" \ --patch '{"spec": {"cloudRun": null}}'
Prüfen Sie, ob
cloudRun
erfolgreich ausOnPremUserCluster
entfernt wurde. Führen Sie dazu den Befehlget
aus und prüfen Sie, ob eine Konfiguration zurückgegeben wird:kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"
Es sollte keine Ausgabe an Ihr Terminal gesendet werden.
Aktualisieren Sie das Secret "create-config" Ihres Nutzerclusters:
Erstellen Sie eine lokale YAML-Kopie der Datei "create-config":
kubectl get secret create-config \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}" \ --output=jsonpath={.data.cfg} \ | base64 -d > "${CLUSTER_NAME}_create_secret.yaml"
Öffnen Sie die soeben erstellte Datei
${CLUSTER_NAME}_create_secret.yaml
in einem Editor und entfernen Sie das Feldcloudrun
ausspec
.Codieren Sie die Datei
${CLUSTER_NAME}_cluster_create_secret.yaml
mit Base64 in eine.b64
-Datei:cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
Öffnen Sie in Ihrem Editor die soeben erstellte lokale Datei
.b64
und kopieren Sie den String aus dem Attributdata.cfg
, um ihn im nächsten Schritt zu verwenden.Sie dürfen nur den Inhalt des Attributs
cfg
kopieren. Fügen Sie beispielsweise keine Zeilenumbrüche (\n
) ein.Führen Sie den folgenden Befehl aus, Secret bearbeiten in Ihrem Nutzercluster:
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}"
Ersetzen Sie im geöffneten Editor das Feld
data[cfg]
durch den String, den Sie aus der lokalen Datei.b64
kopiert haben, und speichern Sie dann die Änderungen.Prüfen Sie, ob Ihre Änderungen in Ihrem Nutzercluster bereitgestellt wurden und ob das Attribut
cloudrun
erfolgreich aus den Secretscreate-config
entfernt wurde:kubectl get secret create-config \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace ${CLUSTER_NAME} \ --output=jsonpath={.data.cfg} \ | base64 -d
Konfigurieren Sie den Namespace
knative-serving
in Ihrem Nutzercluster:Löschen Sie den Operator
cloudrun-operator
aus dem Namespaceknative-serving
:kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
Patchen Sie die ConfigMap
config-network
im Namespaceknative-serving
:kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
Entfernen Sie die
cloudrun.enabled
-Konfiguration aus der Konfigurationsdateiuser-config.yaml
Ihrer Google Distributed Cloud-Installation.Die folgenden Attribute müssen aus der Datei
user-config.yaml
gelöscht werden:cloudRun: enabled: true
Wenn Sie das Clusterupgrade auf Anthos Version 1.8 ausführen, wird diese Änderung der Konfiguration bereitgestellt.
Wenn Sie mehrere Nutzercluster haben, müssen Sie alle Schritte im Abschnitt Nutzercluster konfigurieren für jeden Nutzercluster wiederholen.
Flottenkomponente konfigurieren
Aktivieren Sie die Knative serving-Komponente in Ihrer Flotte:
gcloud container fleet cloudrun enable --project=$PROJECT_ID
Weitere Informationen und zusätzliche Optionen finden Sie in der Referenz zu gcloud container fleet cloudrun enable.
Optional: Prüfen Sie, ob die Funktionskomponente von Knative serving verwendet werden kann. aktiviert:
Console
Sehen Sie sich an, ob die Knative serving-Komponente aktiviert im Google Cloud Console:
Befehlszeile
Prüfen Sie, ob der
appdevexperience
-ZustandENABLED
lautet:gcloud container fleet features list --project=$PROJECT_ID
Weitere Informationen und zusätzliche Optionen finden Sie unter gcloud container fleet features list.
Ergebnis:
NAME STATE appdevexperience ENABLED
Stellen Sie die benutzerdefinierte Ressource
CloudRun
für die Installation bereit Knative serving auf VMware in jedem Ihrer Nutzercluster Standardmäßig enthält der Parameter Version vonlatest
von Knative serving wurde bereitgestellt.Führen Sie den folgenden
kubectl apply
-Befehl aus, um die Standardkonfiguration der benutzerdefinierten RessourceCloudRun
bereitzustellen: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
Cloud Service Mesh konfigurieren
Konfigurieren Sie den Cloud Service Mesh-Load-Balancer für jeden Ihrer Nutzercluster.
Sie können das Ingress-Gateway von Cloud Service Mesh konfigurieren, indem Sie entweder eine neue externe IP-Adresse konfigurieren oder Ihre vorhandene IP-Adresse wiederverwenden:
Mit der neuen externen IP-Adresse, die Sie erhalten haben, konfigurieren Sie die Last mithilfe der Schritte in der Cloud Service Mesh-Dokumentation
Mit dieser Option wird sichergestellt, dass Ihre Knative serving-Dienste ohne Unterbrechung neu gestartet.
Alternative: Führen Sie die folgenden Schritte aus, um das Cloud Service Mesh zu konfigurieren den Load-Balancer an die vorhandene IP-Adresse an.
Konfigurieren Sie das Gateway Ihrer Dienste für Cloud Service Mesh, indem Sie Folgendes ausführen: die folgenden Befehle:
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}}"
Entfernen Sie die aktuellen Istio-Konfigurationseinstellungen:
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}}'
Migration überprüfen
Sie können nachsehen, ob appdevexperience-operator
wird ausgeführt, um zu prüfen, ob Knative serving on VMware
zu Ihrer Flotte migriert.
Führen Sie für jeden Nutzercluster den folgenden Befehl aus:
kubectl get deployment -n appdevexperience appdevexperience-operator
Das appdevexperience-operator
operator
sollte 1/1
als bereit angezeigt werden. Beispiel:
NAME READY UP-TO-DATE AVAILABLE AGE
appdevexperience-operator 1/1 1 1 1h
Wenn der Operator den Bereitschaftsstatus nicht erreicht, rufen Sie die Seite „Arbeitslasten“ Ihres Clusters in der Google Cloud Console auf, um Ressourcenprobleme zu erkennen:
Zu Google Kubernetes Engine-Arbeitslasten
Cluster upgraden
Nachdem Sie nun Ihre Installation von Knative serving on VMware migriert haben, Flottenkomponente benötigen, können Sie Ihren Cluster auf Anthos upgraden Version 1.8 Folgen Sie dazu der detaillierten Anleitung unter GKE On-Prem aktualisieren.
Fehlerbehebung
- Upgradevorgang des Nutzerclusters konnte nicht abgeschlossen werden
Der Pod
cluster-local-gateway
im Namespacegke-system
verhindert möglicherweise, dass Ihr Nutzercluster das Upgrade auf Anthos Version 1.8 ausführt. Der Podcluster-local-gateway
wird nicht mehr benötigt und kann sicher entfernt werden.Sie können den Pod
cluster-local-gateway
manuell entfernen, um den Upgradevorgang manuell zu unterstützen. Skalieren Sie dazu Ihre Deployment-Replikate auf0
herunter. Beispiel:Skalieren Sie das
cluster-local-gateway
herunter:kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
Der Pod
cluster-local-gateway
im Namespacegke-system
und alle Arbeitslasten im Namespaceknative-serving
werden entfernt.Warten Sie, bis der Upgradevorgang abgeschlossen ist.