You can gain insights into what individual components are doing by inspecting their logs or peering inside via introspection. If that’s insufficient, the steps below explain how to get under the hood.
istioctl allows you to inspect the current xDS of a given Envoy from its admin interface (locally) or from Pilot using the
For example, to retrieve the configured clusters in an Envoy via the admin interface run the following command:
$ istioctl proxy-config endpoint <pod-name> clusters
To retrieve endpoints for a given pod in the application namespace from Pilot, run the following command:
$ istioctl proxy-config pilot -n application <pod-name> eds
proxy-config command also allows you to retrieve the state of the entire mesh from Pilot using the following command:
$ istioctl proxy-config pilot mesh ads
To debug Istio with
gdb, you will need to run the debug images of Envoy / Mixer / Pilot. A recent
gdb and the golang extensions (for Mixer/Pilot or other golang components) is required.
kubectl exec -it PODNAME -c [proxy | mixer | pilot]
Find process ID: ps ax
gdb -p PID binary
For go: info goroutines, goroutine x bt
Tcpdump doesn’t work in the sidecar pod - the container doesn’t run as root. However any other container in the same pod will see all the packets, since the
network namespace is shared.
iptables will also see the pod-wide configuration.
Communication between Envoy and the app happens on 127.0.0.1, and is not encrypted.