istioctl proxy-config: Dump Envoy Config
istioctl proxy-config (aliased pc) prints the actual Envoy configuration a given sidecar is running: clusters, listeners, routes, endpoints, and secrets.
When traffic goes to the wrong place, proxy-status tells you if config synced but proxy-config tells you what that config is. It is the ground truth for a single proxy.
What it does
istioctl proxy-config queries a specific proxys admin API through istiod and prints the requested slice of its Envoy config. Subcommands are cluster, listener, route, endpoint, secret, bootstrap, and all, so you can see exactly what one sidecar resolved from the mesh config.
Common usage
# routes the sidecar knows about
istioctl proxy-config routes my-app-7d9f-abcde.my-app
# clusters, with endpoint status
istioctl proxy-config cluster my-app-7d9f-abcde.my-app
# dump everything as json
istioctl proxy-config all my-app-7d9f-abcde.my-app -o jsonOptions
| Subcommand / flag | What it does |
|---|---|
| cluster <pod> | Show configured upstream clusters |
| listener <pod> | Show listeners (ports the proxy binds) |
| route <pod> | Show HTTP route configuration |
| endpoint <pod> | Show resolved endpoints and their health |
| secret <pod> | Show TLS certs the proxy holds (SDS) |
| -o json|yaml | Structured output for diffing in CI |
In CI
Snapshot proxy-config route -o json in a smoke test to assert a canary route weight, or diff proxy-config cluster before and after a deploy to prove endpoints changed as expected. It needs the sidecar running, so run it after the workload is ready.
Common errors in CI
"Error: pod ... does not have a sidecar" means the workload was not injected; check the namespace injection label. "unable to find pod" means the pod name or namespace is wrong (use pod.namespace form). "no endpoints" under proxy-config endpoint usually means the service has no ready backends, which is why traffic fails.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes