Learn Istio - Core Concepts & Main Architecture

#Introduction

In episode 1 you saw the big picture of why Istio exists. Now it is time to dissect the machine: how Istio works on the inside. Episode 2 explains the two architectural layers (control plane and data plane), the CRDs you will write every day, and the xDS protocol that is the lifeblood of configuration distribution.

Understand this structure well — almost every term that appears in the following episodes (VirtualService, DestinationRule, PeerAuthentication, and others) lives inside the framework we build now.

#Control Plane and Data Plane

#istiod: The Unified Control Plane

Since version 1.5, Istio merges the old control plane components (Pilot, Citadel, Galley) into a single binary named istiod. Its three main responsibilities:

• Pilot: translates mesh configuration into xDS rules for Envoy.
• Citadel: issues and rotates certificates for mTLS via SDS.
• Galley: validates, processes, and distributes configuration.

istiod runs as a Deployment in the istio-system namespace. You can see it together with the other components:

kubectl get deploy -n istio-system
kubectl get pods -n istio-system -l istio=sidecar-injector

The second line shows the istiod Pod along with the sidecar injector webhook, which we will cover in episode 4.

#Envoy Sidecar: The Data Plane

Every Pod that joins the mesh gets an injected istio-proxy (Envoy) container. It is Envoy that processes all inbound and outbound Pod traffic: applying routing, retries, mTLS, and recording telemetry. Because the sidecar moves together with the application, traffic rules always follow the workload rather than depending on infrastructure.

#Main Istio CRDs

#Traffic Management

• Gateway: describes the load balancer at the edge of the mesh, complete with ports, hosts, and TLS.
• VirtualService: routing rules — which host, to which subset, with what weight.
• DestinationRule: post-routing policies — subsets, connection pool, load balancing, outlier detection.
• ServiceEntry: registers external services so they become part of the mesh.

The simplest example of a VirtualService that sends all traffic to one service:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews-routing
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

#Security

• PeerAuthentication: configures the mTLS mode between workloads.
• RequestAuthentication: validates JWT tokens from requests.
• AuthorizationPolicy: allow/deny rules based on identity, namespace, or JWT claims.

#Supporting

• Sidecar: limits the egress/ingress traffic scope of a workload.
• EnvoyFilter: patches Envoy configuration directly — powerful but risky.
• WorkloadEntry: represents a non-Kubernetes workload (for example a VM) inside the mesh.

See all the CRDs installed in the cluster:

kubectl get crd | grep istio.io

#XDS: How Configuration Flows to Sidecars

#Discovery Services

Envoy does not read Istio YAML directly. Istiod translates CRDs and Kubernetes Services into rules delivered over a gRPC protocol called xDS. The four most important ones:

• CDS (Cluster Discovery Service): the list of destination clusters and their policies.
• EDS (Endpoint Discovery Service): the actual endpoint addresses for each cluster.
• LDS (Listener Discovery Service): the listeners that manage ports and connections.
• RDS (Route Discovery Service): HTTP routing rules for each listener.

#The Distribution Flow

The flow goes like this: you apply a VirtualService and a DestinationRule, istiod validates and translates them, then pushes RDS and CDS to every connected Envoy. Envoy keeps a streaming connection to istiod, so configuration changes can spread within seconds without a restart.

To inspect what a sidecar has received, use the following commands:

kubectl exec -it reviews-v1-abc123 -c istio-proxy -- curl localhost:15000/config_dump
istioctl proxy-status

istioctl proxy-status is a key tool: it shows the synchronization of every sidecar with istiod. If the status column shows SYNCED, configuration was delivered correctly; if it shows STALE, there is a connection problem or a lagging configuration version.

#Summary

Episode 2 laid out the Istio architecture framework: istiod as the control plane combining the Pilot, Citadel, and Galley functions; Envoy sidecars as the data plane; ten CRDs that form the configuration language; and the xDS protocol that streams CDS, EDS, LDS, and RDS to every proxy.

Key takeaways:

• Istiod is the single control plane binary: Pilot, Citadel, and Galley are merged inside it.
• The data plane is the collection of Envoy sidecars in every Pod.
• Gateway and VirtualService manage traffic; DestinationRule manages destination policies.
• ServiceEntry and WorkloadEntry bring external services into the mesh.
• PeerAuthentication, RequestAuthentication, and AuthorizationPolicy are the pillars of security.
• xDS (CDS, EDS, LDS, RDS) is the language istiod uses to talk to Envoy.
• istioctl proxy-status is the barometer of configuration distribution health.

In the next episode, episode 3, we will install Istio for the first time — comparing istioctl install, the Istio Operator, and Helm, choosing the right profile, and laying out a safe upgrade strategy. Make sure the cluster from episode 0 is still running.