Introduction

With kind, the Kubernetes version comes from the node image you choose when creating the cluster. You do not typically "upgrade" the version inside an existing kind cluster. Instead, you create a cluster with the specific kindest/node image tag that matches the Kubernetes release you want to test.

Pick the Kubernetes Version Through the Node Image

A basic cluster using a specific Kubernetes release looks like this:

kind create cluster \
  --name k129 \
  --image kindest/node:v1.29.2

That command tells kind which node image to boot. The Kubernetes version inside the cluster comes from that image tag.

You can verify the server version afterward:

kubectl cluster-info --context kind-k129
kubectl version

If you want multiple versions side by side, create multiple named clusters:

kind create cluster --name k128 --image kindest/node:v1.28.7
kind create cluster --name k129 --image kindest/node:v1.29.2

That is one of the main advantages of kind: fast, disposable version-specific clusters for testing.

Use a Config File for Multi-Node Clusters

If you want a specific version plus a predictable topology, combine the node image with a cluster config file:

1kind: Cluster
2apiVersion: kind.x-k8s.io/v1alpha4
3nodes:
4  - role: control-plane
5  - role: worker
6  - role: worker

Then create the cluster:

1kind create cluster \
2  --name demo \
3  --image kindest/node:v1.29.2 \
4  --config kind-config.yaml

This is useful for testing scheduling behavior, upgrades across environments, or compatibility with a specific Kubernetes minor release.

Do Not Assume Every Version Works with Every kind Release

kind is built around versioned node images, and support is tied to what the project publishes. The safest approach is:

• install a recent kind release
• use kindest/node image tags published by the project
• check release notes when using older or unusual Kubernetes versions

If you pick an arbitrary image tag that is not published or not compatible with your kind version, cluster creation may fail or behave unpredictably.

Recreate Instead of Mutating In Place

Unlike a managed Kubernetes environment, kind is meant to be disposable. If you want to switch versions, delete and recreate the cluster:

kind delete cluster --name k129
kind create cluster --name k130 --image kindest/node:v1.30.0

That workflow is normal. Trying to treat a local kind cluster like a long-lived environment usually creates more friction than value.

Useful Testing Pattern

A practical version-compatibility check might look like this:

1kind create cluster --name app-k128 --image kindest/node:v1.28.7
2kubectl config use-context kind-app-k128
3kubectl apply -f k8s/
4
5kind create cluster --name app-k129 --image kindest/node:v1.29.2
6kubectl config use-context kind-app-k129
7kubectl apply -f k8s/

Now you can compare whether your manifests, controllers, or admission policies behave consistently across versions.

Common Pitfalls

The biggest pitfall is assuming kind has a flag like --kubernetes-version separate from the node image. In practice, the image tag is the version selector.

Another mistake is trying to change the version of an existing cluster in place. For kind, recreation is the normal path.

Teams also sometimes forget the kubectl context name. A cluster created with --name demo uses the context kind-demo, not just demo.

Finally, be careful with old blog posts that reference outdated image tags. Use image versions published by the kind project rather than guessing.

Summary

• In kind, the Kubernetes version is chosen through the kindest/node image tag.
• Create clusters with kind create cluster --image ... for the version you want.
• Use named clusters and config files to test multiple versions and topologies.
• Recreate clusters to change versions instead of mutating them in place.
• Prefer published, supported node images that match your kind release.