Anthos Service Mesh 1.13 hat das Ende des Produktzyklus erreicht und wird nicht mehr unterstützt. Siehe Upgraden von früheren Versionen.

Lesen Sie die aktuelle Dokumentation oder wählen Sie eine andere verfügbare Version aus:

Verfügbare Versionen

Diese Seite wurde von der Cloud Translation API übersetzt.

Probleme mit dem kanonischen Dienst in Cloud Service Mesh beheben

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

In diesem Abschnitt werden häufige Cloud Service Mesh-Probleme und deren Behebung erläutert. Weitere Informationen finden Sie unter Support.

Cluster in Ihrem Mesh führen eine ältere Version von Cloud Service Mesh aus

Wenn in einem Ihrer Cluster eine frühere Version von Cloud Service Mesh (<1.6.8) oder ein Cluster Cloud Service Mesh mit deaktiviertem kanonischen Dienstcontroller ausgeführt wird, werden diese Cluster (und die darauf ausgeführten Dienste) nicht in der Service Mesh-UI angezeigt. Kanonical Diensten, müssen Sie jeden Cluster auf Cloud Service Mesh 1.6.8 oder höher aktualisieren und Verwenden Sie die Standardinstallationsoption, die den Canonical Service Controller enthält. Weitere Informationen finden Sie unter Cloud Service Mesh auf die neueste Version upgraden. ob Ihre Cluster in GKE sind oder Cloud Service Mesh lokal aktualisieren wenn Ihre Cluster lokal sind.

Wenn Sie den Dienstüberwacher nicht in Ihren Clustern installieren möchten, können Sie den verwalteten kanonischen Dienstüberwacher (derzeit als Vorschau) für Ihr Mesh aktivieren.

Weitere Informationen zum Aktivieren des kanonischen Dienstüberwachers finden Sie unter Kanonischen Dienstüberwacher aktivieren.

Cloud Service Mesh ist nicht auf dem Cluster installiert

Wenn Cloud Service Mesh in keinem Ihrer Cluster installiert ist, werden diese Cluster nicht in der Service Mesh-UI angezeigt. Weitere Informationen zur Installation von Cloud Service Mesh finden Sie in der Dokumentation zu Cloud Service Mesh.

Sie sind nicht beim lokalen Cluster angemeldet

Wenn Sie einen lokalen Cluster im Mesh-Netzwerk haben und nicht im Cluster angemeldet sind, können Sie die Dienste, die diesem Cluster entsprechen, nicht aufrufen. Damit Sie diese Dienste im Dashboard aufrufen können, müssen Sie sich beim Cluster anmelden. Weitere Informationen zum Anmelden in einem Cluster finden Sie unter Über die Cloud Console bei einem Cluster anmelden.

Der lokale Cluster ist nicht erreichbar

Wenn Sie einen lokalen Cluster im Mesh-Netzwerk haben, der nicht über den Connect-Agent erreichbar ist, können Sie die Dienste, die diesem Cluster entsprechen, nicht sehen. Damit diese Dienste im Dashboard angezeigt werden können, muss Ihr Cluster ausgeführt werden und mit Google Cloud verbunden sein. Weitere Informationen zum Verbinden Ihres Clusters mit Google Cloud finden Sie unter Connect-Übersicht.

Ein Dienst mit definierten SLOs wird nicht 1:1 einem kanonischen Dienst zugeordnet

Vor der Umstellung auf kanonische Dienste zeigte Cloud Service Mesh Dashboards für Kubernetes-Dienste. Während Kubernetes-Dienste und standardmäßige kanonische Dienste oft übereinstimmen, ist es möglich, dass ein Kubernetes-Dienst nicht automatisch mit dem entsprechenden kanonische Dienst übereinstimmt oder dass die standardmäßige kanonische Dienstgrenze nicht gewünscht ist.

Wenn Sie Service Level Objectives (SLOs) für vorhandene Dienste eingerichtet haben, die nicht automatisch einem kanonischen Dienst zugeordnet werden können, ist eine Migration nicht möglich. Wenn Sie kanonische Dienste verwenden möchten, müssen Sie die SLOs für den problematischen Dienst löschen. Wenn Sie möchten, können Sie neue SLOs für die kanonischen Dienste erstellen, die diesem Dienst am ehesten entsprechen, bevor Sie das alte SLO löschen.

Mein Dashboard zeigt nicht die erwarteten Inhalte

Die Service Mesh-Dienst-Dashboards beziehen sich jeweils auf einen kanonischen Dienst in Ihrem Service Mesh, wobei ein kanonischer Dienst ein logisches Dienstkonzept ist, das alle relevanten Arbeitslasten, Regionen usw. umfasst.

Standardmäßig definieren vorhandene Labels in jeder Arbeitslastinstanz (Pod oder WorkloadEntry) kanonische Dienste und befolgen diese Regeln in absteigender Reihenfolge:

Das Label service.istio.io/canonical-name wurde bereits explizit festgelegt. Es werden keine weiteren Maßnahmen ergriffen.
Andernfalls wird das Label service.istio.io/canonical-name hinzugefügt und der Wert auf das Label app.kubernetes.io/name festgelegt.
Andernfalls wird das Label service.istio.io/canonical-name hinzugefügt und der Wert auf das Label app festgelegt.
Andernfalls wird das Label service.istio.io/canonical-name hinzugefügt und der Wert wird auf den name der besitzenden Arbeitslast festgelegt. Die „besitzende Arbeitslast” in diesem Fall, wenn der Pod einzeln oder das Deployment, das StatefulSet usw. mit einer höheren Orchestrierung bereitgestellt wird.

Für die meisten idiomatischen Nutzer von Kubernetes und Kube Run/Knative sind diese Regeln direkt auf die Verwaltung Ihrer Dienste und Arbeitslasten ausgerichtet.

In individuelleren oder komplexeren Anwendungsfällen hingegen erfassen die Standardheuristik Ihren Dienst nicht korrekt, und das Cloud Service Mesh-Dashboard enthält nicht den erwarteten Inhalt.

Sie können das Problem beheben, indem Sie den Bereich des kanonischen Diensts manuell definieren.

Umfang eines Dienstes manuell definieren

Nach Möglichkeit sollten Sie die Standardmechanismen zur automatischen Gruppierung verwenden. Wenn Sie diese Standardgruppierungen überschreiben möchten, können Sie dazu das Kubernetes-Label service.istio.io/canonical-name auf Ihre Kubernetes Pod- und WorkloadEntry-Konfigurationen anwenden.

Weitere Informationen finden Sie unter kanonischen Dienst manuell definieren.