K3s Deployment on Fedora and Fedora CoreOS Architecture

The integration of K3s into the Fedora ecosystem represents a convergence of lightweight container orchestration and a robust, cutting-edge Linux distribution. K3s is designed as a highly optimized, lightweight Kubernetes distribution that minimizes resource consumption while maintaining full compatibility with the Kubernetes API. This makes it an ideal candidate for home labs, edge computing, and small-scale production environments where the overhead of a full Kubernetes installation would be prohibitive. When deployed on Fedora, K3s benefits from the latest kernel advancements and the stringent security posture provided by Security-Enhanced Linux (SELinux). However, the interplay between K3s's orchestration requirements and Fedora's security defaults creates a specific set of operational requirements.

Operating K3s on Fedora is not merely a matter of running a script; it requires a nuanced understanding of the underlying system architecture. For users utilizing standard Fedora Server, the focus is on managing the package manager, firewall, and security policies. Conversely, for those utilizing Fedora CoreOS, the paradigm shifts toward an immutable infrastructure model. Fedora CoreOS provides a minimal, bulletproof host system characterized by atomic updates, which fundamentally changes how K3s is installed and maintained. In this environment, the system is treated as a disposable entity where configuration is managed via Butane and Ignition files, ensuring that the environment can be reproduced with absolute precision.

The tactical implementation of K3s on these platforms allows users to leverage production-grade orchestration tools such as kubectl and Helm to manage workloads that might otherwise be handled by simpler tools like Docker or Docker Compose. Whether the goal is to self-host an RSS reader, manage a private cloud, or experiment with microservices, the Fedora and K3s combination provides a scalable foundation. This combination ensures that the user does not sacrifice the power of Kubernetes for the sake of simplicity, providing a path from a single-node experimental setup to a highly available, multi-node cluster.

Hardware and System Prerequisites

Before initiating the installation of K3s on a Fedora-based system, it is imperative to ensure the underlying hardware meets the minimum and recommended specifications to prevent pod instability or system crashes.

The requirements vary depending on the intended workload, but the baseline for a server node is as follows:

Specification Minimum Requirement Recommended Requirement
CPU Cores 1 Core 2 Cores
RAM 512 MB 1 GB - 2 GB

The impact of these requirements is significant. While K3s is designed to run on minimal hardware, providing only the minimum (512 MB RAM) may lead to memory pressure when running multiple pods or complex services. Increasing the RAM to 2GB ensures that the K3s control plane and the container runtime have sufficient headroom to operate without triggering the Out-Of-Memory (OOM) killer.

From a system perspective, the following prerequisites must be met:

  • A recent Fedora release.
  • Root or sudo administrative access.
  • Familiarity with Kubernetes and the kubectl command-line tool.
  • For CoreOS users: Knowledge of the coreos-installer, butane, and ignition-validate tools.

The requirement for sudo access is non-negotiable, as K3s must modify system-level networking and install binaries into protected directories. For those utilizing Fedora CoreOS, the prerequisites extend to the configuration layer, as the user must be proficient in creating Ignition files to automate the provisioning process.

Standard Fedora Installation and System Preparation

Installing K3s on a standard Fedora Server VM requires a sequence of preparation steps to ensure the environment is compatible with the K3s runtime, specifically concerning the package manager and security policies.

The first step involves updating the system to ensure all dependencies are current. This is achieved using the DNF package manager:

sudo dnf upgrade -y

Once the system is updated, specific packages must be installed to support the security and policy requirements of the K3s distribution. These packages include container-selinux, selinux-policy-base, and policycoreutils-python-utils.

sudo dnf install -y container-selinux selinux-policy-base policycoreutils-python-utils

The inclusion of container-selinux is critical because it provides the necessary security policies that allow containers to interact with the host system in a controlled manner. Without these policies, K3s may encounter permission errors when attempting to launch pods or access host resources.

Firewall Configuration and Networking

Fedora's default firewall configuration can obstruct the communication required for K3s cluster operations. If firewalld is kept enabled, specific rules must be implemented to ensure the cluster remains functional.

Rather than relying on the cni0 interface name, which can be volatile, it is recommended to trust the default K3s pod and service CIDRs. This ensures consistent connectivity regardless of the interface naming convention. The relevant CIDRs are:

  • Pod CIDR: 10.42.0.0/16
  • Service CIDR: 10.43.0.0/16

The impact of configuring these CIDRs is that K3s can maintain a stable internal network for pod-to-pod and pod-to-service communication. If these are not properly trusted in firewalld, the pods may fail to communicate, leading to "Connection Refused" errors and service outages.

Additionally, K3s fully supports cgroups v2, which is the default on Fedora 31 and later. This support is integrated into the K3s runtime, allowing for more efficient resource management and isolation of container workloads.

K3s Installation Process

The installation of K3s is designed to be rapid and streamlined, typically completed via a shell script.

For a basic installation, the following command is used:

curl -sfL https://get.k3s.io | sh -

This process requires the sudo password and executes the K3s installation script. The script allows for various customization options to tailor the components installed based on the specific requirements of the environment.

For installations on SELinux-enforcing Fedora systems, it is a best practice to use the --selinux flag. This ensures that the containerd runtime is launched with K3s SELinux support enabled, which is vital for maintaining the security integrity of the host. The command for this specific implementation is:

