Probleme mit Ambient Networking beheben

Autopilot Standard

Vorschau

Dieses Produkt oder Feature unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Hinweis: Bevor Sie GKE Ambient Networking verwenden können, müssen Sie auf eine Zulassungsliste gesetzt werden. Füllen Sie das Anmeldeformular aus, um Zugriff anzufordern. Die Bearbeitung kann zwei bis drei Arbeitstage dauern.

Auf dieser Seite wird beschrieben, wie Sie Probleme mit Ambient Networking in der Google Kubernetes Engine (GKE) beheben und überprüfen. Darin finden Sie Anleitungen zum Prüfen des Status von Ambient-Komponenten im Cluster, zum Diagnostizieren von Problemen bei der Traffic-Authentifizierung und -Autorisierung, zum Überprüfen der Zertifikatausstellung sowie zum Untersuchen von Messwerten und Logs.

Prüfen, ob Komponenten installiert sind und ordnungsgemäß funktionieren

Clusterinterne Komponenten für den Ambient-Modus von Cloud Service Mesh werden im Namespace gke-managed-ambient installiert. Mit dem folgenden Befehl können Sie den Status aller relevanten Pods aufrufen:

kubectl get pods -n gke-managed-ambient

Prüfen, ob Traffic authentifiziert und autorisiert ist

Prüfen Sie mit dem Log-Explorer in derGoogle Cloud Console die Zugriffslogs, die den betreffenden Verbindungen entsprechen:

resource.type="k8s_container"
resource.labels.location="CLUSTER_LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
logName="projects/PROJECT_ID/logs/gke-ambient-node-proxy-accesslog"

In den Zugriffslogs werden Verbindungsdetails angezeigt, einschließlich des Authentifizierungs- und Autorisierungsstatus.

Logformat

Die folgenden Felder sind im jsonPayload des Zugriffsprotokolleintrags vorhanden:

Feld	Typ	Beschreibung
connection	Struktur (in Code: struct)	Verbindungsinformationen.
connection.src_ip	String	Quell-IP-Adresse der Verbindung.
connection.src_port	int	Quellport der Verbindung.
connection.dest_ip	String	Ziel-IP der Verbindung.
connection.dest_port	int	Zielport der Verbindung.
connection.direction	String	Richtung der Verbindung: {ingress, egress}
src	Struktur (in Code: struct)	Endpunktinformationen der Quelle.
src.spiffe_id	String	Die SPIFFE-Identität des Pods. Leer, wenn der Pod keine SPIFFE-Identität hat.
dst	Struktur (in Code: struct)	Endpunktinformationen des Ziels.
dst.spiffe_id	String	Die SPIFFE-Identität des Pods. Leer, wenn der Pod keine SPIFFE-Identität hat.
error_details	String	Details zum aufgetretenen Fehler (oder -, wenn kein Fehler aufgetreten ist).
timestamp	String	Zeitpunkt, zu dem die Verbindung beobachtet wurde (UTC).
tls_failure_reason	String	Fehlergrund für den TLS-Handshake. -, wenn die Verbindung nicht TLS ist.

Prüfen, ob Zertifikate erfolgreich ausgestellt wurden

Verwenden Sie den folgenden Befehl, um den Status von CertificateSigningRequests für Arbeitslast-Pods in Ihrem Cluster zu prüfen:

kubectl get csr

Sie sollten Bedingungen vom Typ „Genehmigt, Ausgestellt“ sehen, die in etwa so aussehen:

NAME                           AGE   SIGNERNAME                 CONDITION
gke-ambient-spiffe-csr-q8kqh   2s    spiffe.gke.io/fleet-svid   Approved,Issued
gke-ambient-spiffe-csr-t5px2   7s    spiffe.gke.io/fleet-svid   Approved,Issued

Monitoring-Messwerte für Netzwerkdienste

Zusätzlich zu den standardmäßigen Cloud Observability-Messwerten wird das Ambient Networking von Cloud Service Mesh in Network Services Monitoring eingebunden, um detaillierte Layer-4-Netzwerktelemetrie bereitzustellen.

Weitere Informationen finden Sie in der Übersicht zur Überwachung von Netzwerkdiensten und in der Referenz zu Messwerten für die Überwachung von Netzwerkdiensten.