Diese Dokumentation bezieht sich auf die neueste Version der Knative-Bereitstellung, die Flotten und Anthos Service Mesh verwendet. Weitere Informationen

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

Verfügbare Versionen

Neueste
Archivieren

Upgrade von Knative für die Bereitstellung auf VMware für Flotten durchführen

Hier erfahren Sie, wie Sie Knative Serving auf VMware zur Verwendung von Flotten migrieren, um ein Upgrade auf Anthos Version 1.8 durchzuführen.

Die Bereitstellung von Knative ist jetzt unabhängig vom verwalteten Cloud Run-Produkt und wird jetzt als Flottenkomponente in Ihren Clustern bereitgestellt. Wenn Sie die Features von Knative für die Bereitstellung auf VMware als Komponente Ihrer Flotte installieren, können Sie Ihre Installation unabhängig von anderen Flottenkomponenten verwalten und aktualisieren.

Grundsätzlich müssen Sie Folgendes tun, um Ihre Knative-Bereitstellung auf VMware-Installation zu einer Flotte zu migrieren:

Konfigurieren Sie die Installation von Knative für die Bereitstellung auf VMware entsprechend den Flottenanforderungen.
Aktivieren Sie die Knative-Bereitstellungsfeature-Komponente in Ihrer Flotte.

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

Weitere Informationen zum Durchführen einer Neuinstallation von Knative für die Bereitstellung auf VMware finden Sie unter Knative-Bereitstellung auf VMware installieren.

Hinweise

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

Für diese Schritte muss der Cluster für die Bereitstellung von Knative auf VMware in GKE Enterprise registriert sein:

Zu GKE Enterprise-Clustern

Cluster registrieren
Ihre Installation von Knative für die Bereitstellung auf VMware befindet sich in einem Cluster, auf dem Anthos Version 1.7 oder niedriger ausgeführt wird.
Istio wird in Anthos 1.8 nicht mehr unterstützt. Anthos Service Mesh Version 1.18 muss in Ihrer Flotte installiert und Ihre Installation der Knative-Bereitstellung muss konfiguriert werden, bevor Sie diesen Cluster auf Version 1.8 upgraden.

Weitere Informationen zur Installation in GKE on VMware finden Sie in der Anleitung zu Anthos Service Mesh.

Beachten Sie, dass Anthos 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 Möglichkeiten, die Knative-Bereitstellung zu Anthos Service Mesh zu migrieren:
- 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 Anthos Service Mesh führt zu etwa zwei Minuten Ausfallzeit. Planen Sie für diesen Zeitraum ein, in dem Ihre Knative-Bereitstellungsdienste keine Verbindung herstellen können.
Ihre Befehlszeilenumgebung muss konfiguriert und auf dem neuesten Stand sein.

Zu Flotten migrieren

Für das Upgrade von Anthos auf Version 1.8 müssen Sie zuerst die folgenden Schritte ausführen, damit Ihre vorhandene Installation von Knative für die Bereitstellung auf VMware mithilfe 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 cloudrun.enabled-Konfiguration aus der Konfigurationsdatei user-config.yaml des Nutzerclusters Ihrer GKE on VMware-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-Bereitstellungskomponente 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 Funktion für die Bereitstellung von Knative aktiviert ist:
Console
Prüfen Sie in der Google Cloud Console, ob die Knative-Bereitstellungskomponente Aktiviert ist:

Zu den GKE Enterprise-Features
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.

Auswirkungen:
```
NAME               STATE
appdevexperience   ENABLED
```
Stellen Sie die benutzerdefinierte Ressource CloudRun bereit, um die Bereitstellung von Knative auf VMware in jedem Ihrer Nutzercluster zu installieren. Standardmäßig wird die Version latest der Knative-Bereitstellung 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
```

Anthos Service Mesh konfigurieren

Konfigurieren Sie den Anthos Service Mesh-Load-Balancer für jeden Ihrer Nutzercluster.

Sie können das Ingress-Gateway von Anthos 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 Anthos Service Mesh.

Durch diese Option werden die Knative-Bereitstellungsdienste ohne Unterbrechung neu gestartet.

Alternativ: Konfigurieren Sie den Anthos 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 Anthos 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

Sie können prüfen, ob appdevexperience-operator ausgeführt wird, um zu prüfen, ob die Knative-Bereitstellung 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 Installation von Knative für die Bereitstellung auf VMware migriert haben, um die Flottenkomponente zu verwenden, können Sie Ihren Cluster auf Anthos Version 1.8 upgraden. 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.