Traffic mirroring – Implementing Traffic Management, Security, and Observability with Istio-2

Following the completion of the Argo CD synchronization process, we’ll proceed to refresh the page five times. Subsequently, we can inspect the logs of the ratings:v1 service using the following command:
$ kubectl logs $(kubectl get pod -n blog-app | \
grep “ratings-” | awk ‘{print $1}’) -n blog-app
127.0.0.6 – – [22/Oct/2023 08:33:19] “GET /review/6534cba72485f5a51cbdcef0/rating HTTP/1.1” 200 –
127.0.0.6 – – [22/Oct/2023 08:33:19] “GET /review/6534cbb32485f5a51cbdcef1/rating HTTP/1.1” 200 –
127.0.0.6 – – [22/Oct/2023 08:33:23] “GET /review/6534cba72485f5a51cbdcef0/rating HTTP/1.1” 200 –
127.0.0.6 – – [22/Oct/2023 08:33:23] “GET /review/6534cbb32485f5a51cbdcef1/rating HTTP/1.1” 200 –
127.0.0.6 – – [22/Oct/2023 08:33:25] “GET /review/6534cba72485f5a51cbdcef0/rating HTTP/1.1” 200 –

With traffic mirroring active, it’s expected that the same set of logs observed in theratings:v1 service will also be mirrored in the ratings:v2 service. To confirm this, we can list the logs for the ratings:v2 service using the following command:
$ kubectl logs $(kubectl get pod -n blog-app | \
grep “ratings-v2” | awk ‘{print $1}’) -n blog-app
127.0.0.6 – – [22/Oct/2023 08:33:19] “GET /review/6534cba72485f5a51cbdcef0/rating HTTP/1.1” 200 –
127.0.0.6 – – [22/Oct/2023 08:33:19] “GET /review/6534cbb32485f5a51cbdcef1/rating HTTP/1.1” 200 –
127.0.0.6 – – [22/Oct/2023 08:33:23] “GET /review/6534cba72485f5a51cbdcef0/rating HTTP/1.1” 200 –
127.0.0.6 – – [22/Oct/2023 08:33:23] “GET /review/6534cbb32485f5a51cbdcef1/rating HTTP/1.1” 200 –
127.0.0.6 – – [22/Oct/2023 08:33:25] “GET /review/6534cba72485f5a51cbdcef0/rating HTTP/1.1” 200 –

Indeed, the logs and timestamps match precisely, providing clear evidence of concurrent log entries in ratings:v1 and ratings:v2. This observation effectively demonstrates the mirroring functionality in operation, showcasing how traffic is duplicated for real-time monitoring and analysis in both versions.

Traffic mirroringis a highly effective method for identifying issues that often elude detection within traditional infrastructure setups. It is a potent approach for conducting operational acceptance testing of your software releases. This practice simplifies testing and safeguards against potential customer incidents and operational challenges.

There are other aspects of traffic managementthat Istio provides, but covering all of them is beyond the scope of this chapter. Please feel free to explore other aspects of it by visiting the Istio documentation: https://istio.io/latest/docs/tasks/traffic-management/.

As we already know, Istio leverages envoy proxies as sidecar components alongside your microservice containers. Given that these proxies play a central role in directing and managing the traffic within your service mesh, they also collect valuable telemetry data.

This telemetry data is subsequently transmitted toPrometheus, a monitoring and alerting tool, where it can be stored and effectively visualized. Tools such as Grafana are often employed in conjunction with Prometheus to provide insightful and accessible visualizations of this telemetry data, empowering you to monitor and manage your service mesh effectively. Therefore, we’ll go ahead and explore the observability portion of Istio in the next section.