How does this compare to k3s? https://rancher.com/docs/k3s/latest/en/
Kind is intended to be a development tool to run fully upstream clusters using kubeadm in Docker containers.
k3s is a custom distro that is oriented towards lightweight environments. The scope of k3s and kind are different (distro vs tool to run k8s in docker). There is another project called k3d (https://github.com/rancher/k3d) that more directly compares to kind. k3d will run k3s clusters in Docker. k3d creates clusters significantly faster and uses less mem/cpu resources than kind.
Non-Goals: Being “production workload ready” - kind is meant to be used:
for testing Kubernetes itself
for testing against Kubernetes (EG in CI on Travis, Circle, etc.)
for “local” clusters on developer machines
NOT to host workloads serving user traffic etc.
curl -sfL https://get.k3s.io | sh -
sudo kubectl get nodes
[0] - https://kind.sigs.k8s.io/docs/contributing/1.0-roadmap/#non-...
Which, you know, you were anyway.
Non-kubeadm bootstrapped clusters are snowflakes in my opinion. You will find many docs that will not work with k3s due to missing systemd. You also lose some flexibility. For example there is no way to change the container runtime cgroup driver.
KIND is designed for local use on your workstation. Cluster API is the project to use for production deployments. You can drive Cluster API with KIND for testing though!
k3s has full flexibility to change any k8s option or component, it merely defaults to settings to meet it's goals of being a simple, lightweight, and secure distro.
Exactly, this differs from every kubeadm bootstrapped cluster which uses systemd to run the kubelet, as well using common config locations and behavior.
> k3s has full flexibility to change any k8s option or component
Quick Example: How do you change the kubelet's cgroup-driver? This looks to be hard-coded into the k3s binaries.
https://github.com/rancher/k3s/blob/c79743d4c3d9f2d21b352ed7...
The major advantage of kind is you download a single binary, run one command and quickly have a functional, disposable cluster, anywhere that Docker runs.
perfectly fine running on rpi or production.