Each node is a Docker container, but the version of Kubernetes running inside it is vanilla Kubeadm, so it's quite representative of what "real" clusters would look like.
The great thing about it is you can spin up a cluster in < 2 mins locally to try things out, then it's a single command to delete.
Note that I maintain a parallel configuration that runs a multi-node cluster on Vagrant for local development [1] as well as a docker environment built for CI purposes[2] using almost all the same images, with the same Ansible playbooks to configure them all across platforms.
[1] https://github.com/geerlingguy/raspberry-pi-dramble/tree/mas...
[2] https://github.com/geerlingguy/raspberry-pi-dramble/tree/mas...
BTW I think your ansible book is great, really helped me get to grips with it.
Thanks for sharing. I fully agree with the fun, and the really-hard-way part.
However, if we ignore that part for the moment, would you think having an R-Pi cluster handy is worth it for training/sandboxing/testing with the aim of applying the skills in your day job?
Are there any advantages to having access to your own R-Pi kubernetes cluster, despite having stuff like Kind and Minikube available online?
perfectly fine running on rpi or production.
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.
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...
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.