Probleme mit kanonischen Diensten 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äufig auftretende 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. Wenn Sie kanonische Dienste verwenden möchten, müssen Sie jeden Cluster auf Cloud 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 Cloud Service Mesh auf die neueste Version aktualisieren, wenn Sie Ihre Cluster in GKE verwenden, oder Cloud Service Mesh lokal aktualisieren.

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 Cloudverbunden sein. Weitere Informationen zum Verbinden Ihres Clusters mit Google Cloudfinden 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:

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 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.

Probleme mit verwalteten kanonischen Controllern beheben

1. Funktionstatus prüfen:Führen Sie den folgenden Befehl aus, wobei FLEET_PROJECT_ID die ID Ihres Flotten-Hostprojekts ist. Normalerweise wird die FLEET_PROJECT_ID standardmäßig erstellt und hat denselben Namen wie das Projekt.

  gcloud container fleet mesh describe --project FLEET_PROJECT_ID
  

Beispielausgabe:

      membershipStates:
        projects/<project-number>/locations/<location>/memberships/<membership-name>:
          state:
            code: OK
            description: 
              Revision(s) ready for use: istiod-asm-183-2.
              All Canonical Services have been reconciled successfully.

2. Aktionen auf Grundlage von state.code ausführen:

Prüfen Sie in der Ausgabe zum Feature-Status den Status Ihres Clusters. Prüfen Sie den Wert von state.code. Er gibt Aufschluss über den aktuellen Status des verwalteten Kundencenters. Implementieren Sie je nach Wert von state.code die entsprechenden Aktionen:

• MISSING:

  1. Warten Sie eine Stunde, um mögliche Verzögerungen bei der Initialisierung zu berücksichtigen.
  2. Führen Sie den Befehl gcloud container fleet mesh describe --project <FLEET_PROJECT_ID> noch einmal aus. Wenn state.code immer noch fehlt, wenden Sie sich bitte an den Google Cloud-Support.

• WARNING/ERROR:

  1. Weitere Informationen zum Fehler finden Sie in der servicemesh.conditions.
  2. Wenn die Bedingung CANONICAL_SERVICE_ERROR erfüllt ist, tritt beim verwalteten kanonischen Dienstüberwacher ein Problem auf. Andernfalls liegt das Problem wahrscheinlich nicht am kanonischen Dienstüberwacher.
  3. Wenden Sie sich in beiden Fällen an den Google Cloud-Support, um weitere Schritte zur Fehlerbehebung zu erhalten.

• OK:In der folgenden Tabelle finden Sie Aktionen, die auf dem state.description-Text basieren: