Skip to content

Ankur Pandita

Upstream Kubernetes on Flatcar Linux using Rafay

This blog is Part 3 of our series on Flatcar Linux and Kubernetes

  • In Part 1, we introduced Flatcar Linux and why it is a great fit for Kubernetes.
  • In Part 2, we covered how to install a Flatcar instance locally.
  • In this Part 3, we focus on deploying and managing Upstream Kubernetes on Flatcar Linux using Rafay MKS.

Our upcoming February release will introduce a number of new features and enhancements.We will write about these in separate blogs. This blog is focused on support for Upstream Kubernetes based on Rafay MKS on nodes running Flatcar Linux. The Rafay platform enables users to seamlessly provision new clusters and perform in-place upgrades of Kubernetes clusters, simplifying lifecycle management.

For more details on Flatcar Linux, visit the official Flatcar Linux website.

Flatcar Logo


Provision Cluster

Rafay MKS based Upstream Kubernetes clusters can be configured and provisioned on Flatcar Linux using all the supported interfaces i.e.

  • Web Console
  • API
  • CLI (declarative spec)
  • GitOps
  • Rafay Terraform/OpenTofu Provider

In this blog, we will demonstrate this using the web console and the Rafay RCTL CLI.

Install Flatcar-Part 2

This is in continuation of our first blog where we introduced Flatcar Linux. In part 2, we will show how you can install a Flatcar Container Linux instance locally on your laptop so that you can learn more about it. This guide will take you through the steps to install it, boot the instance, SSH into it. Finally, we will explore and validate some of Flatcar's critical features that we reviewed in the first blog.


Boot Flatcar Instance Locally

Follow the steps below to download, set up, and run a Flatcar instance locally. In our example, we are installing this on a M1 MacBook Pro.

Step 1: Install QEMU

First, install QEMU on your system. Follow the instructions provided here.

Step 2: Download the QEMU Script and Flatcar Image

Get the QEMU helper script and the latest stable Flatcar image

wget https://stable.release.flatcar-linux.net/amd64-usr/current/flatcar_production_qemu.sh
wget https://stable.release.flatcar-linux.net/amd64-usr/current/flatcar_production_qemu_image.img.bz2

Step 3: Extract the Image

Decompress the downloaded image

bzip2 --decompress --keep flatcar_production_qemu_image.img.bz2

Step 4: Make the Script Executable

Set execution permissions for the QEMU helper script:

chmod +x flatcar_production_qemu.sh

Step 5: Create/Start the Flatcar Instance

Use the following command to start the Flatcar instance with 4 CPUs and 4GB memory in console mode:

./flatcar_production_qemu.sh -M 4096 -- -smp 4 -display curses

Access Flatcar Instance via SSH

Once the Flatcar instance is running, set up your SSH configuration to connect to it. Update your SSH config file as follows:

# ~/.ssh/config
Host flatcar
        User core
        StrictHostKeyChecking no
        UserKnownHostsFile /dev/null
        HostName 127.0.0.1
        Port 2222

You can then SSH into the instance using the following command

ssh flatcar

After you successfully SSH into the instance, you can run the following command to verify the system's firmware and kernel details:

hostnamectl

You should see something like the image below.

hostnamectl

Flatcar Versioning

In the image above, notice that the Flatcar version is 4081.2.1. Here’s how the versioning system works for Flatcar Linux.

  • 4081: The number of days since the first CoreOS release. (Flatcar is a fork of CoreOS)
  • 2: Minor number representing the promotion level:

    • 0 = Alpha
    • 1 = Beta
    • 2 = Stable
    • 3 = LTS
  • 1: Patch level, indicating small updates like kernel or software fixes.

In our version (4081.2.1), 2 represents a stable release on its first patch.


Explore Flatcar's Key Features

Now that we have installed Flatcar Linux, let us test and validate some of the interesting features of Flatcar.

1. No Package Manager and Immutable File System

In Linux, the /usr directory is used to store user system resources. It contains the majority of the system’s software and programs i.e. binaries, libraries, documentation, and other files shared by all users of the system. Flatcar Linux makes the /usr directory read-only as part of its design philosophy to ensure system immutability and reliability. By focusing on immutability and containerization, Flatcar Linux achieves a stable, predictable, and secure platform, which is why /usr is deliberately set to read-only.

Let's test whether Flatcar Linux's /usr folder is immutable

  • SSH into your Flatcar instance
  • Run commands like apt, yum, or dnf

You will notice they are unavailable. Additionally, any attempt to write to the /usr/ directory to see that the file system is immutable. For example, let's try to create a new file in the /usr directory using the "touch" command.

sudo touch /usr/test 

Below is an example screenshot showing this behavior:

no pkg manager


2. Automatic Updates

Flatcar includes a auto update system by default. By default, the Flatcar instance will check for updates every hour, download them if available, and automatically reboot to apply updates to ensure that your instance is always current and up to date. Organizations can always self host their own update server ensuring that they can control how/when their Flatcar instances are kept current.

To view the update configuration, run the following command inside the Flatcar instance:

cat /usr/share/flatcar/update.conf

The output will look like this:

