Most organizations prefer to deploy containerized applications into K8s because of its scalability and flexibility. But as the number of microservices increases and application pods are distributed across multiple clusters and cloud providers, managing and scaling them becomes complex.
While scaling, it is harder to configure complex communication logic between microservices. Also, there are additional concerns like securing and observing these connections. Without a proper management system for communication, service downtime and security breaches among distributed services become common.
Service mesh was introduced to address these challenges and complexity while scaling microservices in K8s. It provides a platform for network traffic management and handles service-to-service communication at an infrastructure level. Istio is one of the most popular service mesh platforms, and we will explore Istio in this article.
Challenges of microservices in cloud and Kubernetes environment
We have outlined a few pressing challenges faced by teams such as developers, security teams, SREs, and platform Engineers. Below are a few of them and the respective teams facing the challenge.
Developers toil to create security policies to their application
Organizations and different government bodies have set security policies and standards for application development, such as HIPAA and PII. It helps to ensure the security of data and applications in a dynamic threat landscape. A Web-based firewall (WAF) is not enough to secure data-in-transit. Developers have to write authentication and authorization policies in their business logic (or service) to avoid breach of data during the communication between other services.
It is particularly a headache for developers because of repeating effort. And wherever there is a new organizational policy for compliance, developers have to toil and ensure security changes are done for their system.
No central point to secure multicloud and multicluster applications
Other reasons such as diversity of technology and container versions makes the security local to the applications. It is a pain to enforce consistent security policies for applications across multiple clusters, cloud providers, and with various third-party services and APIs. While developers develop the security policies for their applications or services, the responsibility of securing traffic for multiple infrastructure remains a question.
Traffic management of microservice is a pain for cloud team
DevOps engineers, Cloud engineers or Infra engineers configure the communication logic of an application in the service manifest itself. Every time new services are deployed or any changes happen to existing services, the networking logic has to be changed. For example, if a new service has been deployed, the endpoint to the new service has to be manually added on all the other services that communicate with it. All the traffic management is a time-consuming process.
Struggle to monitor application performance (SREs)
It is essential to have real-time visibility into the health and performance of network infrastructure. It helps SREs to identify and respond to any issues or security threats emerging in the real-time traffic, and ensure the availability of services at all times.
Most of the microservices are distributed across cloud or Kubernetes clusters. Without a single plane of visibility of traffic- north-south and east-west- and the granular performance and behavioral details, it is challenging for SREs to troubleshoot and resolve issues quickly. This often leads to SLA breaches and service unavailability.
Istio solves all the above problems by abstracting the network and security logic from the application layer to its own infrastructure layer. This is done by injecting a sidecar (Envoy proxy) on pods, which in turn helps in managing complex, distributed networks at scale. Let us now discuss Istio and its components and how it can help in simplifying network challenges for developers, cloud engineers and SREs.
What is Istio?
Istio is an open-source service mesh platform that simplifies and secures traffic between microservices. Istio provides a dedicated infrastructure for traffic management, security, and observability, to help developers handle the network of microservices in Kubernetes and multiple clouds, at scale.
Istio works by deploying Envoy proxy- a L4 and L7 layer proxy- alongside each microservice. The proxy intercepts and handles service-to-service traffic, and thus abstracts communication logic from the service/application layer into a dedicated infrastructure layer (refer to fig. A).
Fig. A – Service-to-service communication before and after deploying Istio service mesh in a Kubernetes cluster
Istio components and sidecar architecture
Istio has two main components that control and manage the entire network infrastructure layer (refer to fig. B):
- Data plane: It is a network of Envoy proxies that handle the communication between services in the mesh. Envoy is a lightweight proxy deployed as a sidecar alongside each service in a mesh, which then intercepts the traffic between that particular service and other services. Using Envoy proxy, data plane route and control the request flow between services, and offers traffic routing, load balancing, methods to test the resilience of the system (retries, timeouts, circuit breakers, fault injection), and metrics for better visibility and observability.
- Control plane: In Istio, the control plane interacts with the data plane and provides a centralized management and configuration layer for data plane proxies. That is, the control plane converts high-level routing rules that define traffic control behavior into Envoy-specific configurations. Earlier control plane components were divided into Pilot, Galley, Citadel, and Mixer. Now, control plane functionalities are consolidated into a single binary called istiod. Istiod handles service discovery, configuration, and certificate management for service communication in the mesh.
Fig. B – Istio sidecar architecture
Although injecting Envoy proxies as sidecars is the go-to method to implement Istio, there are certain limitations to this approach. The primary limitation is that the operational cost of deploying and maintaining a sidecar is fixed, regardless of the complexity of the use cases. That is, even if the use case is to achieve simple transport security or to configure complex L7 policies, they both require deploying and maintaining sidecars.
And there are other operational challenges. For example, upgrading a sidecar could be disruptive for workloads since it requires restarting the service pod. It cannot be done without a pod restart because Kubernetes pod spec has to be modified to inject the updated sidecar container. Istio recently introduced an early version of the ambient mesh, which solves some of the challenges with sidecar injection.
Istio ambient mesh
Istio ambient mesh is a modified and sidecar-less data plane for Istio. Ambient mesh takes a layered approach and splits the functionality of Istio into two: the secure overlay layer and the L7 processing layer. Secure overlay layer suits enterprises with comparatively minimal use cases such as routing, zero trust with mTLS, and L4 processing. The L7 processing layer helps organizations take advantage of the secure overlay, along with accessing advanced L7 processing and the full range of Istio capabilities. This layered approach is useful for enterprises to adopt Istio incrementally.
Also, since ambient mesh uses a shared agent (ztunnel) running on each node in the cluster, it provides complete separation from the application service, unlike in sidecars. To know more about the Istio ambient mesh architecture and features, you can read What is Istio ambient mesh?