Network quality issues such as packet loss can be discovered, quantified, and monitored using Envoy sidecar. During testing, Envoy can be used as an egress on the client side such as JMeter to monitor traffic. This article discusses one of the implementation solutions.
Like all proxy software, Envoy takes flow control seriously because CPU/memory resources are limited. But flow control is never a simple matter. It involves all the players in the data flow path. This article tries to explain the principles and synergies involved.
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.
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.