Summary

​

Prerequisites

• A running Kubernetes cluster (cloud or local). Examples: AWS EKS, GKE, or local kind.
• Plan for additional cluster resources: Istio control plane and proxies consume CPU, memory, and network bandwidth.
• kubectl and istioctl (or Helm) installed on your local machine for management and troubleshooting.

​

Installation methods

• base
• istiod
• ingress / gateway (optional if you do not accept external traffic)

​

Sidecar injection and namespace management

# Legacy injection
kubectl label namespace myapp istio-injection=enabled

# Revision-based injection (recommended for canary upgrades)
kubectl label namespace myapp istio.io/rev=canary-1

• After labeling a namespace, existing pods must be restarted so that new sidecars get injected.
• Revision-based labels map namespaces to a specific control plane revision and enable running multiple control planes concurrently.

​

Ambient mode (sidecarless) and Waypoint proxies

• In Ambient mode a ztunnel runs as a DaemonSet (one ztunnel per node) to enforce mTLS and network-level policies without per-pod sidecars.
• If you require Layer 7 features (L7 routing, application-level proxies) at namespace granularity rather than per-workload sidecars, consider deploying Waypoint proxies which provide namespace-level application proxy functionality.

• Sidecar mode gives per-workload L7 capabilities and fine-grained routing.
• Ambient mode reduces injection overhead and simplifies some operational aspects at the cost of some L7 control patterns.

​

Istio Operator and customization

1. Create or edit an IstioOperator resource or Helm values file to express desired control plane configuration.
2. Apply changes with istioctl or Helm; the operator reconciles and updates the control plane accordingly.

istioctl install --set revision=canary-1 --set profile=default

• Use the operator to manage profiles, component enablement, and resource sizing.
• Keep your IstioOperator or Helm values in source control for reproducibility (ideal for GitOps).

​

Canary (revision) upgrades for the Istio control plane

1. Install the new control plane with a revision label:

istioctl install --set revision=<new-revision> --set profile=default

2. Label target namespaces to use the new revision:

kubectl label namespace <namespace> istio.io/rev=<new-revision>

3. Restart workloads (or let rolling updates occur) so pods are recreated and injected with the new proxy. Examples:

kubectl rollout restart deployment/myapp -n <namespace>
# or delete pods to force recreation
kubectl delete pod -l app=myapp -n <namespace>

4. Validate application behavior and traffic routing with tests and telemetry (logs, metrics, traces).
5. When stable, uninstall the old control plane revision:

istioctl uninstall --revision=<old-revision>

• Confirm namespace labels target the intended revision.
• Verify sidecar proxies in pods match the new revision.
• Run integration and traffic-shift tests before decommissioning old revisions.

​

Quick commands reference

​

Final reminders

• Always verify namespace labels before expecting automatic sidecar injection.
• Know when to use sidecar vs ambient mode and how ztunnel and Waypoint proxies differ.
• Use the Istio operator (IstioOperator CR) or Helm values for repeatable configuration; store these artifacts in version control.
• Practice the canary revision upgrade flow: install revision, migrate namespaces, validate traffic, then remove the old revision.

​

Links and references

• Istio official docs: https://istio.io/
• GitOps with Argo CD
• Istio Certified Associate course (exam prep)