Module 1: Why Kubernetes And The Continuity Challenge

4. Hands-on: installing `kind` and `kubectl`

Next →

Description

Everything that follows in this guide — from the first cluster to the complete Module 8 capstone — runs on two tools, neither optional: kind, which creates a real Kubernetes cluster inside Docker containers on your own machine, and kubectl, the command-line interface you'll use to talk to any Kubernetes cluster, whether local kind or production EKS. This lesson installs both, for real, on your machine, and confirms the exact version you'll use for the rest of the guide — everything you see here ran to write this lesson, with the honest caveat that your own output will vary based on your processor architecture and minor packaging details of your operating system.

Connection to the module

Lesson 3 left you with the criteria and the continuity challenge resolved, without having touched a terminal yet. This lesson is the lab's first physical piece: without kind and kubectl installed, lesson 5 (your first cluster) can't start.

Before installing anything: confirm Docker is running

kind doesn't replace Docker — it uses it. Each "node" in a kind cluster is, underneath, a Docker container running a special image (kindest/node) that packages a complete Kubernetes system inside. Without a Docker engine running, kind has nowhere to create anything.

docker info --format '{{.ServerVersion}}'

What to expect (your exact Docker version is your variable value — what matters is that the command returns a version, not a connection error):

29.6.1

If this command fails with a connection error (Cannot connect to the Docker daemon), open Docker Desktop (macOS/Windows) or start the docker service (Linux) before continuing — nothing that follows in this guide works without this.

Step 1 — Install kind

kind (kubernetes-in-docker) is an official kubernetes-sigs project — the same GitHub organization space where the Kubernetes project itself lives — built specifically to run local test and CI clusters, not as a separate simulator but as real Kubernetes conveniently packaged. The installation method changes depending on your operating system:

macOS or Linux, with Homebrew installed:

brew install kind

What to expect (executed — your exact installation path depends on your Homebrew setup, but the package version is the same for everyone):

==> Fetching downloads for: kind
✔︎ Bottle kind (0.32.0)
==> Would install 1 formula:
kind
🍺  /opt/homebrew/Cellar/kind/0.32.0: 10 files, 10MB

Linux, without Homebrew (direct binary):

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.32.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

If your architecture isn't amd64 (for example, an ARM server), change the binary suffix to kind-linux-arm64 — kind's own documentation publishes one binary per operating-system-and-architecture combination, never a universal installer.

Windows, with Chocolatey:

choco install kind

In all three cases, the goal is the same: a single kind binary on your PATH. The official documentation (linked in Resources) keeps the complete, up-to-date list of methods, including go install for anyone who already has a Go toolchain set up.

Verify the version

kind version

What to expect (go1.26.3 and darwin/arm64 are your specific platform — variable; v0.32.0 is the version this guide uses and verified, and should be that or newer):

kind v0.32.0 go1.26.3 darwin/arm64

If your version is older than v0.32.0. It's not necessarily a problem — many commands in this guide work the same on somewhat older versions — but if something behaves differently from what a later lesson describes, update first (brew upgrade kind or your package manager's equivalent) before reporting the behavior as a guide error.

Step 2 — Install kubectl

kubectl isn't specific to kind — it's the official CLI for all of Kubernetes, the same binary you'll use against a real EKS cluster in Module 7. This is, in fact, the central pedagogical reason this guide invests so much time in kind: what you learn against kind transfers to EKS with zero translation, because the client is identical.

macOS or Linux, with Homebrew:

brew install kubectl

Any platform, direct binary (the method kubernetes.io documents as universal):

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl

Swap darwin/arm64 for your operating-system-and-architecture combination (linux/amd64, windows/amd64, etc.) — the official Kubernetes documentation publishes the exact URL for each one.

Verify the version

kubectl version --client

What to expect (v1.36.1 is the version this guide uses; Kustomize Version has shipped alongside kubectl for several versions now, bundled by default):

Client Version: v1.36.1
Kustomize Version: v5.8.1

Notice the --client flag: without it, kubectl version also tries to report the server's version — the cluster you're connected to — and, at this point in the guide, you haven't created any cluster yet. Confirm it yourself:

kubectl version

What to expect (the exact error message when no cluster is configured — you're going to resolve this in lesson 5):

Client Version: v1.36.1
Kustomize Version: v5.8.1
The connection to the server localhost:8080 was refused - did you specify the right host or port?

localhost:8080 is the default address kubectl tries when it can't find any cluster configuration file (~/.kube/config) — literally "I don't know who to ask," not an error in your installation. Lesson 5 resolves exactly this: when you create a cluster with kind, the tool itself writes the necessary configuration into that file, and this same command (without --client) will then also report the server's version.

Analogy: buying cleats and a whistle before the first practice

Installing kind and kubectl is like buying your gear before a team sport's first practice: the cleats (kind, which is going to create the playing field) and the whistle (kubectl, with which you're going to give every instruction to the whole team, whether the match is a local practice game or the real match at the big stadium). None of this is the match yet — you won't see any cluster running until lesson 5 — but without this gear, you can't even step onto the field. And, exactly like a referee's whistle works the same in any stadium, kubectl works identically against this guide's practice field (kind) and against the real production stadium (EKS, Module 7).

Common mistakes

