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.

This lesson recaps the key points for installing and configuring Istio on Kubernetes. It covers prerequisites, installation methods, sidecar injection patterns (including Ambient mode and Waypoint), customization via the Istio Operator and Helm, and safe revision-based (canary) upgrades.

​
Prerequisites

  • A working Kubernetes cluster is required. This can be a managed cluster such as AWS EKS or a local development cluster like kind.
  • kubectl configured to communicate with your cluster and appropriate RBAC permissions to install cluster components.

​
Installation methods

Istio can be installed in multiple ways. Choose the approach that matches your operational model:
MethodUse caseNotes
istioctlRecommended for most usersSimplest path for single control plane installs and for revision-based installs.
Helm chartsGitOps / declarative management (e.g., Argo CD)Manage base, istiod, and gateway charts for fine-grained control.
Istio OperatorEnterprise-grade lifecycle managementUseful for recurring customizations and day-2 operations.
Typical Helm chart layout you may manage:
  • Istio base (CRDs and cluster-level resources)
  • Istiod (control plane)
  • Ingress/egress gateway (optional; needed for inbound traffic)

​
What installation actually deploys

Installing Istio deploys control plane components and supporting resources (CRDs, control plane pods, gateways, etc.). It does not automatically change existing workloads. To get data-plane behavior (sidecars) you must enable sidecar injection for target namespaces or inject the Envoy sidecar manually into pods when they are created.

​
Enabling sidecar injection

There are three primary options to inject data-plane proxies into your workloads:
  1. Automatic injection (namespace label)
    • Enable automatic sidecar injection for a namespace:
kubectl label namespace my-namespace istio-injection=enabled --overwrite
  • For revision-based (canary) control planes, label the namespace with the revision name:
kubectl label namespace my-namespace istio.io/rev=canary --overwrite
  1. Manual injection
    • Use istioctl kube-inject (older pattern) or the injection webhook can be bypassed and the sidecar added to pod specs manually. Manual injection is useful when you cannot or do not want to rely on namespace labels.
  2. Ambient mode (sidecarless)
    • Ambient mode runs ztunnel as a DaemonSet (one tunnel per node) instead of injecting per-workload Envoy sidecars. For L7 control in Ambient mode, deploy waypoint proxies at the namespace level.
Automatic injection labels and revision labels overwrite existing settings when you pass --overwrite. Be careful when relabeling production namespaces—workloads may need to be restarted to pick up a different revision or injection behavior.
  • Ambient mode and Waypoint
    • Ambient mode is Istio’s sidecarless option. The Ambient dataplane agent, ztunnel, runs as a DaemonSet — one tunnel per node.
    • If you need layer-7 (L7) proxying capabilities in Ambient mode or want per-namespace L7 control, use a waypoint proxy which operates at the namespace level rather than per-workload.
A presentation slide with a turquoise gradient left panel labeled "Summary" and colorful numbered markers down the center. The right side lists brief Istio takeaways (Ambient Mode, Istio Operator for customization, updating/removing with istioctl/Helm, and canary releases via revisions).

​
Istio Operator and customization

The Istio Operator provides a declarative, repeatable way to manage Istio lifecycle and configuration. Common workflows:
  • Edit an Operator CR or Helm values to change component settings.
  • Reapply the manifest to update an installation.
Examples: 
# Using istioctl with a config file
istioctl install -f istio-config.yaml

# Using Helm (example pattern)
helm upgrade --install istiod istio/istiod -n istio-system -f values.yaml
Operator or Helm is typically preferred when integrating Istio configuration into GitOps pipelines. Revision-based upgrades let you run multiple Istio control plane revisions side-by-side and migrate namespaces one-by-one. Typical steps:
  1. Install the new control plane with a revision name:
istioctl install --set revision=canary -y
  1. Label the namespaces you want to migrate:
kubectl label namespace my-namespace istio.io/rev=canary --overwrite
  1. Restart or roll the workloads in that namespace so new pods get the updated sidecars:
kubectl rollout restart deployment -n my-namespace
  1. Test traffic, validate behavior, then migrate additional namespaces or remove the old revision once you’re satisfied.
Revision-based upgrades, the Istio Operator, namespace labels for injection, and Ambient mode behavior are all topics likely to appear on the ICA exam. Make sure you can perform a canary revision upgrade and know how to enable/disable injection.

​
Quick reference — common commands

ActionCommand
Install Istio (default)istioctl install -y
Install with revisionistioctl install --set revision=canary -y
Enable automatic injection (namespace)kubectl label namespace my-namespace istio-injection=enabled --overwrite
Enable revision label for namespacekubectl label namespace my-namespace istio.io/rev=canary --overwrite
Restart workloads to pick up new sidecarkubectl rollout restart deployment -n my-namespace
Upgrade Istiod with Helmhelm upgrade --install istiod istio/istiod -n istio-system -f values.yaml
That’s it for this section.

Watch Video