Kind Concepts: Difference between revisions
No edit summary |
|||
| (10 intermediate revisions by the same user not shown) | |||
| Line 18: | Line 18: | ||
While initializing the cluster, the initialization process will report what container provider it is using. | While initializing the cluster, the initialization process will report what container provider it is using. | ||
===<tt>KIND_EXPERIMENTAL_PROVIDER</tt>=== | ===<tt>KIND_EXPERIMENTAL_PROVIDER</tt>=== | ||
=Node= | =Node= | ||
| Line 35: | Line 24: | ||
The “node” image is a Docker image for running nested containers, systemd, and Kubernetes components. | The “node” image is a Docker image for running nested containers, systemd, and Kubernetes components. | ||
==Node Provider== | ==Node Provider== | ||
==<tt>containerd</tt> on Node== | ===<tt>containerd</tt> on Node=== | ||
<syntaxhighlight lang='bash'> | <syntaxhighlight lang='bash'> | ||
crictl images | crictl images | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Also see: {{Internal|crictl#Overview|<tt>crictl</tt>}} | |||
=Registry= | |||
==Registry Server== | |||
Also referred by the kind documentation as the "local registry". | |||
==Registry Container Provider== | |||
While initializing the cluster, the registry can use a different container provider, though usually there should be no good reason do so. | |||
=Image Handling= | |||
<font color=darkkhaki> | |||
Understand and document image pull and storage on a kind cluster. | |||
TODO | |||
* https://yunikorn.apache.org/docs/next/developer_guide/env_setup/#loading-your-images | |||
* https://iximiuz.com/en/posts/kubernetes-kind-load-docker-image/ | |||
Update [[Kind_Operations#Load_Images_into_a_Node|Load Images into a Node]]. | |||
</font> | |||
Latest revision as of 00:15, 8 December 2023
Internal
Overview
kind is a tool for running local Kubernetes clusters using Docker container as cluster nodes. As such, it needs a Docker installation to run and it is similar to Docker Desktop in that respect. kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
Cluster
A Kubernetes cluster can be created with kind create cluster. The "nodes" are implemented as Docker containers. Upon creation of a default cluster, it will report two nodes, "kind-control-plane" and "kind-worker". The corresponding Docker containers are:
CONTAINER ID IMAGE [...] NAMES 3108457ff1b6 [...]/kind:v1.27.3-3966ac76 kind-worker c90cb24cc040 [...]/kind:v1.27.3-3966ac76 kind-control-plane 2702defb0752 [...]/registry:2 kind-registry
Other cluster container providers can be used, and in that case, the nodes/containers will be reported differently.
Cluster Container Provider
While initializing the cluster, the initialization process will report what container provider it is using.
KIND_EXPERIMENTAL_PROVIDER
Node
"Node" Image
The “node” image is a Docker image for running nested containers, systemd, and Kubernetes components.
Node Provider
containerd on Node
crictl images
Also see:
Registry
Registry Server
Also referred by the kind documentation as the "local registry".
Registry Container Provider
While initializing the cluster, the registry can use a different container provider, though usually there should be no good reason do so.
Image Handling
Understand and document image pull and storage on a kind cluster. TODO
- https://yunikorn.apache.org/docs/next/developer_guide/env_setup/#loading-your-images
- https://iximiuz.com/en/posts/kubernetes-kind-load-docker-image/
Update Load Images into a Node.