Schritt-für-Schritt-Anleitung zur Fehlerbehebung in Cloud Service Mesh
In diesem Abschnitt wird beschrieben, wie Sie Probleme bei der Verwendung von Cloud Service Mesh beheben. Weitere Informationen finden Sie unter Support.
Schritte zur Fehlerbehebung
Führen Sie die folgenden allgemeinen Schritte aus, um Probleme mit Cloud Service Mesh zu beheben:
- Verwenden Sie die automatisierten Tools zur Validierung der Konfiguration.
- Prüfen Sie, ob ein häufig auftretendes Problem mit einer bekannten Lösung vorliegt.
- Grenzen Sie den Umfang des Problems ein.
- Prüfen Sie relevante Logs und Informationen.
- Erstellen Sie Diagnoselogs und holen Sie sich Hilfe.
Mit dem Diagnosetool für Cloud Service Mesh können häufig auftretende Konfigurationsprobleme ermittelt werden. Installieren Sie das Tool zur Fehlerbehebung mit dieser Anleitung.
Hinweise
Der kubeconfig-Kontext für Ihren Cluster muss in der kubeconfig-Datei verfügbar sein. Falls nicht, führen Sie den folgenden Befehl aus:
gcloud container clusters get-credentials CLUSTER_NAME \ --location=CLUSTER_LOCATION --project=PROJECT_NAME
Ersetzen Sie Folgendes:
CLUSTER_NAME
: Der Name Ihres Clusters.CLUSTER_LOCATION
: Die Zone oder Region Ihres Clusters.PROJECT_NAME
ist der Projektname
Prüfen Sie, ob die Standardanmeldedaten für Anwendungen erstellt wurden. Falls nicht, führen Sie einen der folgenden Befehle aus:
gcloud auth application-default login --billing-project=PROJECT_NAME
gcloud auth application-default set-quota-project PROJECT_NAME
Ersetzen Sie dabei
PROJECT_NAME
durch den Namen Ihres Projekts.
Status der Steuerungsebene ansehen
Die folgenden Befehle können Ihnen helfen, den Status der Cloud Service Mesh-Steuerungsebene zu verstehen:
Verwaltet
Liste mit dem Verbindungsstatus der Clients zur Cloud Service Mesh-Steuerungsebene abrufen:
gcloud beta container fleet mesh debug proxy-status \ --membership=MEMBERSHIP_NAME \ --location=MEMBERSHIP_LOCATION \ --project=PROJECT_NAME
Ersetzen Sie Folgendes:
MEMBERSHIP_NAME
: Der Name Ihrer Mitgliedschaft.MEMBERSHIP_LOCATION
: die Region für Ihre Mitgliedschaft. Sie können den Standort Ihrer Mitgliedschaft mitgcloud container fleet memberships list --project FLEET_PROJECT_ID
prüfen. Ersetzen Sie dabeiFLEET_PROJECT_ID
durch die ID des Flottenprojekts.PROJECT_NAME
ist der Projektname
In der folgenden Tabelle werden die möglichen Antworten beschrieben.
UNKNOWN (Standardeinstellung) Statusinformationen sind nicht verfügbar oder unbekannt. SYNCHRONISIERT Die Steuerungsebene hat die Konfiguration an den Client gesendet und eine Bestätigung vom Client erhalten. FEHLER Die Kontrollebene hat die Konfiguration an den Client gesendet und ein NACK vom Client erhalten. STALE Die Kontrollebene hat die Konfiguration an den Client gesendet, aber kein ACK oder NACK vom Client erhalten. NICHT GESENDET Die Konfiguration wurde nicht gesendet. – Nicht zutreffend. Nicht unterstützt Der Synchronisierungsstatus wird von unserer API zur Fehlerbehebung nicht unterstützt.
Clusterintern
kubectl get pods -n istio-system
kubectl describe -n istio-system
- Für alle Pods in istio-system:
kubectl logs -n istio-system -l istio --all-containers
istioctl version
istioctl proxy-status
kubectl get configmap istio -o yaml && kubectl get configmap istio-sidecar-injector -o yaml
kubectl top pods -n istio-system
Verwenden Sie die folgenden Befehle, um den Umfang der Bereitstellung zu verstehen:
kubectl get nodes
kubectl get services --all-namespaces
kubectl get pods --all-namespaces
Proxykonfigurationen ansehen
Der folgende Befehl kann Ihnen helfen, die Cloud Service Mesh-Proxykonfigurationen zu verstehen:
Verwaltet
gcloud beta container fleet mesh debug proxy-config POD_NAME.NAMESPACE \
--type=TYPE \
--membership=MEMBERSHIP_NAME \
--location=MEMBERSHIP_LOCATION \
--project=PROJECT_NAME
POD_NAME
: der Name Ihres Pods.NAMESPACE
: der Namespace Ihres Pods.TYPE
: Eine der folgenden Optionen: cluster, listeners, routes, endpoints, bootstrap, log, secret, all.MEMBERSHIP_NAME
: Der Name Ihrer Mitgliedschaft.MEMBERSHIP_LOCATION
: die Region für Ihre Mitgliedschaft. Sie können den Standort Ihrer Mitgliedschaft mitgcloud container fleet memberships list --project FLEET_PROJECT_ID
prüfen. Ersetzen Sie dabeiFLEET_PROJECT_ID
durch die ID des Flottenprojekts.PROJECT_NAME
ist der Projektname
Clusterintern
Mit istioctl proxy-config
können Sie Proxykonfigurationen für clusterinterne Steuerungsebenen aufrufen. Weitere Informationen finden Sie unter Debugging von Envoy und istiod.
Wenn das Problem weiterhin besteht, sehen Sie im nächsten Abschnitt nach, ob Ihr Problem bereits bekannt ist.
Auf häufig auftretende Probleme mit Lösungen prüfen
Sie können Zeit sparen, indem Sie prüfen, ob Ihre Symptome einem Problem in den folgenden Abschnitten zu häufig auftretenden Problemen mit bekannten Lösungen entsprechen. Die Abschnitte sind nach Cloud Service Mesh-Funktionsbereich gruppiert:
- Installationsprobleme
- Probleme mit der verwalteten Steuerungsebene
- Beobachtbarkeitsprobleme
- Probleme bei der Bereitstellung außerhalb von Google Cloud
- Proxy-Probleme
- Ressourcenprobleme
- Skalierungsprobleme
- Sicherheitsprobleme
- Probleme mit der Trafficverwaltung
- Webhook-Probleme
- Probleme mit Sidecar-Proxys
Wenn sich das Problem so nicht beheben lässt, lesen Sie den nächsten Abschnitt.
Umfang des Problems eingrenzen
Cloud Service Mesh besteht aus mehreren Technologien, die zusammenarbeiten. Das bedeutet, dass bestimmte Arten von Problemen mit bestimmten Funktionsbereichen oder Komponenten verknüpft sind. Jede dieser Komponenten generiert hilfreiche Logs. Bevor Sie anfangen, manuell die gesamten bereitgestellten Informationen zu analysieren, grenzen Sie den Umfang der Fehlerbehebung ein, indem Sie die folgenden Fragen beantworten:
- Tritt das Problem innerhalb der Steuerungsebene oder der Datenebene auf, beispielsweise bei
istiod
- oder Envoy-Proxys? - In welchem Funktionsbereich tritt das Problem auf, beispielsweise Netzwerk, Telemetrie oder Sicherheit?
- Gibt es Traffic-Verluste im gesamten Service Mesh oder in einer bestimmten Bereitstellung?
- Wird das Problem dadurch verursacht oder verschärft, dass der Traffic im Service Mesh nicht genügend skaliert werden kann?
- Hat das Problem Latenz- oder andere Leistungsprobleme zur Folge?
- Können Sie das Problem jederzeit reproduzieren?
- Trat das Problem erstmals nach einer kürzlichen Konfigurationsänderung in Istio, GKE usw. auf?
- Gibt es einen Anstieg des Traffics innerhalb des Service Mesh?
- Sind im Cluster besondere Features aktiviert oder enthält er untypische Bereitstellungen?
- Stellen Sie eine hohe CPU- oder Speicherauslastung fest? Wenn ja, welche Auslastung wäre im großen Maßstab zu erwarten?
- Gibt es Kontingentbeschränkungen, die beachtet werden müssen?
Relevante Logs und Informationen prüfen
Nachdem Sie den Umfang des Problems eingegrenzt haben, können Sie sich effektiver auf bestimmte Logs und Informationen konzentrieren. Informationen zu den von Cloud Service Mesh generierten Logs und deren Interpretation finden Sie unter Cloud Service Mesh-Logs interpretieren.