Managing Releases on Flatcar Container Linux

Switching release channels

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

Flatcar Container Linux is designed to be updated automatically with different schedules per channel. You can disable this feature , although we don’t recommend it. Read the release notes for specific features, bug fixes, and changes. A new major release always starts in the Alpha channel - which is for developers - where it passes multiple feature and bug fix iterations. Roughly every second major Alpha release is promoted to the Beta channel; the promotion is based on stability and on feature completeness. The Beta channel is for user consumption, so operators can validate compatibility with user workloads. In Beta, the release passes additional iterations and eventually fully stabilises, receiving bug fixes addressing issues with user workloads. Roughly every second major Beta release is promoted to Stable. Thus, the Stable channel gets no brand new major releases but instead gets the bug fix release of a new major release. It then continues to get bug fix releases. Any Stable major version remains supported until a new major Stable version is released. We generally recommend operators to follow releases in the Stable channel, with a few nodes on Beta for workload validation. Beta is generally considered ready for production. However, in edge cases new releases may show issues with certain user workloads. The Beta channel is an opportunity to validate early and to give feedback, so potential issues are fixed before they hit Stable. For low-maintenance scenarios there is the LTS channel which only gets bug fix releases. New major releases come out around once per year, marking a new LTS stream, and there is an overlap where the old stream still gets critical security updates.

Update and reboot strategies

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

The overarching goal of Flatcar Container Linux is to secure the Internet’s backend infrastructure. We believe that automatically updating the operating system is one of the best tools to achieve this goal.

We realize that each Flatcar Container Linux cluster has a unique tolerance for risk and the operational needs of your applications are complex. In order to meet everyone’s needs, there are different update/reboot strategies that we have developed.

Verify Flatcar Container Linux images with GPG

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

Kinvolk publishes new Flatcar Container Linux images for each release across a variety of platforms and hosting providers. Each channel has its own set of images ( stable , beta , alpha ) that are posted to our storage site. Along with each image, a signature is generated from the Flatcar Container Linux Image Signing Key and posted.

After downloading your image, you should verify it with gpg tool. First, download the image signing key:

Flatcar Container Linux update.conf specification

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

Flatcar Container Linux uses update_engine to check and fetch new updates from the Nebraska Update Service .

Location

The client-side configuration of these updates is stored in /etc/flatcar/update.conf. (there is a legacy symlink of /etc/coreos -> /etc/flatcar for compatibility with third-party integrations). This file is in the user writable partition by default.

Next order of client-side configurations that are checked are:

/usr/share/flatcar/update.conf
- Generated at build time of the image/payload build
- will typically contain:
  - SERVER=
  - GROUP=
/usr/share/flatcar/release
- Generated at build time of the image/payload build
- will typically contain:
  - FLATCAR_RELEASE_VERSION=
  - FLATCAR_RELEASE_BOARD=
  - FLATCAR_RELEASE_APPID=

Fields

Default installs of Flatcar will likely not need custom settings, and an empty or non-existing /etc/flatcar/update.conf file is sufficient.