First impressions with the new kubeadm

Kubeadm just graduated to general availability (GA) with the new Kubernetes 1.13 release. Let’s find out what’s new and take it for a spin!

First of all, if you have been using kubeadm before without relying on alpha features like the configuration file, the new version will probably feel quite familiar. You can still do kubeadm init just as before. In fact, you would probably not notice the difference. The flow for a single master cluster is still the same: init, install network add-on and then join workers. So what’s new?

The first thing I ran into was a new pre-flight check. If you have been using kubeadm for experimenting using vagrant boxes, you may run into it as well. It checks that the number of CPUs available is 2 or more. This wasn’t a hard requirement before. In any case, the solution is simple if you are using vagrant. Just change the number of CPUs that the VMs have. For Virtualbox and Libvirt you can do it like this:

config.vm.provider :virtualbox do |v|
    v.cpus = 2
end

config.vm.provider :libvirt do |libvirt|
    libvirt.cpus = 2
end

You can also disable the check if you want to. Just remember that it’s there for a reason. That said, I didn’t notice any problems when I upgraded my old test environment running on single core VMs.

New features and improvements

The configuration file format has changed and is now in beta. You can find details about the new format here. And just as with the previous changes to this format, you can easily migrate from the old v1alpha3 to v1beta1 with the migrate command: kubeadm config migrate. A notable addition in the config file is the timeoutForControlPlane setting, which should make it easier to get Kubernetes running on slower platforms such as the Raspberry Pi.

It is nice to see that the configuration file is stabilizing and that it is now considered beta. If you have not been using kubeadm previously due to missing configuration options and the configuration file being in alpha state, I encourage you to try the new beta format. The configuration file is an essential part of kubeadm for more complex setups since it enables much more advanced configuration options.

Another update that should allow kubeadm to be used in more ways is the graduation of the phase commands. Running the initializing phases separately is no longer hidden behind the alpha command but considered stable. The available phases are as follows:

$ kubeadm init phase --help
use this command to invoke single phase of the init workflow

Usage:
  kubeadm init phase [command]

Available Commands:
  addon              Installs required addons for passing Conformance tests
  bootstrap-token    Generates bootstrap tokens used to join a node to a cluster
  certs              Certificate generation
  control-plane      Generates all static Pod manifest files necessary to establish the control plane
  etcd               Generates static Pod manifest file for local etcd.
  kubeconfig         Generates all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
  kubelet-start      Writes kubelet settings and (re)starts the kubelet
  mark-control-plane Mark a node as a control-plane
  preflight          Run master pre-flight checks
  upload-config      Uploads the kubeadm and kubelet configuration to a ConfigMap

These phases allow you to initialize your cluster in a more controlled way instead of all in one go. You could even use kubeadm only for a part of the initialization and do the rest manually.

The HA setup has been improved but is still a bit tedious. Kubeadm will now automatically add a new etcd member in local etcd mode when adding a new control plan node with the join command. You still have to make sure that the needed certificates are available though.

When you are finished experimenting, or want to start over, you may use the kubeadm reset command. This command now features an improved message telling you that it doesn’t clear the IP tables for you. It also suggests how you can clear the tables if you so wish.

The above is of course just a highlight of all the changes in kubeadm 1.13. If you want to get all the details, check out the release notes over here.

Conclusion

Kubeadm provides a nice and easy way to setup a Kubernetes cluster. It has already become the go-to tool for many and with its new GA status I’m hopeful that we will see the adoption increase even more. Remember that not all features it provides are considered GA yet, and be mindful about this. We will surely see changes to some features yet, but the core is there and can be trusted for setting up clusters following best practices.

If you are relying on custom installation scripts or tools not based on kubeadm you should really consider switching and at least try out kubeadm. Consider that the explicit goal of kubeadm is to allow higher level tools to easily create conformant clusters.

Follow us on Linkedin for more Kubernetes news and guides!