Introduction to service mesh – Implementing Traffic Management, Security, and Observability with Istio-2

In the context of extensive applications, it’s not uncommon to see hundreds of microservices interacting with each other, which can quickly become overwhelming. The primary concerns that may be raised by your security and operations teams are as follows:

• Ensuring secure communication between microservices. You need to secure numerous smaller services rather than securing a single monolithic application.

• Isolating a problematic microservice in case of an issue.

• Testing deployments with a limited percentage of traffic before a full release to establish trust.

• Consolidating application logs that are now distributed across multiple sources.

• Monitoring the health of the services becomes more intricate, with many components constituting the application.

While Kubernetes effectively addresses some management issues, it primarily serves as a container orchestration platform and excels in that role. However, it doesn’t inherently solve all the complexities of a microservices architecture as they require specific solutions. Kubernetes does not inherently provide robust service management capabilities.

By default, communication between Kubernetes containers lacks security measures, and enforcing TLS between pods involves managing an extensive number of TLS certificates. Identity and access management between pods is also not applied out of the box.

While tools such as Kubernetes Network Policy can be employed to implement a firewall between pods, they function at a Layer 3 level rather than Layer 7, which is what modern firewalls operate at. This means you can identify the source of traffic but cannot inspect the data packets to make metadata-driven decisions, such as routing based on an HTTP header.

Although Kubernetes offers methods for deploying pods and conducting A/B testing and canary deployments, these processes often involve scaling container replicas. For example, deploying a new microservice version with just 10% of traffic directed to it requires at least 10 containers: 9 for the old version and 1 for the new version. Kubernetes distributes traffic evenly among pods without intelligent traffic splitting.

Each Kubernetes container within a pod maintains separate logging, necessitating a custom solution for capturing and consolidating logs.

While the Kubernetes dashboard provides features such as monitoring pods and checking their health, it does not offer insights into how components interact, the traffic distribution among pods, or the container chains that constitute the application. The inability to trace traffic flow through Kubernetes pods means you cannot pinpoint where in the chain a request encountered a failure.

To address these challenges comprehensively, a service mesh technology such as Istio can be of extreme help. This can effectively tackle the intricacies of managing microservices in Kubernetes and offer solutions for secure communication, intelligent traffic management, monitoring, and more. Let’s understand what the Istio service mesh is through a brief introduction.