-sfL https://get.k3s.io | K3S_URL=https://<SERVER_IP>:6443 K3S_TOKEN=<TOKEN> sh -s - --selinux

In this command, the K3S_URL specifies the server IP and the API port (6443), while the K3S_TOKEN provides the necessary authentication for joining the cluster.

Fedora CoreOS Bare Metal Implementation

Deploying K3s on Fedora CoreOS represents a shift toward immutable infrastructure. Fedora CoreOS provides a minimal host system with atomic updates, which ensures that the system remains in a known, stable state.

The installation process for CoreOS involves creating a USB boot stick. Using the coreos-installer tool, a machine can be transformed into a single-node Kubernetes cluster. It is critical to note that booting from the USB stick will wipe all existing data on the machine without a confirmation prompt.

The configuration of a CoreOS system is managed via Butane and Ignition files. Butane allows users to write a human-readable configuration that is then converted into an Ignition file, which the CoreOS system consumes during the first boot.

Managing Immutable Data and Persistence in CoreOS

One of the primary challenges of immutable systems is the preservation of application data during system reinstalls or updates. Fedora CoreOS addresses this by separating immutable system data from mutable application data.

All application data, including configurations and databases, is stored in /var. To preserve this data across reinstalls, the storage configuration must be explicitly defined in the .bu (Butane) file. The following configuration demonstrates how to preserve the /var partition:

yaml storage: disks: - device: /dev/disk/by-id/coreos-boot-disk wipe_table: false partitions: - number: 4 label: root size_mib: 8192 resize: true - label: var size_mib: 0 filesystems: - path: /var device: /dev/disk/by-partlabel/var format: xfs wipe_filesystem: false with_mount_unit: true

In this configuration:

  • wipe_table: false prevents the disk table from being destroyed.
  • wipe_filesystem: false ensures that the /var filesystem is preserved on reinstall.
  • size_mib: 0 instructs the system to use the remainder of the disk space for the /var partition.

Furthermore, Fedora CoreOS maps /usr/local to a subvolume in /var. This means the K3s binary, installed in /usr/local/bin, is preserved. To ensure the binary is updated during a reinstall, the overwrite: true setting must be applied in the configuration. This allows the Ignition process to replace the old K3s binary with the latest version while keeping the application data in /var intact.

Troubleshooting and SELinux Management

Because Fedora is an SELinux-enforcing distribution, it is common to encounter permission-related issues where pods fail to start. This is usually the result of SELinux denials.

To diagnose these issues, users can search for AVC (Access Vector Cache) denials using the following command:

sudo ausearch -m avc -ts recent | audit2why

The audit2why tool is essential as it translates complex SELinux denial logs into human-readable explanations, providing guidance on why a specific action was blocked.

For temporary testing purposes, SELinux can be set to permissive mode:

sudo setenforce 0

However, this is strictly for testing and should not be used in production environments. The recommended approach is to resolve the underlying policy issue or ensure K3s was installed with the --selinux flag.

Advanced Cluster Expansion and Integration

Once a single-node K3s cluster is established on Fedora, it can be expanded and integrated with other services to create a more powerful infrastructure.

The following capabilities can be implemented:

  • Netboot Provisioning: Using netboot instead of the coreos-installer ISO for faster machine provisioning.
  • Automatic Update Strategies: Configuring the system to handle atomic updates without manual intervention.
  • DNS Services: Configuring an ad-blocking DNS server using dnsmasq.
  • VPN Integration: Setting up a secure network tunnel using wireguard.
  • Multi-node Clusters: Adding additional nodes to the cluster using the k3s agent command.
  • High Availability (HA): Creating a highly available Kubernetes control plane to ensure no single point of failure.

The impact of these expansions is a shift from a simple home lab to a production-ready environment. By adding more nodes via the agent, the cluster can distribute workloads across multiple physical machines, increasing total CPU and RAM availability.

Analysis of K3s on Fedora Performance and Stability

The deployment of K3s on Fedora, particularly when utilizing the CoreOS variant, results in a system that is significantly more stable than traditional Kubernetes installations. The stability stems from the reduced complexity of K3s and the immutability of the CoreOS host.

By removing unnecessary components from the Kubernetes core, K3s reduces the memory footprint, which is why it can operate on as little as 512 MB of RAM. On Fedora, this efficiency is complemented by the xfs filesystem and the optimized kernel, resulting in lower latency for container operations.

The use of an immutable host in CoreOS means that the risk of "configuration drift"—where the system state diverges over time due to manual changes—is eliminated. Since the system is provisioned via Ignition and updated atomically, the operator can be confident that every node in the cluster is identical. This consistency is critical when scaling from a single node to a large cluster, as it ensures that application behavior is predictable across all nodes.

Furthermore, the integration of SELinux provides a layer of security that is often neglected in home lab environments. While it introduces a learning curve and requires specific flags during installation, the result is a hardened system where containers are restricted from accessing unauthorized host resources. This makes K3s on Fedora a viable option for users who intend to expose services to the internet, as it provides a defense-in-depth strategy.

In conclusion, K3s on Fedora is a powerful synergy of lightweight orchestration and a secure, modern OS. Whether through the flexible standard Fedora Server or the immutable Fedora CoreOS, the result is a professional-grade platform capable of running any containerized workload with minimal overhead.

Sources

  1. OneUptime
  2. DevNonsense
  3. Dev.to

Related Posts