Sie lesen die Dokumentation für Anthos Service Mesh 1.7. Lesen Sie die aktuelle Dokumentation oder wählen Sie eine andere verfügbare Version aus:

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.

Kubernetes-Arbeitslasten ohne einen Kubernetes-Dienst werden nicht angezeigt

Sehen Sie „Kubernetes-Arbeitslasten ohne Kubernetes-Dienst werden nicht angezeigt. Erstellen Sie einen Kubernetes-Dienst für jede Arbeitslast, damit sie unten angezeigt werden.”, müssen Sie manuell zu kanonischen Diensten migrieren.

Für dieses Problem gibt es zwei Hauptursachen:

  1. Cluster in Ihrem Mesh führen eine ältere Version von Anthos Service Mesh aus (< 1.6.8)
  2. Ein Dienst mit definierten SLOs wird nicht 1:1 einem kanonischen Dienst zugeordnet

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, sind Sie nicht berechtigt, auf kanonischen Diensten basierende Dashboards zu verwenden. Wenn Sie kanonische Dienste verwenden möchten, müssen Sie alle Cluster auf Anthos Service Mesh 1.6.8 oder höher aktualisieren. 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.

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:

  1. Das Label service.istio.io/canonical-name wurde bereits explizit festgelegt. Es werden keine weiteren Maßnahmen ergriffen.
  2. Andernfalls wird das Label service.istio.io/canonical-name hinzugefügt und der Wert auf das Label app.kubernetes.io/name festgelegt.
  3. Andernfalls wird das Label service.istio.io/canonical-name hinzugefügt und der Wert auf das Label app festgelegt.
  4. 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.