Debugging Envoy sidecar C++ code running in Istio mesh. It helps deep dive into the sidecar at code level. It makes us more confident when troubleshooting Istio problem or writing better EnvoyFilter or eBPF trace program. This article guides how to use VSCode and lldb to debug Envoy istio-proxy sidecar.

To achieve fast recovery of Istio mesh node failures, it is necessary to have a deep understanding of the processing flow of its requests. This article illustrates the Istio & Envoy request processing flow, timeout, circuit breaker, and metrics monitoring

The normal HTTP request was responded with HTTP status code 400 after migrating to Istio. The problem traffic has HTTP headers that do not comply with the HTTP 1.1 specification. So I try to develop an Envoy WASM Network Filter to fix the illegal HTTP Header.

BPF Tracing Upstream/Downstream Event-Driven Collaboration of Envoy@Istio

Starvating threads and SO_REUSEPORT socket

Why tuning If it takes interest and momentum to push a new technology, then what is needed to get this technology go to live production is hard working. Including Cloud Native and Istio. In pre-launch performance testing, Istio out-of-box provided observability, operational convenience, and also introduced pain: Increased service latency. How to minimize latency has become a critical task. My Scenario: SERVICE-A invoke SERVICE-B Latency of Service-A, which was previously 9ms at P50, is now 14ms at P50.