Introduction ¶

Sometimes you need Kubernetes locally for quick testing.

1. Checking out a custom Helm chart
2. Asking kubectl explain something
3. Checking settings

Starting to look for some cluster on first available project, which is not good because it can break something accidentally. It’s not convenient to do something. Turns out there are many different lightweight and fast installers of Kubernetes. This may not be all of them, but those I either tried or passed by. They work a bit differently.

1. Minikube - one of the oldest, so to say. We met that standard installation kube-prometheus-stack on it simply didn’t start, and on the next one - with it.
2. k3s - one of three engines from Rancher. Great thing, used and using them for small projects at work. It’s also two personal clusters exactly on k3s, but it’s not vanilla, everything is put together in a single binary. It’s both good and bad. Very lightweight and easy to install, but I ended up with Wireguard VPN rule issues with IPTables myself. I had to change Wireguard FwMark to 0x8000 and everything worked.
3. rke - another one of three engines. First one from Rancher. It’s very good, especially because there is a Terraform Module - great. I’ve already been more similar to vanilla installation.
4. rke2 - rke + k3s. Everything is put together in one binary, but apiserver, scheduler etc. are still seen as separate pods. I tried it, and it was a shame that there was no support from Terraform like with rke. It didn’t impress me, practically speaking, because it was less stable than k3s or maybe my hands were just crooked.
5. Microk8s - from Canonical, haven’t tried.
6. k0s - same as k3s, but community is smaller and documentation is worse, and that’s… good.
7. kind - the highlight of today’s program.

kind ¶

Why I want to tell you about it? It’s the most vanilla way to get Kubernetes locally. There are many advantages.

1. You can throw in a config
2. Creates Kubernetes in Docker
3. You can create more than one node!
4. Uses vanilla kubeadm!
5. All configurations, paths, and formats - standard kubeadm!
6. It doesn’t mess with iptables on the host

There are some downsides.

1. Control plane eats up 900 MiB RAM at a time
2. You need to throw out ports from nodes on the host

Here’s an example configuration of kind:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraMounts:
  - hostPath: /home/bzm/projects/kind/
    containerPath: /host
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        seccomp-default: "true"
    apiServer:
      extraArgs:
        enable-admission-plugins: NodeRestriction    
- role: worker
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    listenAddress: "127.0.0.1"
  - containerPort: 443
    hostPort: 443
    listenAddress: "127.0.0.1"

So, you can put a bunch of nodes on one computer and everything is in containers. Configurations and settings are all like the official documentation. You need to try out some keys for api-server - easy. You need to refine something about security - easy. I really liked it.