Proxylogs anfordern
Cloud Service Mesh unterstützt zwei verschiedene Arten von Zugriffslogs in Cloud Logging: Traffic-Logs (auch sogenannte Google Cloud Observability-Zugriffslogs). Envoy-Zugriffslogs. Auf dieser Seite erfahren Sie, wie Sie aktivieren, deaktivieren, ansehen und interpretieren. Beachten Sie, dass Traffic-Logs ist standardmäßig aktiviert.
Zugriffslogs aktivieren und deaktivieren
Verwaltetes Cloud Service Mesh
Envoy-Zugriffslogs
Führen Sie den folgenden Befehl aus, um Envoy-Zugriffslogs zu aktivieren und Traffic zu deaktivieren Protokolle:
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: enable-envoy-disable-sd
namespace: istio-system
spec:
accessLogging:
- providers:
- name: envoy
- providers:
- name: stackdriver
disabled: true
EOF
Der Anbietername für das Traffic-Log lautet stackdriver
.
Trafficlogs
Standardmäßig sind Trafficlogs aktiviert und Envoy-Zugriffslogs deaktiviert. Wenn Sie haben zuvor Envoy-Zugriffslogs aktiviert und möchten nun Trafficlogs und Führen Sie den folgenden Befehl aus, um Envoy-Zugriffslogs zu deaktivieren:
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: disable-envoy-enable-sd
namespace: istio-system
spec:
accessLogging:
- providers:
- name: envoy
disabled: true
- providers:
- name: stackdriver
EOF
Beides
Führen Sie folgenden Befehl aus, um sowohl Zugriffs- als auch Traffic-Logs von Envoy zu aktivieren Befehl:
cat <<EOF | kubectl apply -n istio-system -f - apiVersion: telemetry.istio.io/v1alpha1 kind: Telemetry metadata: name: enable-envoy-and-sd-access-log namespace: istio-system spec: accessLogging: - providers: - name: envoy - name: stackdriver EOF
Führen Sie folgenden Befehl aus, um sowohl Zugriffs- als auch Traffic-Logs von Envoy zu deaktivieren. Befehl:
cat <<EOF | kubectl apply -n istio-system -f - apiVersion: telemetry.istio.io/v1alpha1 kind: Telemetry metadata: name: disable-envoy-and-sd namespace: istio-system spec: accessLogging: - providers: - name: envoy disabled: true - providers: - name: stackdriver disabled: true EOF
Verwaltet: istiod
Envoy-Zugriffslogs
Führen Sie die folgenden Befehle aus, um das Envoy-Zugriffs-Logging zu aktivieren:
Führen Sie den folgenden Befehl aus, um
accessLogFile: /dev/stdout
hinzuzufügen:cat <<EOF | kubectl apply -f - apiVersion: v1 data: mesh: |- accessLogFile: /dev/stdout kind: ConfigMap metadata: name: istio-release-channel namespace: istio-system EOF
Dabei ist release-channel Ihre Release-Version (
asm-managed
,asm-managed-stable
oderasm-managed-rapid
).Führen Sie den folgenden Befehl aus, um die ConfigMap aufzurufen:
kubectl get configmap istio-release-channel -n istio-system -o yaml
Um zu prüfen, ob das Zugriffs-Logging aktiviert ist, achten Sie darauf, dass die Im Abschnitt
mesh:
wird die ZeileaccessLogFile: /dev/stdout
angezeigt.... apiVersion: v1 data: mesh: | .... accessLogFile: /dev/stdout ...
Trafficlogs
Traffic-Logs sind standardmäßig aktiviert.
Clusterintern
Envoy-Zugriffslogs
Weitere Informationen finden Sie unter Zugriffs-Logging von Envoy aktivieren.
Trafficlogs
Traffic-Logs sind standardmäßig aktiviert, es sei denn, Cloud Service Mesh ist in Google Distributed Cloud mit Istio CA (früher Citadel) installiert.
So aktivieren Sie Trafficlogs in Google Distributed Cloud mit Istio CA
bei der Installation von Cloud Service Mesh im Cluster
Verwenden Sie dann das Flag --option stackdriver
. Alternativ können Sie Traffic aktivieren
Logs in Google Distributed Cloud mit Istio CA
nach der Installation von Cloud Service Mesh im Cluster.
Zugriffslogs ansehen
Envoy-Zugriffslogs
Befehlszeile
Führen Sie den folgenden Befehl aus, um Envoy-Zugriffslogs im istio-proxy-Log anzusehen:
kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy
Log-Explorer
So rufen Sie Envoy-Zugriffslogs in der Log-Explorer:
Rufen Sie den Log-Explorer auf:
Wählen Sie das entsprechende Google Cloud-Projekt aus.
Führen Sie die folgende Abfrage aus:
resource.type="k8s_container" \
resource.labels.container_name="istio-proxy"
resource.labels.cluster_name="CLUSTER_NAME" \
resource.labels.namespace_name="NAMESPACE_NAME" \
resource.labels.pod_name="POD_NAME"
Trafficlogs
So rufen Sie die Traffic-Logs auf: Log-Explorer:
Rufen Sie den Log-Explorer auf:
Wählen Sie das entsprechende Google Cloud-Projekt aus.
Führen Sie die folgende Abfrage aus, je nachdem, ob Sie Client- oder Serverzugriffsprotokolle:
Serverprotokolle
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"
Clientprotokolle
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"
So rufen Sie während des folgenden Zeitraums Traffic-Logs auf der Cloud Service Mesh-Seite für einen Dienst auf: für einen bestimmten Zeitraum, gehen Sie so vor:
Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.
Wählen Sie unter Dienste den Namen des Dienstes aus, den Sie prüfen möchten.
Rufen Sie die Seite Messwerte auf.
Geben Sie über das Drop-down-Menü Zeitspanne eine Zeitspanne an oder Mit der Zeitachse eine benutzerdefinierte Spanne festlegen
Klicken Sie unter filter_list Filteroption auswählen auf Traffic-Logs ansehen
Das Traffic-Log heißt server-accesslog-stackdriver und ist im Anhang mit der entsprechenden überwachten Ressource (k8s_container oder gce_instance) Ihr Dienst ist verwenden. Das Traffic-Log enthält die folgenden Informationen:
Eigenschaften von HTTP-Anfragen wie ID, URL, Größe, Latenz und allgemeine Header.
Informationen zu Quell- und Zielarbeitslast, z. B. Name, Namespace, Identität und allgemeine Labels.
Wenn Tracing aktiviert ist, werden Trace-Informationen, z. B. Stichprobenerfassung, Trace-ID und Span-ID, angezeigt.
Ein Beispiel für einen Logeintrag sieht so aus:
{ insertId: "1awb4hug5pos2qi" httpRequest: { requestMethod: "GET" requestUrl: "YOUR-INGRESS/productpage" requestSize: "952" status: 200 responseSize: "5875" remoteIp: "10.8.0.44:0" serverIp: "10.56.4.25:9080" latency: "1.587232023s" protocol: "http" } resource: { type: "k8s_container" labels: { location: "us-central1-a" project_id: "YOUR-PROJECT" pod_name: "productpage-v1-76589d9fdc-ptnt9" cluster_name: "YOUR-CLUSTER-NAME" container_name: "productpage" namespace_name: "default" } } timestamp: "2020-04-28T19:55:21.056759Z" severity: "INFO" labels: { destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage" response_flag: "-" destination_service_host: "productpage.default.svc.cluster.local" source_app: "istio-ingressgateway" service_authentication_policy: "MUTUAL_TLS" source_name: "istio-ingressgateway-5ff85d8dd8-mwplb" mesh_uid: "YOUR-MESH-UID" request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632" destination_namespace: "default" source_principal: "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account" destination_workload: "productpage-v1" destination_version: "v1" source_namespace: "istio-system" source_workload: "istio-ingressgateway" destination_name: "productpage-v1-76589d9fdc-ptnt9" destination_app: "productpage" } trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536" receiveTimestamp: "2020-04-29T03:07:14.362416217Z" spanId: "43226343ca2bb2b1" traceSampled: true logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver" receiveTimestamp: "2020-04-28T19:55:32.185229100Z" }
Cloud Service Mesh-Telemetrie interpretieren
In den folgenden Abschnitten erfahren Sie, wie Sie den Status Ihres Mesh-Netzwerks prüfen und Telemetrie mit hilfreichen Details, die Sie dabei unterstützen, Fehlerbehebung.
Messwerte der Steuerungsebene interpretieren
Verwaltetes Cloud Service Mesh
Cloud Service Mesh mit einer verwalteten Cloud Service Mesh-Steuerungsebene unterstützt keine Messwerte der Steuerungsebene.
Verwaltet: istiod
Cloud Service Mesh mit einer verwalteten istiod
-Steuerungsebene unterstützt keine
die Messwertprüfung der Steuerungsebene.
Clusterintern
Beim Installieren von Cloud Service Mesh mit der clusterinternen Steuerungsebene istiod
exportiert Messwerte zur Monitoring-Funktion standardmäßig nach Google Cloud Observability.
istiod
stellt diesen Messwerte mit das Präfix istio.io/control
voran und bietet Einblicke in den Status der Steuerungsebene, z. B. die Anzahl der Proxys, die mit jeder Instanz der Steuerungsebene verbunden sind, Konfigurationsereignisse sowie Push- und Validierungen.
Mit den folgenden Schritten können Sie die Steuerungsebene beobachten oder Fehler beheben.
Beispiel-Dashboard laden:
git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh
Installieren Sie das Cloud Service Mesh-Dashboard:
gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json
Suchen Sie in der Liste nach einem Dashboard mit dem Namen
Istio Control Plane Dashboard
. Weitere Informationen finden Sie unter Installiertes Dashboard ansehen.
Eine vollständige Liste der verfügbaren Messwerte finden Sie unter Exportierte Messwerte.
Konfigurationsverzögerungen diagnostizieren
Verwaltetes Cloud Service Mesh
Cloud Service Mesh mit einer verwalteten Cloud Service Mesh-Steuerungsebene unterstützt keine bei der Diagnose von Konfigurationsverzögerungen.
Verwaltet: istiod
Cloud Service Mesh mit einer verwalteten Istio-Steuerungsebene unterstützt keine bei der Diagnose von Konfigurationsverzögerungen.
Clusterintern
In den folgenden Schritten wird erläutert, wie Sie mit dem Messwert pilot_proxy_convergence_time
eine Verzögerung zwischen einer Konfigurationsänderung und allen konvergenten Proxys feststellen können.
Führen Sie einen Shell-Befehl in einem Pod aus:
kubectl debug --image istio/base --target istio-proxy -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -- curl -s
Greifen Sie auf
localhost:15014
undgrep
fürconvergence
in Messwerten zu:curl http://localhost:15014/metrics | grep convergence
Traffic-Logs interpretieren
Im Folgenden wird erläutert, wie Sie die Traffic-Logs zur Fehlerbehebung verwenden Verbindungsprobleme. Traffic-Logs sind standardmäßig aktiviert.
Cloud Service Mesh exportiert Daten in Traffic-Logs, die Ihnen beim Debuggen des folgenden Arten von Problemen:
- Datenverkehr und Fehler
- End-to-End-Anfragerouting
Traffic-Logs sind standardmäßig für Cloud Service Mesh-Installationen in
Google Kubernetes Engine Sie können Trafficlogs aktivieren, indem Sie asmcli install
noch einmal ausführen. Verwenden Sie
die ursprünglich installiert wurden, lassen Sie jedoch das benutzerdefinierte Overlay weg,
deaktiviert Stackdriver.
Es gibt zwei Arten von Traffic-Logs:
Serverzugriffsprotokolle bieten eine serverseitige Ansicht von Anfragen. Diese befinden sich unter
server-accesslog-stackdriver
und sind an die überwachte Ressourcek8s_container
angehängt. Verwenden Sie die folgende URL-Syntax, um serverseitige Zugriffslogs anzuzeigen:https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
Clientzugriffslogs bieten eine clientseitige Ansicht von Anfragen. Sie befinden sich unter
client-accesslog-stackdriver
und sind an die überwachte Ressourcek8s_pod
angehängt. Verwenden Sie die folgende URL-Syntax, um clientseitige Zugriffslogs anzuzeigen:https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
Zugriffslogs enthalten folgende Informationen:
- HTTP-Anfrageattribute, z. B. ID, URL, Größe, Latenz und allgemeine Header.
- Informationen zu Quell- und Zielarbeitslast, z. B. Name, Namespace, Identität, und allgemeine Bezeichnungen.
- Informationen zu kanonischen Quell- und Zieldiensten sowie Revisionsinformationen.
- Wenn Tracing aktiviert ist, enthalten die Logs Trace-Informationen wie Sampling, Trace-ID und Span-ID.
Traffic-Logs können die folgenden Labels enthalten:
route_name
upstream_cluster
X-Envoy-Original-Path
Das ist ein Beispiel-Logeintrag:
{ "insertId": "1j84zg8g68vb62z", "httpRequest": { "requestMethod": "GET", "requestUrl": "http://35.235.89.201:80/productpage", "requestSize": "795", "status": 200, "responseSize": "7005", "remoteIp": "10.168.0.26:0", "serverIp": "10.36.3.153:9080", "latency": "0.229384205s", "protocol": "http" }, "resource": { "type": "k8s_container", "labels": { "cluster_name": "istio-e2e22", "namespace_name": "istio-bookinfo-1-68819", "container_name": "productpage", "project_id": "***", "location": "us-west2-a", "pod_name": "productpage-v1-64794f5db4-8xbtf" } }, "timestamp": "2020-08-13T21:37:42.963881Z", "severity": "INFO", "labels": { "protocol": "http", "upstream_host": "127.0.0.1:9080", "source_canonical_service": "istio-ingressgateway", "source_namespace": "istio-system", "x-envoy-original-path": "", "source_canonical_revision": "latest", "connection_id": "32", "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local", "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local", "destination_version": "v1", "destination_workload": "productpage-v1", "source_workload": "istio-ingressgateway", "destination_canonical_revision": "v1", "mesh_uid": "cluster.local", "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account", "x-envoy-original-dst-host": "", "service_authentication_policy": "MUTUAL_TLS", "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage", "response_flag": "-", "log_sampled": "false", "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local", "destination_name": "productpage-v1-64794f5db4-8xbtf", "destination_canonical_service": "productpage", "destination_namespace": "istio-bookinfo-1-68819", "source_name": "istio-ingressgateway-6845f6d664-lnfvp", "source_app": "istio-ingressgateway", "destination_app": "productpage", "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4", "route_name": "default" }, "logName": "projects/***/logs/server-accesslog-stackdriver", "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f", "receiveTimestamp": "2020-08-13T21:37:48.758673203Z", "spanId": "633831cb1fda4fd5", "traceSampled": true }
Sie können dieses Protokoll auf verschiedene Arten verwenden:
- Einbindung in Cloud Trace, ein optionales Feature in Cloud Service Mesh.
- Export von Trafficlogs nach BigQuery, um Abfragen auszuführen, wie die Auswahl aller Anfragen, die länger als 5 Sekunden dauern
- Logbasierte Messwerte erstellen
404
- und503
-Fehler beheben
404
- und 503
-Fehler beheben
Im folgenden Beispiel wird erläutert, wie Sie dieses Log zur Fehlerbehebung verwenden, wenn eine Anfrage mit dem Antwortcode 404
oder 503
fehlschlägt.
Suchen Sie im Client-Zugriffslog nach einem Eintrag wie dem folgenden:
httpRequest: { requestMethod: "GET" requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php" requestSize: "2088" status: 404 responseSize: "75" remoteIp: "10.168.0.26:34165" serverIp: "10.36.3.149:8080" latency: "0.000371440s" protocol: "http" }
Gehen Sie zu den Labels im Zugriffslogeintrag. Suchen Sie das Feld
response_flag
, das in etwa so aussieht:response_flag: "NR"
Der Wert
NR
ist ein Akronym fürNoRoute
. Das bedeutet, dass keine Route für das Ziel gefunden wurde oder es keine übereinstimmende Filterkette für eine nachgelagerte Verbindung gibt. Mit dem Labelresponse_flag
können Sie auch503
-Fehler beheben.Wenn Sie sowohl in den Client- als auch den Serverzugriffslogs
503
-Fehler sehen, prüfen Sie, ob die Portnamen für die einzelnen Dienste mit dem Namen des verwendeten Protokolls übereinstimmen. Beispiel: Wenn ein Golang-Binärclient über HTTP mit einem Golang-Server verbunden ist, der Port aberhttp2
lautet, wird das Protokoll nicht automatisch neu ausgehandelt.
Weitere Informationen finden Sie unter Antwort-Flags.
Envoy-Zugriffslogs interpretieren
In den folgenden Schritten wird erläutert, wie Sie die Envoy-Zugriffslogs zum Anzeigen von Traffic verwenden zur Fehlerbehebung zwischen beiden Enden einer Verbindung.
Envoy-Zugriffslogs sind nützlich für die Diagnose von Problemen wie:
- Datenverkehr und Fehler
- End-to-End-Anfragerouting
Envoy-Zugriffslogs sind in Cloud Service Mesh nicht standardmäßig aktiviert und können für die Cluster in einem Mesh-Netzwerk aktiviert.
Sie können Verbindungs- oder Anfragefehler beheben, indem Sie Aktivitäten generieren in die eine HTTP-Anfrage auslöst, und prüft dann die zugehörigen -Anfrage in den Quell- oder Ziellogs.
Wenn Sie eine Anfrage auslösen und diese in den Quellproxy-Logs ausgewiesen wird, bedeutet dies, dass die iptables
-Traffic-Weiterleitung ordnungsgemäß funktioniert und der Envoy-Proxy den Traffic verarbeitet. Generieren Sie ein Envoy, wenn in den Logs Fehler angezeigt werden
Konfigurations-Dump und prüfen Sie die Konfiguration des Envoy-Clusters, um sicherzustellen,
richtig. Wenn Sie die Anfrage sehen, das Log jedoch keine Fehler enthält, prüfen Sie stattdessen die Zielproxy-Logs.
Wenn die Anfrage in den Zielproxy-Logs auftritt, gibt das an, dass das Mesh-Netzwerk ordnungsgemäß funktioniert. Wenn stattdessen ein Fehler angezeigt wird, führen Sie einen Envoy-Konfigurationsdump aus und verifizieren Sie die korrekten Werte für den in der Listener-Konfiguration festgelegten Traffic-Port.
Wenn das Problem nach den vorherigen Schritten weiterhin besteht, kann Envoy das Protokoll zwischen dem Sidecar und dem Anwendungs-Pod möglicherweise nicht automatisch verhandeln. Achten Sie darauf, dass der Portname des Kubernetes-Dienstes, z. B. http-80
, mit dem Protokoll übereinstimmt, das von der Anwendung verwendet wird.
Logs mit dem Log-Explorer abfragen
Sie können die Log-Explorer-Oberfläche verwenden.
um bestimmte Envoy-Zugriffslogs abzufragen. Um beispielsweise alle Anfragen abzufragen,
haben MULTUAL_TLS
aktiviert und verwenden das Protokoll grpc
. Fügen Sie Folgendes an den
Abfrage für Serverzugriffslogs:
labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"
Richtlinie für Zugriffslogs festlegen
Verwaltetes Cloud Service Mesh
So konfigurieren Sie Zugriffslogs für Cloud Service Mesh mit einer verwalteten Cloud Service Mesh-Steuerungsebene, siehe Zugriffslogs aktivieren
Verwaltet: istiod
So konfigurieren Sie Zugriffslogs für Cloud Service Mesh mit einer verwalteten istiod-Steuerungsebene, siehe Zugriffslogs aktivieren
Clusterintern
So legen Sie Zugriffslogrichtlinien für Cloud Service Mesh mit der clusterinternen Steuerung fest: Flugzeug:
Erstellen Sie eine benutzerdefinierte Overlay-Datei
IstioOperator
, die den entsprechendenAccessLogPolicyConfig
Werte für Ihr Szenario.Übergeben Sie diese Datei mit der Option
--custom_overlay
anasmcli
, um die Konfiguration der Steuerungsebene im Cluster zu aktualisieren. Informationen zum Ausführen vonasmcli install
mit einer benutzerdefinierten Overlay-Datei finden Sie unter Mit optionalen Features installieren.
Dienst- oder arbeitslastspezifische Informationen aufrufen
Wenn Sie ein Problem mit einem bestimmten Dienst oder einer Arbeitslast haben, nicht eins, das sich auf das gesamte Mesh-Netzwerk auswirkt, prüfen Sie die einzelnen Envoy-Proxys und erfassen Sie von diesen relevante Informationen. Mit pilot-agent
können Sie Informationen zu einer bestimmten Arbeitslast und ihren Proxys erfassen:
kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- pilot-agent request GET SCOPE
Im Beispiel ist SCOPE eine der folgenden Optionen:
certs
– Zertifikate in der Envoy-Instanzclusters
– Cluster mit konfiguriertem Envoyconfig_dump
– Löscht die Envoy-Konfigurationlisteners
– Listener mit konfiguriertem Envoylogging
– Logging-Einstellungen aufrufen und ändernstats
– Envoy-Statistikenstats/prometheus
– Envoy-Statistiken als Prometheus-Datensätze
Proxy-Socket-Status aufrufen
Sie können den Status von Envoy-Proxy-Sockets mithilfe des folgenden Prozesses direkt prüfen.
Rufen Sie eine Liste der vorhandenen Sockets auf, einschließlich der Sockets mit dem Status
TIME_WAIT
, die sich negativ auf die Skalierbarkeit auswirken können, wenn deren Anzahl hoch ist:kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
Zusammenfassung der Socket-Statistiken anzeigen:
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -s
Weitere Informationen finden Sie unter Einführung in den ss-Befehl.
istio-proxy
- und istio-init
-Logs
Rufen Sie außerdem die istio-proxy
-Logs ab und prüfen Sie deren Inhalt auf Fehler, die möglicherweise die Ursache des Problems sein:
kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy
Sie können dies auch für den Container init
tun:
kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init
Nächste Schritte
In Cloud Trace einbinden Cloud Trace ist ein optionales Feature. Cloud Service Mesh.