Anthos Service Mesh 1.12 hat das Ende seines Lebenszyklus 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

Probleme mit kanonischen Diensten in Anthos Service Mesh beheben

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

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

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

Wenn einer Ihrer Cluster eine frühere Version von ASM (< 1.6.8) ausführt oder ein Cluster ASM mit deaktiviertem kanonischen Dienstüberwacher ausführt, werden diese Cluster (und darauf ausgeführte Dienste) nicht in der Service Mesh-UI angezeigt. Wenn Sie kanonische Dienste verwenden möchten, müssen Sie jeden Cluster auf Anthos Service Mesh 1.6.8 oder höher aktualisieren und die Standardinstallationsoption verwenden, die den kanonischen Dienstüberwacher enthält. Weitere Informationen finden Sie unter Anthos Service Mesh auf die neueste Version aktualisieren, wenn Sie Ihre Cluster in GKE verwenden oder Anthos 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.

Anthos Service Mesh ist nicht auf dem Cluster installiert

Wenn Anthos Service Mesh in keinem Ihrer Cluster installiert ist, werden diese Cluster nicht in der Service Mesh-UI angezeigt. Weitere Informationen zur Installation von Anthos Service Mesh finden Sie in der Dokumentation zu Anthos 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 zur Anmeldung bei 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 Anthos 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 Anthos 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.