kind
Table of contents
Kubernetes IN Docker - local clusters for testing Kubernetes
kind is a tool designed for running local Kubernetes clusters by utilizing Docker containers as nodes. . Primarily designed for testing Kubernetes, its flexibility makes it suitable for local development or integrating with Continuous Integration (CI) pipelines.
Please check official Documentation for more in-depth things.
Information
Source | Tracker | VCS | QA | Bugs
- Version: 0.26.0-1
- Architecture: any
- Standards-Version: 4.7.0
- Maintainer: Debian Kubernetes Packaging Team (DMD)
Releases
- 0.26.0-1 (sid | unstable )
If you are using an unlisted debian version probably that means this package it’s not available.
Installation
apt install kind
Dependencies
apt install docker.io
# or
apt install podman
Completion
Completions will be installed for bash, zsh and fish shells.
Usage
Once you have kind installed you can start creating your cluster.
Creating a Cluster
Is as simple as:
kind create cluster
This will bootstrap a Kubernetes cluster using a pre-built node image. Prebuilt images are hosted at kindest/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.
Multi-node clusters and other advanced features may be configured with a config file, for more usage see the user guide or run kind [command] --help
The kind can auto-detect the docker, podman, or nerdctl installed and choose the available one. If you want to turn off the auto-detect, use the environment variable KIND_EXPERIMENTAL_PROVIDER=docker, KIND_EXPERIMENTAL_PROVIDER=podman or KIND_EXPERIMENTAL_PROVIDER=nerdctl to select the runtime.
Interacting With Your Cluster
After creating a cluster, you can use kubectl to interact with it by using the configuration file generated by kind.
NOTE:
kinddoes not requirekubectl, but you will not be able to perform some of the examples in our docs without it. To installkubectlsee the upstream kubectl installation docs.
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.
kind get clusters
In order to interact with a specific cluster, you only need to specify the cluster name as a context in kubectl:
kubectl cluster-info --context kind-kind
Deleting a Cluster
If you created a cluster with kind create cluster then deleting is equally simple:
kind delete cluster
If the flag --name is not specified, kind will use the default cluster context name kind and delete that cluster.