Discovering Istio

An Introduction!

Sanjit Mohanty
FAUN — Developer Community 🐾

--

Pic courtesy — https://blog.container-solutions.com/solving-2-common-deployment-dilemmas-in-istio

Prologue

In the previous article we learnt the concepts behind Service Mesh & what problem it is addressing through a real life example.

If you missed reading it, I would highly recommend you to do so before proceeding any further. Link to the article -

https://medium.com/faun/untangling-service-mesh-40cd12c337d5

While there are many implementations of Service Mesh, the most prominent & widely used is Istio.

Meet Istio

The Istio project was started by teams from Google & IBM in partnership with the Envoy from Lyft in 2017. It was created to address the challenges that arise when managing micro-services based applications at scale.

Microservices architectures, which break down applications into small, independent services, can result in increased complexity and require more sophisticated tools to manage them.

Since its release, Istio has gained popularity among developers and has been adopted by many organisations to manage their micro services based applications. It has become a de facto standard for service mesh platforms and has a vibrant community of contributors and users.

Architecture

Istio typically consists of —

  • A Control Plane and
  • Data Plane

Istio Control Plane

The control plane is a crucial component of the Istio service mesh that plays a vital role in managing & orchestrating the overall behaviour of the mesh.

It is responsible for configuring & coordinating the various components that make up the service mesh, such as the data plane, which consists of the Envoy sidecar proxies running alongside the micro-services. The control plane helps to simplify the management of micro-services by providing a centralised configuration & management system.

Istio Control Plane

Istio control plane’s primary components are —

  1. Istiod: Istiod is the unified control plane component. Prior to Istio version 1.5, the Istio control plane comprised of many sub-components such as Pilot, Galley, Citadel , Side Car Injector). All these capabilities were integrated into one single component i.e inside Istiod from 1.5
Istiod unified (Pilot, Galley, Citadel & Sidecar Injector) into a single component
  • Configuration management (Done by “Galley” prio to Istio version 1.5): It deals with the configuration validation, ingestion, processing, and distribution. It ensured the validity and consistency of Istio configuration, fetched the configuration from Kubernetes’ API server, and delivered it to other control plane components.
  • Policy enforcement & Traffic routing (Done by “Pilot” & “Sidecar Injector” prio to Istio version 1.5): It deals with automatically injecting Envoy sidecar proxies into the pods of services that were part of the Istio service mesh. This made it easier to onboard new services into the mesh without manual intervention. Once sidecar envoy proxy injection done, it translates high-level routing rules into Envoy-specific configurations and distributed them to the sidecar proxies.
  • Security (Done by “Citadel” prio to Istio version 1.5): It deals with managing the security aspects of the service mesh, such as issuing and rotating certificates for mTLS (mutual Transport Layer Security) and managing access control policies for microservices. It provided secure communication channels and authentication between services.
Istio egress & ingress gateways

2. Ingress Gateway: The Ingress Gateway is responsible for managing the traffic entering the Istio service mesh from external sources. It serves as an entry point that routes incoming traffic to the appropriate services within the mesh, based on predefined routing rules. The key roles of the Ingress Gateway include —

  • Traffic routing: The Ingress Gateway routes incoming traffic to the appropriate services in the mesh, based on the routing rules defined in the Istio control plane.
  • Load balancing: It evenly distributes incoming traffic across the available instances of a service, ensuring optimal resource utilization and improved performance.
  • Security: The Ingress Gateway can enforce security policies, such as TLS termination and client certificate validation, ensuring secure communication between external clients and services within the mesh.
  • Observability: It generates telemetry data, such as logs, metrics, and traces, which can be exported to external monitoring and observability tools for analysis and troubleshooting.
  • Policy enforcement such as TLS termination & client certificate validations.

3. Egress Gateway: The Egress Gateway manages the traffic leaving the Istio service mesh and destined for external services or systems. It serves as an exit point that routes outgoing traffic from services within the mesh to external endpoints. The key roles of the Egress Gateway include —

  • Traffic routing: The Egress Gateway routes outgoing traffic from the service mesh to the appropriate external services or systems, based on the routing rules defined in the Istio control plane.
  • Security: It enforces security policies for traffic leaving the mesh, such as TLS origination and external service authentication, ensuring secure communication between services in the mesh and external systems.
  • Observability: Like the Ingress Gateway, the Egress Gateway generates telemetry data that can be exported to external monitoring and observability tools for analysis and troubleshooting.
  • Policy enforcement: The Egress Gateway can enforce policies for outgoing traffic, such as rate limiting, access control, and request quotas, ensuring consistent behavior and compliance with organizational policies.

Istio Data Plane

The Istio data plane is a crucial part of the Istio service mesh architecture, responsible for the actual handling of network traffic between micro-services.

Istio data plane

It is primarily composed of Envoy sidecar proxies, which are deployed alongside each service instance within the mesh. We already learnt that these sidecar proxies are injected by istiod. These proxies intercept and manage all incoming and outgoing traffic for the service, while the Istio control plane configures and controls their behaviour.

Epilogue

In the first installment we learnt basics of Service Mesh and in this installment we got introduced to Istio. We will continue our journey with Istio in subsequent blogs & will deep dive into it’s nitty gritty.

Until then, happy learning!

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

--

--

Engineering Manager, Broadcom | Views expressed on my blogs are solely mine; not that of present/past employers. Support my work https://ko-fi.com/sanjitmohanty