Microsoft is not just the Windows company. It now supports several Linux distributions alongside its own operating systems. It’s important to remember that these are not general-purpose Linux distributions like Ubuntu or Red Hat.
Instead, they target specific use cases:
- SoNIC for cloud networking equipment,
- SphereOS for secure industrial Internet of Things equipment
- CBL-Mariner as a host for its Azure Stack edge systems and part of its Windows Subsystem for Linux.
A year ago, Microsoft bought German Linux provider Kinvolk to support the use of containers in Azure, especially on cloud platforms such as Kubernetes. Kinvolk is home to the popular container-optimized Flatcar Linux platform, as well as Lokomotive, a secure Linux-based Kubernetes platform. Kinvolk took over the baton for releasing a Linux version for containers after Red Hat acquired CoreOS and merged its stack with Fedora, reducing its effectiveness for platforms such as Kubernetes.
Adding Kinvolk to Microsoft and Azure
By acquiring Kinvolk, Microsoft acknowledged its importance to Azure and committed to supporting the Flatcar community development project, intending to learn how the Kinvolk team works. It’s interesting to hear Microsoft say it wants to learn how to work well with open source, since it’s clear the company is making a major shift toward open-source methods. It may never open-source Windows or Office, but it is using open source as a way to build and manage new tools and platforms.
It’s clear that Microsoft initially saw Flatcar as a replacement for CoreOS in Azure. A year before the acquisition, the company recommended that customers migrate to Flatcar before CoreOS reached end of life in May 2020 year. The migration involved changing the Azure deployment images in the Kubernetes or container repository. In addition, CoreOS systems can be switched to Flatcar using a simple script to download and run the update tools. This lets existing nodes keep running without a full redeployment.
Once the new OS is up and running, you can take the time to build and test new images before redeploying your container environment.
What is Flatcar Container Linux?
If you haven’t seen Flatcar before, it’s a minimal Linux distribution designed to run containers and nothing else. Flatcar is built on many of the core concepts behind cloud application development, providing immutable infrastructure that is redeployed with each new build of your code.
You don’t want your OS changing under your application, even if it only hosts your application’s containers, so Flatcar is configured before deployment with a read-only system partition. It can be configured to automatically install security patches, although you may prefer to make updates part of your build and deployment process.
Kinvolk provides tools for managing the update process, controlling which instances can be updated, when updates can run, and how often they should be applied. Having a minimal Linux with a locked-down filesystem running in the cloud makes a lot of sense. Azure provides isolation between tenants running on the same hardware, but having an immutable container host significantly reduces security risks, keeping the attack surface small and ensuring that many classes of attacks won’t run on the container host. You can find Flatcar in the Azure Marketplace, with versions for three different update channels: stable, beta, and alpha.
Most production systems should use the stable channel, while beta and alpha are recommended for testing and development. You may prefer to run beta and alpha directly from Kinvolk in your internal systems rather than using the Azure Marketplace.
Getting started with Flatcar in Azure
Kinvolk provides Azure CLI scripts for installing Flatcar. You can choose a version by specifying the SKU and version before creating the URN for the image you want to install. It uses the format
Kinvolk supports both 1-generation and 2-generation hypervisor images, with the 1-generation image used by default. If you want to use gen 2, add -gen2 to the channel name in the SKU and URN sections of the installation scripts. Alternatively, you can download your chosen Azure-ready Flatcar image directly and place it in an Azure storage account. Kinvolk provides a script that requires a resource group name and a storage account.
In practice, however, using the Azure Marketplace is the best option, since the Flatcar image is already in Azure and you won’t incur storage costs. Although AKS (Azure Kubernetes Service) uses Ubuntu as its base OS, you can still take advantage of Flatcar in Azure by using your own Kubernetes installation or the Azure version of the Cluster API Provider to run your own managed Kubernetes instance.
The Kinvolk website has instructions for using AKS Engine, and although it is possible to use the standalone version of AKS, it is outdated and no longer updated. Configuring and running Flatcar Once you have installed the Flatcar image, you need to configure it with a tool called Ignition, which injects a JSON configuration file into the Flatcar user environment before the first boot. Once booted, Flatcar’s read-only filesystem means you can’t make changes.
Configuration files are written using YAML, creating a Container Linux Config. This sets the basic configuration of the container host, defining which service containers it loads, how they run, and how the host responds to a container failure. For example, you can reload the latest container images at startup, remove old versions, shut down gracefully, and restart failed containers after a set amount of time.
Kinvolk provides a tool for converting CLC YAML to JSON for use with Ignition. Once you’ve created the JSON, you can inject it into Flatcar using the Azure CLI as custom data when configuring the container. Azure CLI can add users and SSH keys to images if you need to log into them for development and debugging. Production instances won’t need this, as it increases security risks. The team recommends testing a Flatcar virtual machine on a development machine before moving to production. Although you can use Hyper-V, most of the documentation uses open-source QEMU, so you may prefer to test on a Linux system.
This approach lets you use Kinvolk’s own test images by installing the Ignition JSON file on first boot. If you’re experimenting with different containers and configurations, just delete the virtual machine each time you make changes and use another copy of the Flatcar image.
Flatcar isn’t just for Azure. It works across all major public clouds, as well as edge and private clouds. Since the same configuration files work across all systems, Flatcar is an interesting option for hybrid cloud and edge deployments, where you can develop workloads once and deliver them to multiple targets with minimal changes.
There’s also support for tools such as Terraform, so you can make Flatcar part of an “infrastructure as code” platform, separating container node management from applications. Over the past few years, Microsoft has learned a lot about managing open-source acquisitions. Like Deis Labs, Kinvolk remains an almost independent organization. This allows it to continue supporting its open-source community while building and running its own experiments.
Meanwhile, Microsoft can learn from Flatcar as it expands its internal Linux offerings and adds more open-source projects to its portfolio.
