Project 3 Part 1

Project 3 - Part 1

Problem Statement

Currently, our weather application lacks a service mesh layer on top of the Kubernetes architecture. We plan on integrating a service mesh into our current system architecture that is deployed on Google Cloud Platform using Istio and add features such as service authorization, security, canary deployment, and improved metrics observability.

Proposed solution

We would like to implement the following service mesh features:

1. Service Authorization - We use a service mesh to define the communication restrictions between services.
2. Security - Use a service mesh to implement secure communication between services such as mTLS.
3. Canary deployment - Currently, the system is using a rollout deployment. We would like to implement a service mesh to do canary deployment of the services in our system.
4. Metrics - Implement a service mesh to collect and provide various system/network metrics.

We want to implement the above features using Istio into our weather application microservices architecture built and deployed on Google Cloud Platform.

Implementation plan

Istio with Envoy Proxy

Istio works by having a small network proxy sit alongside each microservice. This so-called “sidecar” intercepts all of the service’s traffic and handles it more intelligently. Istio uses the Envoy proxy as its sidecar. The whole set of sidecars, one per microservice, is called the data plane. The work of the sidecars is coordinated by a small number of central components called the control plane.

Phase 1 (Data Plane)

The first phase primarily focuses on the integration and configuration of Envoy sidecars for each pod and microservice. This would include installing the Envoy sidecar manually, routing the system traffic to the sidecar proxy manually, and managing the configurations for all the sidecars.

Therefore, the changes needed in Phase 1 would be in:-

• Pod - The Pod spec in our current architecture has only one container defined inside it but can hold one or more containers. Since we want to run a sidecar proxy with each of our service instances, we will add the Envoy container to every pod.

• Service - Kubernetes services take care of maintaining the list of Pod endpoints it can route traffic to. But since we’re sending the traffic to Envoy first, we need to map the Kubernetes service port to the Envoy listeners port rather than the app’s service port.

Phase 2 (Control Plane)

The second phase comprises introducing the Istio Mesh to take care of the sidecar configurations thus allowing a lighter Envoy proxy for each service. The aim is to use the Istio Control Plane and inject sidecars into every pod that gets deployed into the default namespace. With the services deployed, each pod now should have two containers (the service and the sidecar).

Phase 3 (Monitoring and Testing)

The last phase would be to test the system with Istio tools like Kiali and Grafana that help monitor what is going on in the service mesh once a load testing tool generates some traffic.

Kiali (Observability) — Would provide a detailed view of Istio component configurations, insight on service failures, visualizations according to the information collected by intercepting network requests.

Grafana (Metrics Visualization) —The metrics collected by Istio are scraped into Prometheus and Visualized using Grafana. Istio Mesh Dashboards include metric visualizations like request volume, success rate, request durations etc.