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

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

Verfügbare Versionen

Neueste
Archivieren

Diese Seite wurde von der Cloud Translation API übersetzt.

Upgrade von Knative serving auf VMware für Flotten durchführen

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:

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 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.
  
  Warnung: Wiederverwendung einer vorhandenen IP-Adresse für die Konfiguration Cloud Service Mesh verursacht eine Verbindung von ungefähr 2 Minuten nicht nutzen. Planen Sie diese Zeit ein, in der Ihr Knative serving-Dienste können keine Verbindung herstellen.
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 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, Secret bearbeiten in Ihrem Nutzercluster:
```
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 cloudrun.enabled-Konfiguration aus der Konfigurationsdatei user-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
Prüfen Sie, ob die Knative serving-Komponente im Google Cloud Console:

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 für die Installation bereit Knative serving auf VMware in jedem Ihrer Nutzercluster Standardmäßig enthält der Parameter Version von latest von Knative serving wurde 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 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 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. 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 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.