Istio overview in Kubernetes - Commands & Configuration

Introduction

Istio helps manage how different parts of an application talk to each other inside a Kubernetes cluster. It solves problems like controlling traffic, securing communication, and monitoring services without changing the app code.

When you want to control traffic flow between microservices without changing their code

When you need to add security like encryption and authentication between services

When you want to monitor and trace requests across multiple services easily

When you want to test new versions of services safely with traffic splitting

When you want to enforce policies like rate limiting or access control on service calls

Commands

Create a separate namespace for Istio components to keep them organized and isolated.

Terminal

kubectl create namespace istio-system

Expected Output

namespace/istio-system created

Install Istio control plane components in the istio-system namespace using the official installation manifest.

Terminal

kubectl apply -f https://istio.io/latest/docs/setup/install/istio-minimal.yaml -n istio-system

Expected Output

customresourcedefinition.apiextensions.k8s.io/destinationrules.networking.istio.io created

customresourcedefinition.apiextensions.k8s.io/gateways.networking.istio.io created

customresourcedefinition.apiextensions.k8s.io/virtualservices.networking.istio.io created

... (other resources created)

deployment.apps/istiod created

service/istiod created

→

-f - Apply configuration from a file or URL

→

-n - Specify the namespace to install Istio components

Enable automatic Istio sidecar injection for pods in the default namespace so traffic can be managed by Istio.

Terminal

kubectl label namespace default istio-injection=enabled

Expected Output

namespace/default labeled

Check that Istio pods are running properly in the istio-system namespace.

Terminal

kubectl get pods -n istio-system

Expected Output

NAME                                   READY   STATUS    RESTARTS   AGE

istiod-5f7d9f7d7d-abcde                1/1     Running   0          2m

istio-ingressgateway-7c9d8f9f7f-xyz12  1/1     Running   0          2m

→

-n - Show pods in the specified namespace

Key Concept

If you remember nothing else from Istio, remember: it manages service communication transparently by injecting sidecars that control traffic, security, and monitoring.

Common Mistakes

Not labeling the namespace for automatic sidecar injection

Without the label, Istio does not add its sidecar proxy to your app pods, so traffic is not managed by Istio.

Always run 'kubectl label namespace <namespace> istio-injection=enabled' before deploying your app pods.

Installing Istio components in the wrong namespace

Istio expects its control plane to run in the 'istio-system' namespace; installing elsewhere can cause failures.

Create and use the 'istio-system' namespace for Istio installation.

Summary

Create the 'istio-system' namespace to isolate Istio components.

Install Istio control plane using the official manifest in the 'istio-system' namespace.

Label your app namespace to enable automatic sidecar injection for traffic management.

Verify Istio pods are running to ensure the service mesh is active.

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