Cloud Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Von einem clusterinternen zu einem verwalteten kanonischen Dienstüberwacher migrieren

Hinweis: Kanonische Dienste werden in Cloud Service Mesh Version 1.6.8 und höher automatisch unterstützt.

In dieser Anleitung wird beschrieben, wie Sie vom kanonischen Dienstcontroller im Cluster zum verwalteten kanonischen Dienstcontroller migrieren.

Der clusterinterne kanonische Dienstüberwacher wurde eingestellt und erhält keine Updates mehr. Vorhandene Bereitstellungen von In-Cluster-Controllern werden weiterhin ausgeführt. Wir empfehlen jedoch dringend, zum verwalteten Canonical Service-Controller zu migrieren, um für Kompatibilität mit zukünftigen Releases, Zugriff auf die neuesten Funktionen und fortlaufenden Support zu sorgen. Alle Cloud Service Mesh-Installationen mit asmcli ab Version 1.25 werden mit dem verwalteten kanonischen Dienstcontroller bereitgestellt.

1. Cloud Service Mesh-Flottenfunktion aktivieren

Der Managed Canonical Service-Controller wird im Rahmen der Cloud Service Mesh-Flotte installiert. Diese Funktion wird mit dem folgenden Befehl aktiviert:

  gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Ersetzen Sie FLEET_PROJECT_ID durch die ID Ihres Flotten-Hostprojekts. Normalerweise hat FLEET_PROJECT_ID denselben Namen wie das Projekt.

Wenn Sie mehrere Cluster registrieren möchten, wird Cloud Service Mesh auf Flottenebene aktiviert, sodass Sie diesen Befehl nur einmal ausführen müssen.

Berechtigungen für die Cloud Service Mesh-Dienstkonten erteilen

Wenn sich das Projekt Ihres Clusters von Ihrem Fleet-Hostprojekt unterscheidet, müssen Sie Cloud Service Mesh-Dienstkonten im Fleetprojekt Zugriff auf das Clusterprojekt gewähren.

Dies ist nur einmal für jedes Clusterprojekt erforderlich. Wenn Sie zuvor verwaltetes Cloud Service Mesh für diese Kombination von Cluster- und Flottenprojekten konfiguriert haben, wurden diese Änderungen bereits angewendet und Sie müssen die folgenden Befehle nicht ausführen.

Gewähren Sie Dienstkonten im Fleet-Projekt die Berechtigung für den Zugriff auf das Clusterprojekt:

  gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

Ersetzen Sie CLUSTER_PROJECT_ID durch die Projekt-ID Ihres Clusters und FLEET_PROJECT_NUMBER durch die Projektnummer Ihrer Flotte.

Informationen zum Ermitteln der Projektnummer für Ihre Flotte finden Sie in der Anleitung im Dokument Google Cloud-Projekte.

2. Clusterinternen kanonischen Dienstüberwacher deaktivieren

Der Managed Canonical Service-Controller kann nicht zusammen mit dem clusterinternen kanonischen Dienstüberwacher verwendet werden. Daher müssen Sie den Cluster-Controller deaktivieren.

In-Cluster-Controller prüfen: Prüfen Sie, ob der kanonische Controller im Cluster vorhanden ist.
```
kubectl get deployment canonical-service-controller-manager -n asm-system
```
Clusterinternen Controller löschen: Wenn die Bereitstellung gefunden wird, können Sie sie und den gesamten Namespace „asm-system“ mit dem folgenden Befehl löschen:
```
kubectl delete namespace asm-system
```

3. Prüfen, ob der Managed Canonical Controller betriebsbereit ist

Der Managed Canonical Service-Controller meldet seinen Status im Funktionsstatus. Sie können also prüfen, ob die Installation ordnungsgemäß funktioniert, indem Sie den Funktionsstatus prüfen:

