Diese Dokumentation bezieht sich auf die neueste Version von Knative Serving, die Flotten und Anthos Service Mesh verwendet. Weitere Informationen

Die vorherige Version (Cloud Run for Anthos) wurde archiviert. Die Dokumentation ist für bestehende Nutzer aber weiterhin verfügbar.

Verfügbare Versionen

Neueste
Archivieren

Knative Serving auf VMware auf Flotten aktualisieren

Erfahren Sie, wie Sie Knative Serving auf VMware migrieren, um Flotten zu verwenden, sodass Sie ein Upgrade auf Anthos Version 1.8 durchführen können.

Knative Serving ist jetzt getrennt vom verwalteten Produkt Cloud Run und wird jetzt als Flottenkomponente in Ihren Clustern bereitgestellt. Durch die Installation von Knative Serving auf VMware-Features als Komponente Ihrer Flotte können Sie Ihre Installation unabhängig von anderen Komponenten der Flotte verwalten und aktualisieren.

Wenn Sie allgemein die Installation von Knative Serving auf VMware für die Verwendung einer Flotte migrieren möchten, sind folgende Schritte erforderlich:

Konfigurieren Sie Ihre Installation von Knative Serving auf VMware so, dass sie die Anforderungen der Flotte erfüllt.
Aktivieren Sie die Knative Serving-Feature-Komponente in Ihrer Flotte.

Beachten Sie, dass der Kubernetes API-Server von der Migration nicht betroffen ist.

Weitere Informationen zum Ausführen einer neuen Installation von Knative Serving auf VMware finden Sie unter Knative Serving auf VMware installieren.

Hinweise

Es müssen die folgenden Anforderungen erfüllt sein:

Bei diesen Schritten ist erforderlich, dass Ihr Knative-Dienst auf dem VMware-Cluster bei einer Flotte registriert und in der Google Cloud Console sichtbar ist:

Zu GKE-Clustern
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 Ihrer Flotte installiert und die Knative Serving-Installation muss konfiguriert sein, bevor Sie den Cluster auf Version 1.8 aktualisieren.

Weitere Informationen zur Installation in Google Distributed Cloud finden Sie in der Cloud Service Mesh-Anleitung.

Beachten Sie, dass Cloud Service Mesh erfordert, dass Ihr Cluster einen Maschinentyp mit mindestens vier vCPUs verwendet, 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 Optionen zum Migrieren von Knative Serving zu Cloud Service Mesh:
- 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.
  
  Warnung: Die Wiederverwendung einer vorhandenen IP-Adresse zum Konfigurieren von Cloud Service Mesh führt zu etwa zwei Minuten Ausfallzeit. Sie sollten diesen Zeitraum entsprechend planen, da währenddessen Ihre Knative Serving-Dienste keine Verbindung herstellen können.
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 folgenden Schritte ausführen, damit Ihr vorhandenes Knative Serving auf VMware zur Verwendung der Flottenkomponente migriert wird.

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 Ressource OnPremUserCluster Ihres Administratorclusters:

Prüfen Sie, ob cloudRun in OnPremUserCluster 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 aus OnPremUserCluster:

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 aus OnPremUserCluster entfernt wurde. Führen Sie dazu den Befehl get 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:
1. 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"
```
2. Öffnen Sie die soeben erstellte Datei ${CLUSTER_NAME}_create_secret.yaml in einem Editor und entfernen Sie das Feld cloudrun aus spec.
3. 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"
```
4. Öffnen Sie in Ihrem Editor die soeben erstellte lokale Datei .b64 und kopieren Sie den String aus dem Attribut data.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.
5. Führen Sie den folgenden Befehl aus, um das Secret in Ihrem Nutzercluster zu bearbeiten:
```
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace "${CLUSTER_NAME}"
```
6. 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.
7. Prüfen Sie, ob Ihre Änderungen in Ihrem Nutzercluster bereitgestellt wurden und ob das Attribut cloudrun erfolgreich aus den Secrets create-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 Namespace knative-serving:

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

Patchen Sie die ConfigMap config-network im Namespace knative-serving:

kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'

Entfernen Sie die Konfiguration cloudrun.enabled aus der Konfigurationsdatei user-config.yaml des Nutzerclusters 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 Knative Serving-Feature-Komponente aktiviert ist:
Console
Prüfen Sie, ob die Knative-Serving-Komponente in der Google Cloud Console aktiviert ist:

Zu Feature Manager
Befehlszeile
Prüfen Sie, ob der appdevexperience-Zustand ENABLED 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 bereit, um Knative Serving in VMware auf jedem Ihrer Nutzercluster zu installieren. Standardmäßig wird die latest-Version von Knative Serving bereitgestellt.

Wichtig: Wenn Sie mehrere Nutzercluster haben, müssen Sie diesen Schritt für jeden Nutzercluster wiederholen.

Führen Sie den folgenden kubectl apply-Befehl aus, um die Standardkonfiguration der benutzerdefinierten Ressource CloudRun 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 den Load-Balancer gemäß den Schritten in der Dokumentation zu Cloud Service Mesh.

Mit dieser Option wird sichergestellt, dass Ihre Knative Serving-Dienste ohne Unterbrechung neu gestartet werden.

Alternativ: Konfigurieren Sie den Cloud Service Mesh-Load-Balancer mit den folgenden Schritten zu Ihrer vorhandenen IP-Adresse.

Führen Sie die folgenden Befehle aus, um das Gateway Ihrer Dienste zu Cloud Service Mesh zu konfigurieren:

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

Prüfen Sie, ob appdevexperience-operator ausgeführt wird, um festzustellen, ob Ihr Knative Serving-Dienst auf VMware erfolgreich zu Ihrer Flotte migriert wurde.

Führen Sie für jeden Nutzercluster den folgenden Befehl aus:

 kubectl get deployment -n appdevexperience appdevexperience-operator

Für den Operator appdevexperience-operator sollte 1/1 nun 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 Ihre Knative Serving auf VMware-Installation migriert haben, um die Flottenkomponente zu nutzen, können Sie Ihren Cluster auf Anthos Version 1.8 aktualisieren. 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 Namespace gke-system verhindert möglicherweise, dass Ihr Nutzercluster das Upgrade auf Anthos Version 1.8 ausführt. Der Pod cluster-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 auf 0 herunter. Beispiele:

Skalieren Sie das cluster-local-gateway herunter:
```
kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
```
Der Pod cluster-local-gateway im Namespace gke-system und alle Arbeitslasten im Namespace knative-serving werden entfernt.
Warten Sie, bis der Upgradevorgang abgeschlossen ist.

Weitere Informationen zum Skalieren von Bereitstellungen.