Container Runtimes on Flatcar Container Linux

Getting started with Docker

Mon, 01 Jan 0001 00:00:00 +0000

Docker is an open-source project that makes creating and managing Linux containers really easy. Containers are like extremely lightweight VMs – they allow code to run in isolation from other containers but safely share the machine’s resources, all without the overhead of a hypervisor.

Docker containers can boot extremely fast (in milliseconds!) which gives you unprecedented flexibility in managing load across your cluster. For example, instead of running chef on each of your VMs, it’s faster and more reliable to have your build system create a container and launch it on the appropriate number of Flatcar Container Linux hosts. This guide will show you how to launch a container, install some software on it, commit that container, and optionally launch it on another Flatcar Container Linux machine. Before starting, make sure you’ve got at least one Flatcar Container Linux machine up and running — try it on Amazon EC2 or locally with Vagrant .

Getting started with Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

One of the Flatcar purposes is to run container workloads, this term is quite generic: it goes from running a single Docker container to operate a Kubernetes cluster.

This documentation will cover preliminary aspects of operating Kubernetes cluster based on Flatcar.

Supported Kubernetes version

A Kubernetes basic scenario (deploy a simple Nginx) is being tested on Flatcar accross the channels and various CNIs, it mainly ensures that Kubernetes can be correctly installed and can operate in a simple way.

Incus

Mon, 01 Jan 0001 00:00:00 +0000

While Flatcar proposes Containerd and Docker by default, Incus can be used to run containers. The goal of this guide is not to re-write the Incus documentation but to give key aspects of Incus usage on Flatcar.

Installing Incus

Incus is provided as an official Systemd sysext Flatcar extension. To install it automatically at boot:

---
# config.yaml
# butane < config.yaml > config.json
variant: flatcar
version: 1.1.0
storage:
  files:
    - path: /etc/subuid
      append:
        - inline: |
            root:1065536:65536
    - path: /etc/subgid
      append:
        - inline: |
            root:1065536:65536
    - path: /etc/flatcar/enabled-sysext.conf
      contents:
        inline: |
          incus

Once the instance booted, incus command is available and incus.{socket,service} are started. Note: the core user is added by default to the incus-admin group.

High Availability Kubernetes

Thu, 13 Feb 2025 16:30:38 -0500

After you have created a kubernetes cluster using the getting started guide , we can take a look at a more complex example that involves a highly available control plane nodes and dedicated worker nodes. The result will be similar to a Typhoon cluster, but this version will be a little more “vanilla” and will run on libvirt VMs, which is not mentioned in their documentation as of time of writing.

Architecture

This documentation will walk you through creating 5 VMs with the following properties:

Switching to Unified Cgroups

Mon, 01 Jan 0001 00:00:00 +0000

Beginning with Flatcar version 2969.0.0, Flatcar Linux has migrated to the unified cgroup hierarchy (aka cgroup v2). Much of the container ecosystem has already moved to default to cgroup v2. Cgroup v2 brings exciting new features in areas such as eBPF and rootless containers.

Flatcar nodes deployed prior to this change will be kept on cgroups v1 (legacy hierarchy) and will require manual migration. During an update from an older Flatcar version, a post update script does two things:

Customizing Docker

Mon, 01 Jan 0001 00:00:00 +0000

The Docker systemd unit can be customized by overriding the unit that ships with the default Flatcar Container Linux settings or through a drop-in unit. Common use-cases for doing this are covered below.

For switching to using containerd with Kubernetes, there is an extra guide .

Use a custom containerd configuration

The default configuration under /usr/share/containerd/config.toml can’t be changed but you can copy it to /etc/containerd/config.toml and modify it.

Create a /etc/systemd/system/containerd.service.d/10-use-custom-config.conf unit drop-in file to select the new configuration:

Authenticating to Container Registries

Mon, 01 Jan 0001 00:00:00 +0000

Many container image registries require authentication. This document explains how to configure container management software like Docker, Kubernetes, rkt, and Mesos to authenticate with and pull containers from registries like Quay and Docker Hub .

Using a Quay robot for registry auth

The recommended way to authenticate container manager software with quay.io is via a Quay Robot . The robot account acts as an authentication token with some nice features, including:

Readymade repository authentication configuration files
Credentials are limited to specific repositories
Choose from read, write, or admin privileges
Token regeneration