istioctl install is the fastest way to get a mesh running for learning or local testing, but Helm is Istio’s officially recommended method for a production installation you intend to manage, version, and customize over time. This guide installs Istio with Helm, and covers what replaced the Istio Operator for the kind of fine-grained customization older material points you toward it for.

A note before you start: the Istio Operator is gone

Istio used to ship an in-cluster Istio Operator: a controller watching an IstioOperator custom resource and reconciling the cluster to match it. If you’ve seen tutorials, certification material, or older documentation built around dumping a profile to an IstioOperator YAML file and applying it, that’s what they’re describing. The in-cluster operator was deprecated in Istio 1.23 and removed entirely in 1.24. It no longer exists in current Istio releases.

What replaced it is more direct: Helm values files. The same customization that used to go through an IstioOperator resource, enabling a gateway, adjusting resource requests, changing a component’s settings, is now expressed as Helm values and applied with helm install or helm upgrade, the same way you’d customize any other Helm chart. If you’re studying from material that centers the Operator as essential, treat the underlying concept (customize settings in a file, apply it, Istio reconciles to match) as still valid, but translate the mechanism to Helm.

Install the three core charts

Istio’s Helm installation is split into three charts, installed in order:

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update

# 1. CRDs and cluster-wide resources
helm install istio-base istio/base -n istio-system --create-namespace

# 2. The control plane (istiod)
helm install istiod istio/istiod -n istio-system --wait

# 3. The ingress gateway (optional, if you need external traffic entry)
helm install istio-ingressgateway istio/gateway -n istio-system

istio-base installs the CustomResourceDefinitions and cluster-wide RBAC resources every other piece depends on, and has to land first. istiod is the control plane itself. The gateway chart is only needed if you want a managed ingress (or egress) gateway; a mesh with only sidecar-to-sidecar traffic can skip it.

kubectl get pods -n istio-system
helm list -n istio-system

You should see istiod and, if installed, the gateway, Running, and helm list should show all three releases.

Customize settings with values

Each chart accepts its own values, discoverable the same way as any Helm chart:

helm show values istio/istiod > istiod-values.yaml

Edit the file, then install (or upgrade) with it:

helm upgrade istiod istio/istiod -n istio-system -f istiod-values.yaml

Common customizations: resource requests and limits for istiod or the gateways, enabling an egress gateway (disabled by default on most profiles), or adjusting mesh-wide settings under meshConfig. Everything the Istio Operator used to let you configure through spec.components or spec.meshConfig has a Helm values equivalent; Istio’s own Helm installation documentation is the authoritative reference for exactly which values map to which behavior for the version you’re running.

Apply a change

helm upgrade istiod istio/istiod -n istio-system -f istiod-values.yaml

Same pattern as any other Helm upgrade: edit the values, re-run helm upgrade, and Helm reconciles the live resources to match. There’s no separate “apply the operator config” step the way older material describes; the helm upgrade is the apply step.

Uninstalling

helm uninstall istio-ingressgateway -n istio-system
helm uninstall istiod -n istio-system
helm uninstall istio-base -n istio-system
kubectl delete namespace istio-system

Unlike istioctl uninstall --purge, which removes everything in one command, Helm’s approach uninstalls each release individually, in roughly the reverse order they were installed, since later charts can depend on resources the base chart created.