Funktionsstatus prüfen:Rufen Sie den Funktionsstatus mit dem folgenden Befehl ab:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
Status prüfen:Prüfen Sie den Status Ihres Clusters und achten Sie darauf, dass state.code den Wert OK hat.
- Wichtig:Es kann bis zu 15 Minuten dauern, bis der Status zu OK wechselt. Warten Sie und führen Sie den Befehl noch einmal aus.
- Fahren Sie nur mit dem nächsten Schritt fort, wenn state.code = OK ist.
- Wenn state.code nach 15 Minuten nicht zu OK wird, finden Sie unter Probleme mit dem verwalteten kanonischen Dienstcontroller beheben eine Anleitung zur Fehlerbehebung.
Beispielausgabe:
```
membershipStates:
    projects/<project-number>/locations/<location>/memberships/<membership-name>:
      state:
        code: OK
        description:
          Revision(s) ready for use: istiod-asm-183-2.
```
Prüfen, ob der Managed Canonical Service-Controller funktioniert:Prüfen Sie, ob der Managed Canonical Service-Controller ordnungsgemäß funktioniert, indem Sie einen Pod mit Sidecar-Injection bereitstellen und prüfen, ob der Controller automatisch den entsprechenden kanonischen Dienst erstellt.
1. Erstellen Sie einen Namespace mit aktivierter automatischer Sidecar-Einfügung:
```
kubectl create namespace NAMESPACE_NAME
```
  Folgen Sie dem Abschnitt Automatische Sidecar-Einfügung aktivieren, um die automatische Sidecar-Einfügung im neu erstellten Namespace zu aktivieren.
2. Erstellen Sie eine YAML-Datei mit dem Namen simple_pod.yaml und dem folgenden Inhalt:
```
    apiVersion: v1
    kind: Pod
    metadata:
      name: simple-pod
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80
```
  Das Label app gibt den Namen des kanonischen Dienstes an. Weitere Informationen finden Sie unter Kanonischen Dienst definieren.
3. Stellen Sie den Pod mit dem folgenden Befehl bereit. Ersetzen Sie NAMESPACE_NAME durch den Namen des Namespace, in dem Sie die automatische Sidecar-Einfügung aktiviert haben.
```
kubectl apply -f simple_pod.yaml -n NAMESPACE_NAME
```
4. Prüfen Sie, ob der Pod erstellt wurde:
```
kubectl get pods -n NAMESPACE_NAME
```
  Beispielausgabe:
```
NAME                             READY   STATUS    RESTARTS   AGE
simple-pod                       2/2     Running   0          9s
```
  Note: Prüfen Sie, ob in der Spalte „BEREIT“ 2/2 angezeigt wird. Das bedeutet, dass sowohl der Hauptcontainer als auch der Sidecar-Proxy ordnungsgemäß ausgeführt werden. Wenn ein anderer Wert angezeigt wird, ist die automatische Sidecar-Einfügung für den Namespace wahrscheinlich nicht aktiviert.
5. Erstellung des kanonischen Dienstes prüfen: Führen Sie den folgenden Befehl aus, um alle kanonischen Dienste im Namespace aufzulisten. Prüfen Sie, ob der kanonische Dienst my-app erstellt wurde.
```
kubectl get canonicalservices -n NAMESPACE_NAME
```
  Beispielausgabe:
```
  NAME          AGE
  my-app        3s
```
6. Bereinigen: Löschen Sie den Pod, den kanonischen Dienst und den Namespace:
```
kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME
kubectl delete canonicalservices my-app -n NAMESPACE_NAME
kubectl delete namespace NAMESPACE_NAME
```
Fehlerbehebung:
- Wenn der erforderliche kanonische Dienst nicht erstellt wird, lesen Sie den Hilfeartikel Probleme mit kanonischen Diensten in Cloud Service Mesh beheben.
- Wenn das Problem weiterhin besteht, können Sie zum Clustercontroller zurückkehren. Weitere Informationen finden Sie unter Zum clusterinternen kanonischen Dienstüberwacher zurückkehren.

Zum clusterinternen kanonischen Dienstüberwacher zurückkehren

Wenn Probleme mit dem Managed Canonical Service-Controller auftreten, können Sie den clusterinternen Controller mit dem folgenden Befehl neu installieren:

  kubectl apply -f \
  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.25/asm/canonical-service/controller.yaml

Nächste Schritte

Hier erfahren Sie mehr über: