In this lesson, you will learn how to use CLI diagnostic tools to inspect proxy configurations and resolve common connectivity issues within your service mesh.
When a request fails within a service mesh, the issue usually hides inside the "black box" of the sidecar proxy. Because the traffic is intercepted by the sidecar, you cannot rely on standard kubectl logs of your application alone; you must peek into the Envoy proxy's internal state to see how it is routing, authorizing, or failing your traffic.
Inspecting Proxy Configurations
The primary tool in your arsenal is the mesh-specific CLI (e.g., istioctl). To troubleshoot a connectivity issue, you first need to identify if the proxy has received the latest configuration from the control plane. You can use the proxy-config command to dump the configuration for a specific pod:
# Check the status of the proxy configuration sync
istioctl proxy-status <pod-name>.<namespace>
# Dump the current route configuration to check routing logic
istioctl proxy-config routes <pod-name>.<namespace> --name 8080 -o json
If the proxy-status shows "STALE," the sidecar has not synced with the control plane, explaining why your new VirtualService or routing rule isn't taking effect.
Analyzing Connectivity Failures
When traffic is denied or drops unexpectedly, the sidecar logs are your source of truth. However, raw logs are often noisy. Use the istioctl analyze command to perform a health check of your namespace configuration:
istioctl analyze -n my-app-namespace
This command evaluates your VirtualService, DestinationRule, and PeerAuthentication policies for conflicts. If you suspect an mTLS issue, check the Envoy proxy logs directly for 503 or 403 errors:
kubectl logs <pod-name> -c istio-proxy | grep "403"
If you see RBAC: access denied, your authorization policy is likely too restrictive. If you see upstream connect error, the issue is often a mismatch in your DestinationRule settings, such as forcing TLS when the backend service is not configured to receive it. By systematically verifying the config sync status and checking the proxy logs, you can pinpoint whether the error lies in your traffic policies or the service-to-service handshake.
Key Takeaway: Use istioctl proxy-config to verify the state of your routes and istioctl analyze to detect policy conflicts, ensuring your sidecar proxy has the correct instructions to route traffic securely.