Istio overview in Kubernetes - Step-by-Step Execution

Process Flow - Istio overview

Deploy Application Pods

↓

Inject Istio Sidecar Proxy

↓

Traffic enters Service Mesh

↓

Envoy Proxy intercepts requests

↓

Apply Istio Policies & Telemetry

↓

Route traffic based on rules

↓

Secure communication with mTLS

↓

Collect metrics and logs

↓

End

Istio works by injecting a proxy alongside app pods to intercept and manage traffic, applying policies, routing, security, and telemetry.

Execution Sample

Kubernetes

kubectl apply -f istio-demo.yaml
kubectl get pods
kubectl describe pod <pod-name>
istioctl proxy-status
kubectl logs <pod-name> -c istio-proxy

These commands deploy Istio demo app, check pods, inspect sidecar proxy status, and view proxy logs.

Process Table

Step	Action	Result	System State Change
1	Apply Istio demo app YAML	Pods created with Istio sidecar injected	Application pods and Envoy proxies running
2	Get pods	List shows app pods and istio-proxy containers	Verify sidecar injection success
3	Describe pod	Details show two containers: app + istio-proxy	Confirms sidecar presence
4	Check proxy status	Shows Envoy proxies connected and synced	Mesh control plane communicating with proxies
5	View proxy logs	Logs show intercepted traffic and policy enforcement	Traffic managed by Istio sidecar
6	End	All components running and communicating	Service mesh operational

💡 All pods have sidecar proxies injected and are communicating with Istio control plane

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
Pods	None	App pods created	Pods listed with sidecar	Pods described with 2 containers	Proxy status synced	Proxy logs active	Pods and proxies running
Istio Sidecar	Not injected	Injected in pods	Confirmed in pod list	Confirmed in pod details	Connected to control plane	Intercepting traffic	Active and managing traffic

Key Moments - 3 Insights

Why do pods have two containers after Istio injection?

Because Istio injects a sidecar proxy container alongside the app container to manage traffic, as shown in execution_table step 3.

How do we know the sidecar proxies are communicating with the control plane?

The 'istioctl proxy-status' command in step 4 shows proxies connected and synced, confirming communication.

What role do the proxy logs play in understanding Istio's function?

Proxy logs show intercepted traffic and policy enforcement, proving the sidecar is actively managing traffic (step 5).

Visual Quiz - 3 Questions

Look at the execution table, what is confirmed at step 3?

A Pods have only one container

B Istio control plane is down

C Pods have two containers: app and istio-proxy

D No pods are running

💡 Hint

Check the 'Result' column at step 3 in the execution_table

At which step do we verify that Envoy proxies are connected and synced?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Look for 'proxy status' in the 'Action' column in execution_table

If the sidecar proxy was not injected, what would change in the variable_tracker?

A Pods would show two containers

B Istio Sidecar would remain 'Not injected'

C Proxy logs would be active

D Proxy status would be synced

💡 Hint

Refer to the 'Istio Sidecar' row in variable_tracker across steps

Concept Snapshot

Istio overview:
- Injects Envoy sidecar proxy into app pods
- Proxies intercept and manage all traffic
- Applies routing, security (mTLS), and telemetry
- Control plane communicates with proxies
- Use kubectl and istioctl to inspect mesh state

Full Transcript

Istio is a service mesh that works by injecting a sidecar proxy called Envoy into application pods. This proxy intercepts all network traffic to and from the app, allowing Istio to apply routing rules, enforce security like mutual TLS, and collect telemetry data. The control plane manages these proxies and communicates with them to keep the mesh running smoothly. We deploy Istio-enabled apps using kubectl, then verify pods have two containers: the app and the sidecar proxy. Using istioctl, we check proxy status to confirm connectivity. Proxy logs show traffic interception and policy enforcement. This visual execution shows how Istio components start, connect, and manage traffic step-by-step.