Installing the wrong architecture's binary on Linux or Windows (installation, silent until it fails confusingly). What happens: someone on an ARM-processor server downloads the kind-linux-amd64 binary (the most common one in tutorials, meant for x86_64), and the binary simply doesn't run, or runs with erratic behavior. Why it happens: most generic guides online assume amd64 because it's still the most common server architecture, but more and more machines — including Apple Silicon Macs and many cloud ARM instances — use arm64. How to spot it: the kind version command fails with an "exec format error" or simply "command not found" after an apparently successful installation. How to fix it: confirm your architecture with uname -m (x86_64 = amd64; aarch64/arm64 = arm64) before choosing the binary, and download the exact matching one.

Confusing the absence of --client with an installation error (conceptual, directly tied to this lesson's Step 2). What happens: someone runs kubectl version (without the flag) right after installing, sees the "connection refused" error, and concludes kubectl's installation failed. Why it happens: the error message doesn't explicitly say "you don't have any cluster yet" — it just says it couldn't connect to a specific address, which sounds like an installation problem. How to spot it: if kubectl version --client (with the flag) does work and shows the correct version, your installation is fine — the error only shows up without --client, because there kubectl also tries to report the server's version. How to fix it: use --client until you have a real cluster (lesson 5); after that, kubectl version without the flag will work fully, showing both client and server.

Forgetting Docker is running, and blaming kind when the real error is Docker's (sequencing, the most common one in this whole lesson). What happens: someone installs kind and kubectl correctly, but Docker Desktop is closed (or the Linux docker service is stopped), and when trying any kind operation in lesson 5, gets a confusing error about not being able to create containers. Why it happens: kind version and kubectl version --client — this lesson's two verification commands — don't need Docker running to work, so it's easy to finish this lesson thinking "everything's ready" without having confirmed the most important requirement. How to spot it: the docker info command from this lesson's "Before installing anything" section fails with a connection error. How to fix it: before moving on to lesson 5, run docker info --format '{{.ServerVersion}}' again — if it doesn't return a clean version, start Docker Desktop or your system's docker service before continuing.

Exercises

Exercise 1 — Reconstruct each tool's purpose without looking at the lesson. In one sentence each, explain what kind does and what kubectl does, and why they're two separate tools instead of one.

See solution

kind creates real Kubernetes clusters inside Docker containers on your machine — it's the tool that builds the playing field. kubectl talks to any already-existing Kubernetes cluster, whether created by kind, by EKS, or by any other method — it's the tool that gives instructions. They're two separate tools because they solve different problems: one is specific to creating local test clusters (it only makes sense in a development/CI context), while the other is universal to any Kubernetes cluster that exists, no matter who created it or how — in fact, kubectl works exactly the same against a real EKS cluster that never used kind for anything.

Exercise 2 — Diagnose a real error. A coworker installs kind and kubectl, runs kubectl version (without --client), and sees: The connection to the server localhost:8080 was refused. Without looking at this lesson's solution, explain whether this means their installation failed, and what command you'd use to confirm your diagnosis.

See solution

It doesn't mean the installation failed — it means there's no cluster configured yet in ~/.kube/config, so kubectl tries to connect to the default address (localhost:8080) and, logically, finds nothing there. The command that confirms the diagnosis is kubectl version --client: if that command shows the client version with no error, kubectl's installation is perfectly fine, and all that's missing is creating a cluster — exactly what lesson 5 resolves.

Exercise 3 — Explain the knowledge transfer to a colleague. A colleague asks: "if I'm going to learn against kind, local and free, does that knowledge actually help me work with real EKS on a job?" Answer them in two or three sentences, based on what you learned about kubectl in this lesson.

See solution

A complete answer sounds roughly like this: "Yes, almost entirely. kubectl is Kubernetes' official CLI in general, not a kind-specific tool — the same binary, with the same syntax, talks to any Kubernetes cluster, including real EKS. What changes between kind and EKS isn't how you interact with the cluster (that's identical), but who administers the control plane behind it and how the compute is obtained — this guide's Module 7 covers that in depth."

Summary and next step

In this lesson you really installed the two tools the rest of this guide runs on: kind (v0.32.0 or newer), which creates real Kubernetes clusters inside Docker containers, and kubectl (v1.36.1), Kubernetes' official CLI you'll use unchanged against local kind and, in Module 7, against the real EKS model. You confirmed both versions with literal evidence from your own terminal, and saw, firsthand, the exact error message kubectl shows when no cluster exists yet — the exact problem lesson 5 resolves.

Before moving on you should be able to: explain the difference in purpose between kind and kubectl; diagnose the "connection refused" error without assuming the installation failed; and confirm Docker is running before attempting to create a cluster.

Lesson 5 uses these two tools to create your first real cluster: andes-cargo-cluster, under the same name aws-serverless-and-containers-guide left documented, now actually running.

Resources

  1. kind — Quick Start — the official installation guide, source of Step 1's three methods.
  2. kind — Releases — the official version listing, including v0.32.0.
  3. Kubernetes — Install Tools: kubectl — the official kubectl installation guide for each operating system, source of Step 2.
  4. Docker Docs — docker info — official reference for the command used in this lesson's earlier verification.
← Previous3. The continuity challenge: picking up `andes-cargo-status-api` where it left offNext →5. Hands-on: your first cluster