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.

Practice

1. What is the primary purpose of Istio in a Kubernetes environment?

easy

A. To manage Kubernetes cluster nodes

B. To secure, observe, and control application traffic

C. To deploy applications automatically

D. To store container images

Solution

1. Step 1: Understand Istio's role

   Istio is designed to manage how microservices communicate within Kubernetes by securing, observing, and controlling traffic.

2. Step 2: Compare with other options

   Managing nodes, deploying apps, and storing images are handled by other Kubernetes components, not Istio.

3. Final Answer:

   To secure, observe, and control application traffic -> Option B

4. Quick Check:

   Istio = traffic control and security [OK]

Hint: Istio manages app traffic, not nodes or images [OK]

Common Mistakes:

• Confusing Istio with Kubernetes node management
• Thinking Istio deploys apps automatically
• Assuming Istio stores container images

2. Which command correctly labels a Kubernetes namespace for automatic Istio sidecar injection?

easy

A. kubectl set namespace my-namespace istio-injection=enabled

B. kubectl annotate namespace my-namespace istio-injection=enabled

C. kubectl apply namespace my-namespace istio-injection=enabled

D. kubectl label namespace my-namespace istio-injection=enabled

Solution

1. Step 1: Identify the correct command for labeling

   The command to add a label to a namespace is 'kubectl label namespace'.

2. Step 2: Verify the label key and value

   The label key for Istio sidecar injection is 'istio-injection' and the value is 'enabled'.

3. Final Answer:

   kubectl label namespace my-namespace istio-injection=enabled -> Option D

4. Quick Check:

   Label namespace with 'istio-injection=enabled' using kubectl label [OK]

Hint: Use 'kubectl label namespace' to add labels [OK]

Common Mistakes:

• Using 'annotate' instead of 'label' for sidecar injection
• Trying 'set' or 'apply' commands incorrectly
• Missing the correct label key or value

3. After labeling the namespace for Istio sidecar injection and deploying a pod, what is the expected change in the pod's containers?

medium

A. The pod will have an additional Istio sidecar proxy container

B. The pod will have fewer containers than before

C. The pod will restart automatically without changes

D. The pod will be deleted and recreated without sidecars

Solution

1. Step 1: Understand sidecar injection effect

   Labeling the namespace enables automatic injection of the Istio sidecar proxy container into new pods.

2. Step 2: Observe pod container count

   The pod will have its original containers plus one additional sidecar container for Istio.

3. Final Answer:

   The pod will have an additional Istio sidecar proxy container -> Option A

4. Quick Check:

   Sidecar injection adds a container to pods [OK]

Hint: Sidecar injection adds one container per pod [OK]

Common Mistakes:

• Expecting fewer containers after injection
• Thinking pods restart without container changes
• Assuming pods get deleted instead of modified

4. You labeled the namespace for Istio sidecar injection but new pods do not have the sidecar container. What is the most likely cause?

medium

A. All of the above

B. Istio components are not installed in the cluster

C. Pods were created before labeling and not restarted

D. Namespace was not labeled correctly or label was misspelled

Solution

1. Step 1: Check namespace labeling

   If the label is missing or misspelled, sidecar injection won't trigger.

2. Step 2: Verify Istio installation and pod creation timing

   Istio must be installed; pods created before labeling need restart to get sidecars.

3. Step 3: Combine all causes

   Any of these issues can cause missing sidecars, so all are possible reasons.

4. Final Answer:

   All of the above -> Option A

5. Quick Check:

   Label, install, and pod timing all affect sidecar injection [OK]

Hint: Check label, Istio install, and pod restart [OK]

Common Mistakes:

• Ignoring pod restart after labeling
• Assuming labeling alone is enough
• Not verifying Istio installation

5. You want to secure communication between microservices using Istio. Which Istio feature should you enable to encrypt traffic automatically?

hard

A. Istio Gateway for external traffic routing

B. Sidecar injection for logging only

C. Mutual TLS (mTLS) for service-to-service encryption

D. Prometheus integration for monitoring

Solution

1. Step 1: Identify Istio features for security

   Mutual TLS (mTLS) encrypts traffic between services automatically within the mesh.

2. Step 2: Differentiate other features

   Sidecar injection adds proxies but does not alone encrypt traffic; Gateways route external traffic; Prometheus is for monitoring.

3. Final Answer:

   Mutual TLS (mTLS) for service-to-service encryption -> Option C

4. Quick Check:

   mTLS = automatic encryption in Istio [OK]

Hint: Use mTLS to encrypt service traffic automatically [OK]

Common Mistakes:

• Confusing sidecar injection with encryption
• Thinking Gateway secures internal traffic
• Mixing monitoring tools with security features