Use Istio traffic mirroring for quicker debugging

Use Istio traffic mirroring for quicker debugging

  • February 19, 2019
Table of Contents

Use Istio traffic mirroring for quicker debugging

Often when an error occurs, especially in production, one needs to debug the application to create a fix. Unfortunately the input that created the issue is gone. And the test data on file does not trigger the error (otherwise it would have been fixed before delivery).

Likewise if one is creating new code, one often wants to see what values a client can supply (and to be honest I have used more than once WireShark to see what is being sent). Istio’s traffic mirroring feature can help, as it allows an application to receive real traffic, which is processed by the main version. The same request is copied and then sent to the Mirror service.

The difference is though, that the reply from the mirror service is just dropped (by the Envoy proxy in the sidecar) and not returned to the caller. You do not need to modify the mirror-version—Istio does this all for you. This DestinationRule defines two subsets.

Prod is for the production traffic and the other, development for our debugging target. With that we can now use the following VirtualService to define the mirroring:

Source: itnext.io

Tags :
Share :
comments powered by Disqus

Related Posts

Istio Multicluster

Istio Multicluster

Istio Multicluster is a feature of Istio–the basis of Red Hat OpenShift Service Mesh–that allows for the extension of the service mesh across multiple Kubernetes or Red Hat OpenShift clusters. The primary goal of this feature is to enable control of services deployed across multiple clusters with a single control plane. The main requirement for Istio multicluster to work is that the pods in the mesh and the Istio control plane can talk to each other.

Read More
Sidestepping Dependency Ordering with AppSwitch

Sidestepping Dependency Ordering with AppSwitch

We are going through an interesting cycle of application decomposition and recomposition. While the microservice paradigm is driving monolithic applications to be broken into separate individual services, the service mesh approach is helping them to be connected back together into well-structured applications. As such, microservices are logically separate but not independent.

Read More