Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

In this lesson we’ll cover what Istio is, why it matters for microservice architectures, and how its sidecar-based model (Envoy proxies) provides traffic control, security, and observability without changing application code. Istio is an open-source service mesh that helps teams run distributed, microservice-based applications in any environment. While container runtimes (Docker, containerd, CRI-O, Podman, etc.) and Kubernetes handle container lifecycle and orchestration, Istio provides a similar orchestration layer for service-to-service networking by managing the behavior of sidecar proxies. At a high level:
  • Envoy is the proxy deployed next to each application workload.
  • Istio configures and manages those Envoy sidecars across the mesh.
  • Together, they enable policy-driven traffic routing, mutual TLS (mTLS), telemetry collection, and more — all transparently to applications.

​
Architecture overview

Istio divides responsibilities into two primary planes: the data plane and the control plane.
  • Data plane: handles traffic between microservices. It is composed of Envoy sidecar proxies deployed alongside each workload; these sidecars perform routing, load balancing, mTLS encryption, authentication, telemetry capture, and other traffic-related tasks.
A diagram of a data plane in a service mesh showing Service A and Service B, each with an Envoy proxy sidecar and arrows indicating mesh traffic between them. The caption reads "The Data Plane manages and controls traffic between microservices."
  • Control plane: manages and configures the data plane. It distributes policies, issues certificates, performs service discovery, and pushes dynamic configuration to the Envoy sidecars.
Istio’s control-plane component is called istiod. Running as a pod in the cluster, istiod translates high-level traffic and policy rules into Envoy-specific configuration, distributes those updates to sidecars at runtime, and acts as a certificate authority to provision keys and certificates for mTLS between workloads.
Historically, Istio’s control plane consisted of multiple components (Pilot, Citadel, Galley). Modern Istio consolidates those responsibilities into istiod, which simplifies management and reduces operational overhead.
A diagram of a Kubernetes security architecture with Istio: a Control Plane and certificate authority at the top and three nodes (payments, app, identity namespaces) below. Each node shows services with Envoy sidecars and icons depicting secure/mTLS service-to-service connections.

​
Quick comparison: Data Plane vs Control Plane

PlaneRoleTypical components
Data planeHandles service-to-service trafficEnvoy sidecar proxies (per workload)
Control planeManages configuration, policies, and identityistiod (service discovery, config translation, CA)

​
Key capabilities and why teams use Istio

Istio centralizes a set of cross-cutting concerns so developers can focus on business logic while sidecars enforce networking, security, and telemetry. Core capabilities include:
  • Traffic management: fine-grained routing, traffic splitting, canary releases, A/B testing, request mirroring, and fault injection — all without modifying application code.
  • Security: automatic mTLS between workloads, certificate issuance and rotation, and identity-based authentication.
  • Authentication & authorization: enforce access control policies to restrict which identities can call specific services.
  • Observability: centralized telemetry, tracing, and metrics collection via integrations with tools like Jaeger and Datadog APM.
  • Resilience & reliability: retries, timeouts, circuit breaking, and rate limiting to mitigate cascading failures.
  • Reduced operational overhead: centralizes security and networking policies so applications remain lightweight and unchanged.
A presentation slide titled "Why Use Istio?" showing three colored panels: Traffic Management, Security, and Policies, each with an icon and a short explanatory line. The panels note routing customization, automatic mTLS encryption between workloads, and enforcing access control for service traffic.
Because Istio uses a transparent sidecar proxy model, applications do not need code changes to benefit from these features — Envoy intercepts and manages network traffic for the app.
A presentation slide titled "Why Use Istio?" showing three boxed benefits—Observability, Resilience and Reliability, and Reduced Operation Overhead—each with an icon and a short explanatory caption.

​
Example: simple traffic split with a VirtualService

Below is a minimal Istio VirtualService example that directs 90% of traffic to version v1 and 10% to v2 — a common canary deployment pattern. 
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp-routing
spec:
  hosts:
    - myapp.default.svc.cluster.local
  http:
    - route:
        - destination:
            host: myapp
            subset: v1
          weight: 90
        - destination:
            host: myapp
            subset: v2
          weight: 10
This routing is enforced by Envoy sidecars based on configuration delivered by istiod, with no changes required in application containers.

​
When to adopt Istio

Consider Istio when you need:
  • Centralized traffic control and advanced release strategies (canaries, A/B testing).
  • Strong, automated service-to-service security (mTLS, certificate management).
  • Consistent telemetry and tracing across many microservices.
  • Platform-level resilience features without replicating logic in each service.
Istio introduces operational complexity of its own, so evaluate whether the benefits outweigh the additional control-plane components and learning curve for your team.

​
Summary

Istio is a policy-driven service mesh that manages Envoy sidecars to provide traffic management, security (mTLS), observability, and resilience for microservice environments. Its control plane (istiod) orchestrates sidecar behavior, while Envoy sidecars in the data plane enforce policies transparently to applications. Further reading and resources:

Watch Video