10 ms·

KIND uses kubeadm which is the upstream standard for bootstrapping. It also supports multi masters and even launches a haproxy load balancer for kube-apiserver!

KIND uses kubeadm which is the upstream standard for bootstrapping. It also supports multi masters and even launches a haproxy load balancer for kube-apiserver! K3S uses it's own bootstrapping, as well as non upstream binaries. It also replaces etcd with it's own shim. 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!

darren0 7y ago
k3s has no direct relationship to systemd, I'm not sure what things not working you are referring too. 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.
- moondev 7y ago
  > k3s has no direct relationship to systemd 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/c79743d4c3d9f2d21b352ed78a5d64e0a8e00263/pkg/daemons/agent/agent.go#L68 https://github.com/rancher/k3s/blob/c79743d4c3d9f2d21b352ed7...