Skip to main content
Now that we know what a sidecar is, let’s define Istio and how it helps run microservice-based applications. Istio is an open-source service mesh that helps organizations run distributed, microservice-based applications anywhere.
The image displays the Istio logo and describes it as an open-source service mesh for running microservices apps across any environment.
What does that mean in practice? There are many container runtimes—Docker, containerd, rkt, Podman, CRI-O, LXC, Mirantis, and others. Managing these runtimes across many services and environments can be complex and time-consuming.
The image shows logos of different container runtimes, including Docker, containerd, Rocket, Podman, and cri-o, along with a caption stating, "Managing containers can be difficult and time-consuming."
Kubernetes solves much of the container orchestration problem by managing lifecycle operations (create, restart, destroy) across runtimes. In a similar way, Istio is to the Envoy proxy what Kubernetes is to containers: an orchestrator that manages deployed Envoy sidecars.
The image shows logos of Istio and Envoy, with a note stating that an orchestrator facilitates the management of Envoy Proxies.
Architecture overview An Istio service mesh consists of two primary layers: the data plane and the control plane. Understanding the responsibilities of each is key to designing and operating an Istio mesh. Data plane
  • The data plane handles actual traffic between microservices.
  • It deploys sidecar proxies (typically Envoy) next to each workload.
  • Responsibilities include routing, load balancing, TLS encryption using mTLS, telemetry collection, and service-level authentication.
The image illustrates a data plane setup where "Service A" and "Service B" communicate over mesh traffic using Envoy proxies.
Control plane
  • The control plane manages and configures the data plane.
  • It distributes policies and certificates, performs service discovery, and enforces authentication and authorization.
  • It dynamically converts high-level routing and policy definitions into Envoy-specific configuration and pushes those configs to sidecars.
The image is a diagram showing how Istio's control plane manages and configures the data plane through network policies, certificate authority, authentication, and authorization.
istiod: the core control-plane component The primary control-plane component in modern Istio is istiod. When Istio is installed into a Kubernetes cluster, istiod runs as a pod (or a set of pods) and provides several critical services:
  • Service discovery and config distribution: translates mesh-level routing and policy into Envoy-specific configuration and pushes changes to sidecars at runtime.
  • Certificate Authority: issues and rotates certificates used for mTLS so workloads can securely authenticate one another.
  • Authentication and authorization enforcement: supports service-to-service and end-user identity, enabling fine-grained access control.
The image is a diagram showing the architecture of an Istio service mesh within a Kubernetes environment, illustrating the control plane and the distribution of Envoy proxies across multiple nodes.
Istiod functions as a certificate authority and supports workload identity and credential management. This allows you to enforce strict access controls so services accept traffic only from authorized callers.
The image illustrates a Kubernetes architecture with Istio for security, showcasing three nodes with different namespaces and services interconnected through Envoy proxies. It highlights the control plane, certificate authority, and secure communication between services.
At-a-glance comparison Why use Istio?
  • Traffic management: Define advanced routing rules such as traffic splitting, canary releases, mirroring, and weighted routing—far beyond a simple load balancer.
  • Security: Automatically encrypt traffic between workloads using mTLS and manage certificates, removing the need for custom TLS implementations.
  • Authentication and authorization: Enforce access control policies so services only accept traffic from authorized sources.
The image outlines three benefits of using Istio: Traffic Management, Security, and Policies. Each benefit is briefly described, emphasizing customizable routing, automatic encryption, and access control.
Other key benefits
  • Observability: Centralized telemetry (logs, metrics, traces) simplifies aggregation and analysis with tools such as Jaeger, Prometheus, or Datadog APM.
  • Resilience and reliability: Built-in patterns like circuit breaking, retries, timeouts, and fault injection help reduce cascading failures and improve availability.
  • Reduced operational overhead: Shifts networking, security, and observability concerns out of application code and into the mesh so developers can focus on business logic. The sidecar approach is transparent to applications—workloads generally do not need modification to take advantage of the mesh.
The image presents three reasons to use Istio: Observability, Resilience and Reliability, and Reduced Operation Overhead, each highlighted with a brief description.
Istio’s sidecar model is transparent to application code: you typically inject Envoy proxies beside your workloads (automatically or manually) and let Istio manage networking, security, and telemetry without modifying your application binaries.
While Istio reduces application complexity, it introduces operational components (control plane, certificate lifecycle, sidecar management) that must be monitored and maintained. Plan for observability and backup strategies for the control plane.
Feature summary Further reading and references That wraps up this introductory section. In the next lesson we’ll summarize and start configuring a simple Istio-enabled workload.

Watch Video