SERVER=https://public.update.flatcar-linux.net/v1/update/
GROUP=stable
  • SERVER: This is the update server Flatcar uses to check for new releases.
  • GROUP: Refers to the promotion level (e.g., stable).

update config

Info

Administrators can customize the default behavior by configuring the upgrade strategy. For example, a common configuration is for administrators to specify a "maintenance windows" for reboots.


Other Installation Methods

If you’re not using QEMU, you can install Flatcar Container Linux on other platforms like VirtualBox, Vagrant, and others. You can find detailed installation instructions for these platforms here. Flatcar also provides prebuilt images for cloud providers like AWS, Azure, Google Cloud, and others. These cloud platforms offer Flatcar-based AMIs or images to streamline deployment. Check out the cloud-specific installation steps here.


Conclusion

In this blog, we:

  • Walked through the steps to install and run a Flatcar Container Linux instance locally.
  • Validated some unique characteristics of Flatcar, such as its lack of a package manager and its auto-update system.
  • Explored Flatcar versioning.

In the upcoming Part 3 of the blog series on Flatcar Linux, we will cover how to install Rafay's Kubernetes Distribution (Rafay MKS) on Flatcar and manage it centrally using the Rafay Platform.

Kubernetes v1.32 for Rafay MKS

As part of our January release, alongside other enhancements and features, we are adding support for Kubernetes v1.32 with Rafay MKS (i.e., upstream Kubernetes for bare metal and VM-based environments).

Both new cluster provisioning and in-place upgrades of existing clusters are supported. As with most Kubernetes releases, v1.32 deprecates and removes several features. To ensure zero impact to our customers, we have validated every feature of the Rafay Kubernetes Operations Platform on this Kubernetes version.

Kubernetes v1.32 Release

Get Started with Auto Mode for Amazon EKS with Rafay

This is Part 3 in our series on Amazon EKS Auto Mode. In the previous posts, we explored:

  1. Part 1: An Introduction: Learn the core concepts and benefits of EKS Auto Mode.
  2. Part 2: Considerations: Understand the key considerations before Configuring EKS Auto Mode.

In this post, we will dive into the steps required to build and manage an Amazon EKS cluster with Auto Mode template using the Rafay Platform. This exercise is specifically well suited for platform teams interested in providing their end users with a controlled self-service experience with centralized governance.

EKS Auto Mode Cluster in Rafay

Deploying Custom CNI (Kube-OVN) in Rafay MKS Upstream Kubernetes Cluster Using the Blueprint Add-On Approach

In continuation of our Part 1 intro blog on the Kube-OVN CNI, this is Part 2, where we will cover how easy it is to manage CNI configurations using Rafay's Blueprint Add-On approach.In the evolving cloud-native landscape, networking requirements are becoming more complex, with platform teams needing enhanced control and customization over their Kubernetes clusters. Rafay's support for custom, compatible CNIs allows organizations to select and deploy advanced networking solutions tailored to their needs. While there are several options available, this blog will focus specifically on deploying the Kube-OVN CNI. Using Rafay’s Blueprint Add-On approach, we will guide you through the steps to seamlessly integrate Kube-OVN into an upstream Kubernetes cluster managed by Rafay’s Managed Kubernetes Service.

Our upcoming release, scheduled for December in the production environment, introduces several new features and enhancements. Each of these will be covered in separate blog posts. This particular blog focuses on the support and process for deploying Kube-OVN as the primary CNI on an upstream Kubernetes cluster.

kube ovn

Watch a video showcasing how users can customize and configure Kube-OVN as the primary CNI on Rafay MKS Kubernetes clusters.

Amazon EKS v1.31 using Rafay

Our recent release update in Oct to our Production environment adds support for a number of new features and enhancements. We will write about the other new features in separate blogs. This blog is focused on our turnkey support for Amazon EKS v1.31.

Both new cluster provisioning and in-place upgrades of existing EKS clusters are supported. As with most Kubernetes releases, this version also deprecates and removes a number of features. To ensure there is zero impact to our customers, we have made sure that every feature in the Rafay Kubernetes Operations Platform has been validated on this Kubernetes version.

Kubernetes v1.31

Using Amazon EKS Pod Identity and Associations with Rafay - Part 2

In continuation of our Part 1 of our blog introducing Pod Identity vs. IRSA for Amazon EKS, this is Part 2, where we will explore how to use Amazon EKS Pod Identity with the Rafay platform. This blog post will guide you through deploying the Amazon EKS Pod Identity Agent and configuring role associations, enabling your Kubernetes pods to securely access AWS services.

Pod Accessing AWS service

Kubernetes v1.30 for Rafay MKS

Our upcoming release scheduled for June to our Preview environment adds support for a number of new features and enhancements. We will write about these in separate blogs. This blog is focused on support for Kubernetes v1.30 with Rafay MKS (i.e. upstream Kubernetes for bare metal and VM based environments).

Both new cluster provisioning and in-place upgrades of existing clusters are supported. As with most Kubernetes releases, this version also deprecates and removes a number of features. To ensure there is zero impact to our customers, we have made sure that every feature in the Rafay Kubernetes Operations Platform has been validated on this Kubernetes version. This will be promoted from Preview to Production in a few days and will be made available to all customers.

Kubernetes v1.30 Release