Automation Is Strange

What is a bit more adventurous is the way k3OS finds, or should find according to the developers, its way onto your hard disk. The k3OS makers do not use a powerful automation framework like Preseedint, Anaconda, or AutoYaST.

Instead, the command line that accompanies the kernel at startup defines the type of installation desired. Moreover, k3OS can install itself directly from a running Linux system; to do this, it changes the partitioning of the disk and then the GRUB configuration. However, the developers also provide for a legacy installation with an ISO file.

The admin will search in vain for tools to configure IP addresses and similar settings. A host running k3OS gets all these details automatically from the appropriate operator in K3s. As soon as the kubelet agent is running on the host, it learns how to do the configuration. In the usual style for clouds, protocols such as DHCP are also used for this purpose.

Basically, the following is true: k3OS (Figure 4) is so closely interconnected with and designed for K3s that it is hardly worthwhile taking a closer look at the system without being interested in K3s. In this case, you get a largely non-extendable basic Linux. Even for use with other Kubernetes distributions, K3s is not a useful choice because it does not adopt part of their standard configuration. Conversely, if you do want to use K3s, you should definitely take a closer look at k3OS.

Figure 4: k3OS is specifically designed to meet the needs of Rancher's Kubernetes distribution K3s. © Rancher

Red Hats on a Flatcar

The second microdistribution for review is not a new project, but rather an old acquaintance. Red Hat has a proven track record of buying open source companies and making them big. Ceph, for example, has become more or less a standard solution for software-defined storage since its takeover by Red Hat.

The manufacturer might have had a similarly lucky hand with CoreOS, which has belonged to Red Hat since 2018. The CoreOS microdistribution was considered a pioneer in the entire industry. The OS is the work of a company with the same name, which also invented a number of other components that are practically indispensable in the container context today. Examples include the Etcd cluster consensus algorithm, Flannel, and Prometheus.

From Red Hat's point of view, it was logical – almost necessary – to buy CoreOS. On the one hand, Red Hat was able to secure its open source properties, on the other hand, the CoreOS products fit perfectly into Red Hat's Kubernetes portfolio (which it had just turned on its head with OpenShift). Red Hat did what was expected immediately after the acquisition: It made CoreOS the centerpiece of new products. CoreOS became Red Hat CoreOS (RHCOS) and Fedora CoreOS.

Noses Turned Up

In the course of development, CoreOS changed continuously; in the meantime, it was no longer compatible with the original version in many ways. Therefore, Red Hat officially discontinued the old standalone version of CoreOS; by the end of October 2020, at the latest, everything will be done and dusted. However, not everyone is happy: Critics complain about Red Hat having too much influence and fear that CoreOS will not be usable without Red Hat's blessing.

Add to that the frustration of having to switch to a new OS and adapt existing workloads. People who already have complete lifecycle management for their container fleet do not see any value in the change. The same is true for third-party vendors who develop applications for CoreOS and who would also have to put in additional work because of Red Hat's move, without seeing any technical reasons for doing so.

Berlin-based consulting and development company Kinvolk went on the offensive and forged CoreOS from the last stable version. This project is known as Flatcar Linux. Kinvolk promises to maintain Flatcar as an unofficial successor to CoreOS for the foreseeable future and to keep it compatible with CoreOS. Also important for corporate customers is that the company offers commercial support for the system.