Hey! Welcome to another post, I'm glad you're here πŸ‘‹

Kind, also known as Kubernetes-in-Docker is a popular was of running a local development cluster. This year, Podman support was enabled for Kind.

I've been wanting to run Kind on Fedora for a long while, since it had become the go-to for bringing up Kubernetes locally.

Since not being about to use it natively, Minikube has been my preferred option for bringing up Kubernetes locally since it provides a nice level of isolation and QEMU+KVM is supported on Fedora.

However, there are quite a few things that Kind can do, being on the host system, that Minikube can't do (aside from host-system IP tables modifications such as via minikube tunnel). I now use both Kind and Minikube where I see appropriate.

Current problems πŸ”₯

The latest versions of Fedora use cgroupsv2 by default. Docker doesn't work as a result.
The good news is, there has been discussion around cgroupsv2 support in runc (a dependency of Docker).

NFTables is not supported with Kind, only IPTables is. NFTables is also default on Fedora. I ran into some DNS issues in-cluster.

Instructions πŸ“‘

Grab yourself a fresh copy of Kind using the instructions in the docs, here.
I have Kind as a binary in the $HOME/bin. You can do the same with:

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.9.0/kind-linux-amd64
chmod +x ./kind
mv ./kind $HOME/bin/kind

Once you've got a Kind binary locally, you'll need to follow these next steps.

# change the user ownership of the binary to root
chown root $HOME/bin/kind

# add a setuid for the user owner and disallow non-user / non-group members to execute
chmod u+s,o-rx $HOME/bin/kind

A setuid on a program in Linux makes it run as the user that owns it. This can have it's security drawbacks, so it should be used sparingly.

Finally, you'll need to set firewalld to use IPTables instead of NFTables. This can be done with the following command:

sed -i /etc/firewalld/firewalld.conf 's/FirewallBackend=.*/FirewallBackend=iptables/'
systemctl restart firewalld

As described on the Kind known-issues page.

Using Kind πŸ“¦

To configure Kind to use Podman, the final step is to set export KIND_EXPERIMENTAL_PROVIDER=podman in you're environment (and $HOME/.bashrc for persistence).

Creating a cluster ☸️

A familiar command can now be issued to bring up a Kind cluster:

🐚 kind create cluster
enabling experimental podman provider
Creating cluster "kind" ...
 βœ“ Ensuring node image (kindest/node:v1.19.1) πŸ–Ό 
 βœ“ Preparing nodes πŸ“¦  
 βœ“ Writing configuration πŸ“œ 
 βœ“ Starting control-plane πŸ•ΉοΈ 
 βœ“ Installing CNI πŸ”Œ 
 βœ“ Installing StorageClass πŸ’Ύ 
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Have a nice day! πŸ‘‹

and that's it, now you're away!

Final notes πŸ“

Usage of Fedora 🐧

In case you missed it here's why I currently like to run Fedora Silverblue. If you want to avoid this whole article, you may wish to either use cgroupsv1 or switch to a different OS which uses cgroupsv1 out of the box.

Security, etc... πŸ”

Of course as discussed, this way of doing things does require running everything as root due to the setuid and the lack of rootless implementation currently. I'm looking forward to the future of rootless container orchestration systems + container runtimes beening common in production. I see it as a great stride for security!
Until then, I hope this has been useful as it was for me to learn.

Credits πŸ™Œ

Special shout out and thanks to:
- hh for pairing on this mini project.
- Kind maintainers and contributors for enabling these capabilities

Thank you!

Update (December 27th 2020): it appears that there's a break of compatibility with Kind version v0.9.0 and Podman version v2.2.1, this will be likely fixed in the next release of Podman (PR).