istioctl is the fastest way to get Istio running on a cluster, which makes it the right starting point for learning the mesh even though Helm (covered in the next guide) is the better fit for a production install you’ll manage long-term. This guide installs Istio, confirms it’s healthy, and injects a sidecar into a real workload.

Before you install: cluster resources

Istio’s control plane and ingress/egress gateways need real CPU and memory, more than a default local cluster typically allocates. On minikube specifically, start the cluster with headroom:

minikube start --cpus=4 --memory=8192

Undersized resources are a common source of Istio Pods stuck Pending or CrashLoopBackOff on a first install, worth ruling out before troubleshooting anything else.

Install istioctl

Download the release for your platform from Istio’s releases page, or use the install script:

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
istioctl version --remote=false

The export PATH line only applies to your current shell session; add it to your shell profile (~/.bashrc, ~/.zshrc) if you want istioctl available in every new terminal without repeating this step.

Install Istio into the cluster

istioctl install --set profile=demo -y

-y skips the confirmation prompt. The demo profile installs the control plane plus both ingress and egress gateways, with resource settings light enough for a local cluster; production installs typically start from the leaner default profile instead, covered in the Helm guide. List the available profiles if you want to see what each includes before choosing:

istioctl profile list

Confirm the install:

kubectl get pods -n istio-system

You should see istiod and, with the demo profile, istio-ingressgateway and istio-egressgateway, all Running.

Confirm installing Istio didn’t change anything yet

This is worth checking explicitly, because it surprises people the first time: installing Istio has no effect on existing workloads. No sidecars appear, nothing about how your applications run changes, until you explicitly enable injection. Istio sitting in the cluster unused costs you the resources its own control plane and gateways consume, nothing more.

Enable sidecar injection for a namespace

kubectl label namespace default istio-injection=enabled
kubectl get namespace default --show-labels

This only affects Pods created after the label is applied. For Pods that already existed in that namespace, recreate them:

kubectl delete pods --all -n default
kubectl rollout restart deployment -n default

(Or reapply whatever manifests originally created them; a plain kubectl delete followed by kubectl apply of the same unmodified files works identically; nothing about the manifests themselves needs to change for injection to apply.)

Confirm a sidecar actually landed

kubectl get pods -n default

A Pod with its sidecar present shows 2/2 under READY instead of 1/1. Confirm what that second container actually is:

kubectl describe pod <pod-name> -n default

You should see an istio-init init container (which configures traffic interception) and an istio-proxy container alongside your application’s own, listed under Containers in the output.

Inject a single workload manually, without labeling a namespace

Sometimes meshing an entire namespace isn’t what you want, only one specific workload. istioctl kube-inject adds the sidecar to a manifest before it’s applied, rather than relying on namespace-wide automatic injection:

istioctl kube-inject -f my-deployment.yaml | kubectl apply -f -

This is the manual equivalent of what the namespace label triggers automatically: a sidecar spec, generated by istioctl and merged into your manifest, applied in one step. Useful for a namespace with mixed meshed and unmeshed workloads, where labeling the whole namespace would mesh more than you intend.

Uninstalling

istioctl uninstall --purge -y
kubectl delete namespace istio-system

--purge removes everything the install added, including resources from profiles other than the one currently active, which matters if you’ve switched profiles during testing and want a clean removal rather than leftovers from an earlier install.