What does Kubernetes teach The Hard Way?
Kubernetes The Hard Way There are several articles about it: about the offer, about getting machines on ARM, about deploying a cluster on them.
My goal was to practice Linux troubleshooting and learn more about Kubernetes. Because by itself the hard way described in the repository by reference and in a dozen other tutorials that consider the nuances, this post does not contain instructions. It’s about whether there is any point in doing it.
For educational purposes, I slightly changed the conditions compared to those described in the instructions I found. Here they are:
I used Oracle Linux instead of my usual Debian/Ubuntu. Oracle Linux is based on a Red Hat distribution that has SELinux enabled by default and most network connections blocked.
The latest version of Kubernetes is v1.27.1, not v1.21.0, which is described in the repository.
The control node is on amd64, and the four workers are on ARM. Looking ahead, deployment on ARM did not bring the expected difficulties.
I also used Oracle Cloud for the first time, but their interface is similar to AWS, so it was easy to figure it out.
Encountered problems
Most of the problems I encountered were caused by the use of an unfamiliar distribution. Let’s start with the fact that SELinux, according to some principle that I have not fully clarified, simply blocks the launch of some binaries as services. Necessary change security context for these files.
Another story is setting up firewalld, which first blocks almost all connections. Moreover, all this is also blocked in the subnet settings in Oracle Cloud. Of course, you can simply allow all connections, but a more careful setting requires understanding what is talking to what and on which port. There were many such rules.
In the latest version of Kubernetes, some startup keys and manifest settings no longer work, but he himself screams about it, so this is not a problem. The instructions for v.1.21.0 work almost unchanged on v.1.27.1. The most non-obvious point was that kubelet and containerd must have the same cgroups driver. Everything worked for me only after I added the line cgroupDriver: "systemd" V /var/lib/kubelet/kubelet-config.yaml.
conclusions
So what does the passage of Kubernetes The Hard Way teach?
Firstly, that installing Kubernetes from binaries, except for educational purposes, makes no sense. Maintaining such a cluster will definitely be a pain. It is worth using at least kubeadm. But in general, after such an experience, you begin to especially appreciate managed kubernetes solutions.
Secondly, the educational meaning of such projects is very limited. Essentially, it boils down to getting a feel for the architecture of the cuber itself. After it, it is difficult to forget what the components are and how they interact with each other. But Kubernetes The Hard Way almost does not teach you how to administer a cluster, how to properly deploy applications, etc. and so on.
Thirdly, going through the hard way in unfamiliar conditions basically teaches you the features of these conditions, and not the features of the cuber itself. In other words, if you use Oracle Linux, then you will have to understand the specifics of this distribution, and not the features of the functioning of the Kuber components on it.
To sum it up: was it worth it? I think I got a little deeper understanding of Kubernetes, but the method chosen to achieve this is not the most successful. You could just repeat some sections course preparation for CKA certification.
At the same time, I practiced Linux troubleshooting on an unfamiliar distribution, and this was useful. Most of my time was spent on this. In this part, the project, perhaps, justified itself.
