Quick Start

This guide covers getting started with the kind command.

If you are having problems please see the known issues guide.

Installation

NOTE: kind does not require kubectl, but you will not be able to perform some of the examples in our docs without it. To install kubectl see the upstream kubectl installation docs.

If you are a go developer you may find the go get option convenient.

Otherwise we supply downloadable release binaries, community-managed packages, and a source installation guide.

Stable tagged releases (currently v0.14.0) are generally strongly recommended for CI usage in particular.

You may need to install the latest code from source at HEAD if you are developing Kubernetes itself at HEAD / the latest sources.

Installing With A Package Manager

The kind community has enabled installation via the following package managers.

On macOS via Homebrew:

  1. brew install kind

On macOS via MacPorts:

  1. sudo port selfupdate && sudo port install kind

On Windows via Chocolatey (https://chocolatey.org/packages/kind)

  1. choco install kind

Installing From Release Binaries

Pre-built binaries are available on our releases page.

To install, download the binary for your platform from “Assets”, then rename it to kind (or perhaps kind.exe on Windows) and place this into your $PATH at your preferred binary installation directory.

On Linux:

  1. curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.14.0/kind-linux-amd64
  2. chmod +x ./kind
  3. mv ./kind /some-dir-in-your-PATH/kind

On macOS:

  1. # for Intel Macs
  2. [ $(uname -m) = x86_64 ]&& curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.14.0/kind-darwin-amd64
  3. # for M1 / ARM Macs
  4. [ $(uname -m) = arm64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.14.0/kind-darwin-arm64
  5. chmod +x ./kind
  6. mv ./kind /some-dir-in-your-PATH/kind

On Windows in PowerShell:

  1. curl.exe -Lo kind-windows-amd64.exe https://kind.sigs.k8s.io/dl/v0.14.0/kind-windows-amd64
  2. Move-Item .\kind-windows-amd64.exe c:\some-dir-in-your-PATH\kind.exe

Installing From Source

In addition to the pre-built binary + package manager installation options listed above you can install kind from source with GO111MODULE="on" go get sigs.k8s.io/kind@v0.14.0 or clone this repo and run make build from the repository.

Installing With make

Using make build does not require installing Go and will build kind reproducibly, the binary will be in bin/kind inside your clone of the repo.

You should only need make and standard userspace utilities to run this build, it will automatically obtain the correct go version with our vendored copy of gimmee.

You can then call ./bin/kind to use it, or copy bin/kind into some directory in your system PATH to use it as kind from the command line.

make install will attempt to mimic go install and has the same path requirements as go install below.

Installing with go get / go install

When installing with Go please use the latest stable Go release, ideally go1.16 or greater.

For Go versions go1.17 and higher, you should use to go install sigs.k8s.io/kind@v0.14.0 per https://tip.golang.org/doc/go1.17#go-get

For older versions use GO111MODULE="on" go get sigs.k8s.io/kind@v0.14.0.

For either version if you are building from a local source clone, use go install . from the top-level directory of the clone.

NOTE: go get should not be run from a Go modules enabled project directory, as go get inside a modules enabled project updates dependencies / behaves differently. Try for example cd $HOME first.

go get / go install will typically put the kind binary inside the bin directory under go env GOPATH, see Go’s “Compile and install packages and dependencies” for more on this. You may need to add that directory to your $PATH if you encounter the error kind: command not found after installation, you can find a guide for adding a directory to your PATH at https://gist.github.com/nex3/c395b2f8fd4b02068be37c961301caa7#file-path-md.

Creating a Cluster

Creating a Kubernetes cluster is as simple as kind create cluster.

This will bootstrap a Kubernetes cluster using a pre-built node image. Prebuilt images are hosted atkindest/node, but to find images suitable for a given release currently you should check the release notes for your given kind version (check with kind version) where you’ll find a complete listing of images created for a kind release.

To specify another image use the --image flag – kind create cluster --image=....

Using a different image allows you to change the Kubernetes version of the created cluster.

If you desire to build the node image yourself with a custom version see the building images section.

By default, the cluster will be given the name kind. Use the --name flag to assign the cluster a different context name.

If you want the create cluster command to block until the control plane reaches a ready status, you can use the --wait flag and specify a timeout. To use --wait you must specify the units of the time to wait. For example, to wait for 30 seconds, do --wait 30s, for 5 minutes do --wait 5m, etc.

More usage can be discovered with kind create cluster --help.

Interacting With Your Cluster

After creating a cluster, you can use kubectl to interact with it by using the configuration file generated by kind.

By default, the cluster access configuration is stored in ${HOME}/.kube/config if $KUBECONFIG environment variable is not set.

If $KUBECONFIG environment variable is set, then it is used as a list of paths (normal path delimiting rules for your system). These paths are merged. When a value is modified, it is modified in the file that defines the stanza. When a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the last file in the list.

You can use the --kubeconfig flag when creating the cluster, then only that file is loaded. The flag may only be set once and no merging takes place.

To see all the clusters you have created, you can use the get clusters command.

For example, let’s say you create two clusters:

  1. kind create cluster # Default cluster context name is `kind`.
  2. ...
  3. kind create cluster --name kind-2

When you list your kind clusters, you will see something like the following:

  1. kind get clusters
  2. kind
  3. kind-2

In order to interact with a specific cluster, you only need to specify the cluster name as a context in kubectl:

  1. kubectl cluster-info --context kind-kind
  2. kubectl cluster-info --context kind-kind-2

Deleting a Cluster

If you created a cluster with kind create cluster then deleting is equally simple:

  1. kind delete cluster

If the flag --name is not specified, kind will use the default cluster context name kind and delete that cluster.

Note: By design, requesting to delete a cluster that does not exist will not return an error. This is intentional and is a means to have an idempotent way of cleaning up resources.

Loading an Image Into Your Cluster

Docker images can be loaded into your cluster nodes with:

kind load docker-image my-custom-image-0 my-custom-image-1

Note: If using a named cluster you will need to specify the name of the cluster you wish to load the images into: kind load docker-image my-custom-image-0 my-custom-image-1 --name kind-2

Additionally, image archives can be loaded with: kind load image-archive /my-image-archive.tar

This allows a workflow like:

  1. docker build -t my-custom-image:unique-tag ./my-image-dir
  2. kind load docker-image my-custom-image:unique-tag
  3. kubectl apply -f my-manifest-using-my-image:unique-tag

NOTE: You can get a list of images present on a cluster node by using docker exec:

  1. docker exec -it my-node-name crictl images

Where my-node-name is the name of the Docker container (e.g. kind-control-plane).

NOTE: The Kubernetes default pull policy is IfNotPresent unless the image tag is :latest or omitted (and implicitly :latest) in which case the default policy is Always. IfNotPresent causes the Kubelet to skip pulling an image if it already exists. If you want those images loaded into node to work as expected, please:

  • don’t use a :latest tag

and / or:

  • specify imagePullPolicy: IfNotPresent or imagePullPolicy: Never on your container(s).

See Kubernetes imagePullPolicy for more information.

See also: Using kind with Private Registries.

Building Images

NOTE: If you’re using Docker Desktop, be sure to read Settings for Docker Desktop first.

kind runs a local Kubernetes cluster by using Docker containers as “nodes”. kind uses the node-image to run Kubernetes artifacts, such as kubeadm or kubelet. The node-image in turn is built off the base-image, which installs all the dependencies needed for Docker and Kubernetes to run in a container.

Currently, kind supports one default way to build a node-image if you have the Kubernetes source in your host machine ($GOPATH/src/k8s.io/kubernetes), by using docker.

NOTE: Building Kubernetes node-images requires everything building upstream Kubernetes requires, we wrap the upstream build. This includes Docker with buildx. See: https://git.k8s.io/community/contributors/devel/development.md#building-kubernetes-with-docker

Settings for Docker Desktop

If you are building Kubernetes (for example - kind build node-image) on MacOS or Windows then you need a minimum of 6GB of RAM dedicated to the virtual machine (VM) running the Docker engine. 8GB is recommended.

To change the resource limits for the Docker on Mac, you’ll need to open the Preferences menu. Quick Start - 图1

Now, go to the Advanced settings page, and change the settings there, see changing Docker’s resource limits. Setting 8Gb of memory in Docker for Mac

To change the resource limits for the Docker on Windows, you’ll need to right-click the Moby icon on the taskbar, and choose “Settings”. If you see “Switch to Linux Containers”, then you’ll need to do that first before opening “Settings”

Quick Start - 图3

Now, go to the Advanced settings page, and change the settings there, see changing Docker’s resource limits.

Setting 8Gb of memory in Docker for Windows

You may also try removing any unused data left by the Docker engine - e.g., docker system prune.

Advanced

Configuring Your kind Cluster

For a sample kind configuration file see kind-example-config. To specify a configuration file when creating a cluster, use the --config flag:

  1. kind create cluster --config kind-example-config.yaml

Multi-node clusters

In particular, many users may be interested in multi-node clusters. A simple configuration for this can be achieved with the following config file contents:

  1. # three node (two workers) cluster config
  2. kind: Cluster
  3. apiVersion: kind.x-k8s.io/v1alpha4
  4. nodes:
  5. - role: control-plane
  6. - role: worker
  7. - role: worker

Control-plane HA

You can also have a cluster with multiple control-plane nodes:

  1. # a cluster with 3 control-plane nodes and 3 workers
  2. kind: Cluster
  3. apiVersion: kind.x-k8s.io/v1alpha4
  4. nodes:
  5. - role: control-plane
  6. - role: control-plane
  7. - role: control-plane
  8. - role: worker
  9. - role: worker
  10. - role: worker

Mapping ports to the host machine

You can map extra ports from the nodes to the host machine with extraPortMappings:

  1. kind: Cluster
  2. apiVersion: kind.x-k8s.io/v1alpha4
  3. nodes:
  4. - role: control-plane
  5.   extraPortMappings:
  6.   - containerPort: 80
  7.     hostPort: 80
  8.     listenAddress: "0.0.0.0" # Optional, defaults to "0.0.0.0"
  9.     protocol: udp # Optional, defaults to tcp

This can be useful if using NodePort services or daemonsets exposing host ports.

Note: binding the listenAddress to 127.0.0.1 may affect your ability to access the service.

You may want to see the Ingress Guide and LoadBalancer Guide.

Setting Kubernetes version

You can also set a specific Kubernetes version by setting the node‘s container image. You can find available image tags on the releases page. Please use the sha256 shasum for your desired kubernetes version, as seen in this example:

  1. kind: Cluster
  2. apiVersion: kind.x-k8s.io/v1alpha4
  3. nodes:
  4. - role: control-plane
  5.   image: kindest/node:v1.16.4@sha256:b91a2c2317a000f3a783489dfb755064177dbc3a0b2f4147d50f04825d016f55
  6. - role: worker
  7.   image: kindest/node:v1.16.4@sha256:b91a2c2317a000f3a783489dfb755064177dbc3a0b2f4147d50f04825d016f55

Enable Feature Gates in Your Cluster

Feature gates are a set of key=value pairs that describe alpha or experimental features. In order to enable a gate you have to customize your kubeadm configuration, and it will depend on what gate and component you want to enable. An example kind config can be:

  1. kind: Cluster
  2. apiVersion: kind.x-k8s.io/v1alpha4
  3. featureGates:
  4.   FeatureGateName: true

Configure kind to use a proxy

If you are running kind in an environment that requires a proxy, you may need to configure kind to use it.

You can configure kind to use a proxy using one or more of the following environment variables (uppercase takes precedence):

  • HTTP_PROXY or http_proxy
  • HTTPS_PROXY or https_proxy
  • NO_PROXY or no_proxy

NOTE: If you set a proxy it would be passed along to everything in the kind nodes. kind will automatically append certain addresses into NO_PROXY before passing it to the nodes so that Kubernetes components connect to each other directly, but you may need to configure additional addresses depending on your usage.

Exporting Cluster Logs

kind has the ability to export all kind related logs for you to explore. To export all logs from the default cluster (context name kind):

  1. kind export logs
  2. Exported logs to: /tmp/396758314

Like all other commands, if you want to perform the action on a cluster with a different context name use the --name flag.

As you can see, kind placed all the logs for the cluster kind in a temporary directory. If you want to specify a location then simply add the path to the directory after the command:

  1. kind export logs ./somedir
  2. Exported logs to: ./somedir

The structure of the logs will look more or less like this:

  1. .
  2. ├── docker-info.txt
  3. └── kind-control-plane/
  4.     ├── containers
  5.     ├── docker.log
  6.     ├── inspect.json
  7.     ├── journal.log
  8.     ├── kubelet.log
  9.     ├── kubernetes-version.txt
  10.     └── pods/

The logs contain information about the Docker host, the containers running kind, the Kubernetes cluster itself, etc.