Lab prerequisites

The rest of this course works against a real cluster — a small Kubernetes-in-Docker setup with Istio and a multi-service sample app you can break on purpose. Before we boot it, set up a workspace and install four tools.

One workspace, one teardown

Pick a single directory and do everything from there — config files, downloaded binaries, manifests. Knowing exactly where the lab lives means you can clean it up in one step at the end without hunting for stray files.

mkdir ~/incident-cluster && cd ~/incident-cluster

Every command in this course assumes you're inside ~/incident-cluster/. If you open a fresh terminal later, run cd ~/incident-cluster before doing anything else. We'll save the cluster config, the gateway/route manifests, and even the Istio release itself into this directory — so the entire lab footprint lives in one place.

What each tool does

Tool	Role in this course
kind	Runs a multi-node Kubernetes cluster as Docker containers on your laptop. Each "node" is a container; the control plane and workers share a Docker network. Faster to recreate than minikube; closer to a real cluster than k3d for our purposes.
kubectl	The Kubernetes API client. Everything you do against the cluster — apply manifests, describe pods, port-forward services — goes through it.
helm	Package manager for Kubernetes. We use it later when we install operators that ship as Helm charts.
istioctl	Istio's installer + diagnostic tool. Used once to install the mesh, then again whenever we want to inspect proxy config.

Install (macOS)

Three of the four come from Homebrew (global install — they live in /opt/homebrew/bin/ and stay on your machine even after teardown):

brew install kind kubectl helm

The fourth, istioctl, ships as a curl-installer that drops a release directory wherever you run it. We run it inside ~/incident-cluster/ so the full ~200 MB Istio bundle stays contained:

cd ~/incident-cluster
curl -L https://istio.io/downloadIstio | sh -

You'll get a directory like istio-1.29.2/ (or whatever the latest version is) containing bin/istioctl plus sample manifests and tools. Add its bin/ to your shell PATH:

ls ~/incident-cluster                                     # confirm the version
echo 'export PATH="$PATH:$HOME/incident-cluster/istio-1.29.2/bin"' >> ~/.zshrc
source ~/.zshrc

Adjust 1.29.2 to match the directory name you actually got from the installer. If you ever upgrade Istio, the path needs to be updated too — that's the cost of keeping the binary scoped to the workspace.

Docker is the runtime

kind runs Kubernetes nodes as Docker containers, so the Docker daemon has to be up before anything in this course works. On macOS that means launching Docker Desktop (or Colima/OrbStack if you prefer those). If docker ps errors with Cannot connect to the Docker daemon, fix that first — this is the most common "why is my cluster not starting" cause throughout the course.

Acceptance test

Run all five from inside ~/incident-cluster/ — every command should print a version, no errors:

kind --version
kubectl version --client
helm version --short
istioctl version --remote=false
docker info | head -5

If any of these fail, stop here. The next lesson assumes all five succeed.

A note on the word "kind"

You'll see kind mean two different things in this course. The CLI tool we just installed is one. The kind: field at the top of every Kubernetes manifest (kind: Pod, kind: ServiceAccount) is something else entirely — it's how the API server identifies the type of resource a YAML file declares. Same word, different layers; nothing in common.