Learn Istio - Installation & Upgrade (istioctl, Operator, Helm)

#Introduction

Your cluster is ready from episode 0, and the architecture is understood from episode 2. Now it is time for the real thing: installing Istio. Episode 3 covers the three installation methods, how to pick a profile that fits your environment, and a safe upgrade strategy — decisions that will affect your entire mesh operations.

Do not rush. The choice of installation method is not a matter of taste alone: it determines how you upgrade, who holds the configuration state, and how easily installation can be automated.

#Installation Options: istioctl, Operator, Helm

#istioctl install

The simplest and most widely used method for practice and small environments:

istioctl install --set profile=demo -y

istioctl install --set profile=demo applies a specific profile and waits until all components are ready. The advantages of this method: one command, clear output, and a --set mechanism for direct customization. The drawbacks: it is less suited to GitOps because the configuration lives in the command line rather than in a manifest.

#Istio Operator

A method based on the Kubernetes Operator pattern: you define an IstioOperator resource and the operator keeps the cluster state aligned with that description.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: example-istiocontrolplane
spec:
  profile: demo

Because this resource is plain YAML, it can be stored in a repository and applied through GitOps. The operator also handles upgrades in a more controlled way. The drawbacks: an additional concept (the operator) and an operator release cycle you must keep track of.

#Helm

The method closest to the modern Kubernetes ecosystem. Every component (base, istiod, ingress gateway) is a Helm chart:

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm install istio-base istio/base -n istio-system --create-namespace
helm install istiod istio/istiod -n istio-system --set profile=default

helm install istiod istio/istiod gives you granular control through values and natural integration with Helm-based GitOps tools like ArgoCD. The drawback: you must understand the install order — base first, then istiod, then the gateway — rather than a single command.

#Choosing the Right Profile

#Profile Comparison

Istio ships several built-in profiles:

• default: core features with a balanced trade-off, the best fit for production.
• demo: full-featured for experiments, including grafana, prometheus, kiali, and jaeger.
• minimal: only the istiod control plane, the lightest option.
• ambient: for sidecar-less ambient mesh mode (we cover this in episode 17).
• external / remote: for multi-cluster topologies (episode 16).

Check the available profiles with istioctl profile list. For production, start from default and enable observability components selectively, rather than copying demo wholesale.

#Custom Profile

As your needs grow, create a custom profile file instead of stacking --set flags:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: prod-profile
spec:
  profile: default
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
    egressGateways:
    - name: istio-egressgateway
      enabled: true
  meshConfig:
    enablePrometheusMerge: true

This file can be applied with istioctl install -f prod-profile.yaml and stored in Git for auditability.

#Upgrade Strategy

#istioctl x upgrade

Upgrading a minor version of Istio with istioctl x upgrade can only move one minor version per step (for example 1.21 to 1.22, not directly to 1.23). The process: verify the pre-requisites, download the new istioctl version, then run the upgrade:

istioctl x precheck
istioctl x upgrade -y

Always run istioctl x precheck before an upgrade to catch issues such as lagging CRDs. Read the release notes of the target version because some features change or get deprecated.

#Canary Install

To reduce risk, use a canary install: install the new version alongside the old one, then move workloads one by one via a revision label.

istioctl install --revision=canary --set profile=default -y
kubectl label namespace default istio.io/rev=canary --overwrite

The istio.io/rev=canary label on the namespace makes new workloads in that namespace use the canary revision. The old istiod keeps serving workloads that have not moved yet, so rolling back is just a matter of switching the label back. We will cover the full workload migration details in episode 4.

#Summary

Episode 3 actually got Istio running: you now understand the three installation methods (istioctl, operator, Helm), can choose the right profile, and have an upgrade strategy using canary installs and istioctl x upgrade.

Key takeaways:

• istioctl is fast for experiments; the operator and Helm are friendlier to GitOps.
• The default profile is for production, demo for experiments, minimal for tight memory budgets.
• Large customizations should go through an IstioOperator file, not a stack of --set flags.
• Minor upgrades must be sequential: one minor version per step.
• istioctl x precheck is mandatory before an upgrade.
• Canary installs use revisions and the istio.io/rev label for gradual migration.
• The istioctl version must match the Istio version you use.

In the next episode, episode 4, we will enable sidecar injection and workload onboarding — switching namespaces to the istio-injection=enabled or istio.io/rev label, understanding the difference between automatic and manual injection with istioctl kube-inject, and adding non-Kubernetes workloads through WorkloadEntry.