Over the past two years, deploying a conformant Kubernetes cluster has become even easier, thanks to the efforts of the Cluster Lifecycle Special Interest Group (SIG) and its kubeadm tool. But if you've used kubeadm on a freshly provisioned machine, you know there is a considerable set of tasks you have to complete prior to running kubeadm:

1. Install your choice of container runtime
2. Configure container runtime storage
3. Install the Container Network Interface (CNI) binaries
4. Install kubelet dependencies
5. Configure control groups driver for kubelet
6. Configure kernel parameters
7. Call kubeadm (the hero)

To take you from zero to hero (see what I did there?), the team at Platform9 has built nodeadm, an unassuming but jovial sidekick to kubeadm. Like kubeadm, it's open-source and focused on making it easy to manage the Kubernetes lifecycle. You can use it in concert with tools like etcdadm and cctl as part of our Klusterkit, together with your own automation software, or interactively.

What Does nodeadm Do?

In its current release, nodeadm installs and configures most of the dependencies (i.e. kubelet and kubelet systemd file, kubeadm binary, CNI binaries, all container images including Kubernetes, keepalived image and systemd file, etcd container image and related configuration files), configures kernel parameters, and calls kubeadm on your behalf. In the near term, it will also install and configure the most popular container runtimes.

Nodeadm makes it easy to use kubeadm in an air-gapped environment. You can use nodeadm to only download dependencies to its cache, but not install them. Afterward, you can snapshot the file system to create a machine image, or just save the cache. Then you can boot your machine from the image, or copy the cache to the machine and run nodeadm to configure and install everything; it will find everything necessary in its local cache.

If you have a use case that nodeadm does not meet, please let us know!

Why Use nodeadm?

"Why do I need it?" you might ask. "I created my own solution." That's true, but then so does everyone else. The benefits of standardizing on common, open-source tooling are many: more bug reports, more fixes for said bugs, and keeping current with best practices. Platform9 and other contributors are working to improve nodeadm, and we welcome your feedback and PRs!

"Bah. Just write a shell script." And you would be right, as long as everything goes right. If you want to handle transient network problems, bad configuration values, and many other potential error conditions in a shell script, be my guest. And a robust shell script is no easier to maintain and test than any other shell script. On the other hand, nodeadm is written in Go. Though Go might not be everybody's favorite language, it is the lingua franca of the Kubernetes community. We believe that will make it easier for the community to understand and contribute to the code.

"I'll use [your favorite configuration management tool]." If that suits you, go ahead! Like many Kubernetes administrators, we too have been down that road. But we found that a single, self-sufficient binary is easier to use than either master-agent or agentless tools.

"My system package manager takes care of some of these." It's true! The Cluster Lifecycle SIG has done a superb job maintaining rpm and deb packages, ensuring that dependencies and CNI binaries are installed together with kubelet. But that's cold comfort if you use a distribution that doesn't support rpm or deb packages. By comparison, nodeadm can work with a system package manager, but does not require one.

Take It for A Spin!

Re-use and consistency of configuration and code is key to accelerate your Kubernetes deployments and on-going operations. We invite you to grab nodeadm from Github and see if it meets your needs. And of course, let us know if you have any feedback!