The own proliferation of container orchestration has led to a divergence between heavy-duty enterprise clusters and the need for lightweight, edge-ready environments. K3s, a lightweight Kubernetes distribution created by Rancher (now a part of SUSE), represents a strategic shift in how container orchestration is delivered. By stripping away legacy cloud provider code and optimizing the binary size to under 100MB, K3s provides a CNCF-certified environment that adheres to the same software conformance tests as full Kubernetes distributions. This ensures that any configuration designed for standard Kubernetes (K8s) will function seamlessly within a K3s ecosystem.
The nomenclature of K3s is a deliberate play on the "K8s" abbreviation. In K8s, the number 8 represents the eight letters between the 'k' and the 's' in Kubernetes. K3s follows this logic by dividing the total number of letters in Kubernetes (10) in half and replacing the 8 with a 3, symbolizing its trimmed requirements and reduced resource footprint. This architectural pruning allows K3s to run on diverse hardware, from high-performance CentOS 8 servers to resource-constrained ARM-based devices, without sacrificing the core capabilities of the Kubernetes API.
K3s Architecture and Component Analysis
To understand the efficiency of K3s, it is necessary to contrast its architecture with the standard Kubernetes model. A full Kubernetes distribution utilizes six main components, each operating as a distinct process. The control plane traditionally manages the following:
- API Server: This serves as the central management hub, handling all communications between the various cluster components.
- Controller Manager: This component is responsible for managing the jobs required to maintain the desired state of the cluster.
- Scheduler: This process monitors for newly created pods that have not yet been assigned to a node and selects the most appropriate home for them based on resource availability.
- Cloud Controller Manager: An optional component that interacts with specific cloud providers to configure storage and load balancers.
In a standard K8s deployment, a key/value store is mandatory to maintain the cluster state. K3s optimizes this by utilizing sqlite3 as the default backend storage. This removes the heavy overhead associated with maintaining a separate etcd cluster for smaller deployments. However, for those requiring higher availability or specific database preferences, K3s provides flexibility by supporting etcd3, MySQL, and Postgres database options.
System Requirements and Prerequisites
Deploying K3s on CentOS 8 requires adherence to specific baseline requirements to ensure cluster stability. These requirements apply regardless of whether K3s is deployed as a native Linux service or within a container.
The primary prerequisite for any K3s cluster is the uniqueness of node identifiers. Two nodes within the same cluster cannot share the same hostname. If an automated provisioning system is used that might reuse hostnames, K3s provides mechanisms to prevent collisions. Users can utilize the --with-node-id option, which appends a random suffix to each node, or they can explicitly define a unique name using the --node-name flag or the $K3S_NODE_NAME environment variable.
The hardware and software compatibility for K3s is extensive:
- Architectures: K3s is officially supported on x86_64, armhf, and arm64/aarch64.
- Operating Systems: While designed for most modern Linux systems, specific setup requirements apply to SUSE Linux Enterprise, openSUSE, Red Hat Enterprise Linux (RHEL), CentOS, Fedora, Ubuntu, Debian, and Raspberry Pi.
CentOS 8 Network and Security Configuration
CentOS 8 utilizes firewalld and SELinux by default, both of which can interfere with the communication between the K3s control plane and worker nodes if not configured correctly.
The most straightforward approach to network configuration is to disable the firewall entirely:
systemctl disable firewalld --now
However, in production environments where security is paramount, firewalld can remain active provided the necessary ports and zones are configured. The following commands ensure the API server and pod communications are permitted:
- Open the API server port:
firewall-cmd --permanent --add-port=6443/tcp - Permit pod communication:
firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 - Permit service communication:
firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16 - Apply changes:
firewall-cmd --reload
Regarding security, SELinux is enabled by default on CentOS. K3s requires specific SELinux policies to function. The installation script is designed to handle this automatically by installing the SELinux RPM from the Rancher RPM repository, provided the installation is not being performed in an air-gapped environment.
Step-by-Step K3s Installation on CentOS 8
The deployment of a K3s cluster involves two primary phases: the installation of the Master node (Server) and the attachment of Worker nodes (Agents).
Master Node Setup
The master node acts as the control plane for the entire cluster. The installation is initiated via a curl command that fetches and executes the official installation script.
The installation script handles versioning through several methods. It can use a specific PR artifact, a specific commit hash via ${INSTALL_K3S_COMMIT}, or a version string via ${INSTALL_K3S_VERSION}. If no version is specified, the script identifies the latest release for the chosen channel. The script supports both curl and wget for downloading the necessary binaries.
Once the server is installed, the administrator must retrieve the node token. This token is essential for authenticating worker nodes when they join the cluster. The token is located at:
cat /var/lib/rancher/k3s/server/node-token
Worker Node Installation
Worker nodes, or agents, are the machines that actually run the containerized workloads. To install the K3s agent on a CentOS 8 worker node, the following command is executed:
curl -sfL https://get.k3s.io | K3S_URL=${k3s_Master_url} K3S_TOKEN=${k3s_master_token} sh -
In this command, ${k3s_Master_url} must be replaced with the actual URL of the master node (e.g., https://k3smaster.devopsart.com:6443) and ${k3s_master_token} must be replaced with the token retrieved from the master node.
After execution, the status of the agent service can be verified using:
systemctl status k3s-agent.service
Cluster Validation
Validation is performed on the master node to ensure the worker node has successfully joined the cluster. The kubectl tool is used to query the node list:
kubectl get nodes
If the worker node is listed, the attachment process is complete and the cluster is operational.
Containerized K3s Deployment via Docker
For developers who prefer local development or isolated environments, K3s can be run within Docker containers using the rancher/k3s images. This avoids the need to install K3s as a native service on the host OS.
To launch a K3s server using Docker, the following command is utilized:
sudo docker run --privileged --name k3s-server-1 --hostname k3s-server-1 -p 6443:6443 -d rancher/k3s:v1.24.10-k3s1 server
Critical considerations for Docker deployments include:
- Version Tags: Users must specify a valid K3s version tag. The "latest" tag is not maintained and should be avoided.
- Tag Syntax: Docker does not support the
+sign in tags. Therefore, any version that would normally contain a+must use a-instead. - Kubeconfig Access: To manage the cluster from the host machine, the admin kubeconfig must be copied out of the container:
sudo docker cp k3s-server-1:/etc/rancher/k3s/k3s.yaml ~/.kube/config
Workload Deployment and Validation
Once the cluster is validated, the operational capability of the K3s environment can be tested by deploying a web server. Helm is the preferred tool for this process.
Helm Installation
To install Helm on the CentOS 8 system, the following commands are executed:
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
cp -r /usr/local/bin/helm /usr/bin/helm
Deploying Nginx
Using the Bitnami repository, an Nginx web server can be deployed to the K3s cluster.
- Add the Bitnami repository:
helm repo add bitnami https://charts.bitnami.com/bitnami - Install the Nginx server:
helm install nginx-web bitnami/nginx
To verify that the Nginx pod is running and to retrieve its IP address, the following command is used:
kubectl get pods -o wide
Accessing the Nginx web server is then achieved by utilizing the ClusterIP of the Nginx service, confirming that the container is reachable and the K3s network fabric is functioning correctly.
K3s Technical Specifications Summary
The following table outlines the core technical attributes of K3s as compared to the standard Kubernetes distribution.
| Feature | K3s Specification | K8s (Standard) Specification |
|---|---|---|
| Binary Size | < 100MB | Significantly Larger |
| Default Storage | sqlite3 | etcd |
| Storage Options | sqlite3, etcd3, MySQL, Postgres | etcd |
| Certification | CNCF Certified | CNCF Certified |
| Target Environment | Edge, IoT, Local Dev, Small Servers | Data Centers, Large Cloud Clusters |
| Architecture Support | x86_64, armhf, arm64/aarch64 | Various |
Analysis of K3s Implementation Efficiency
The implementation of K3s on CentOS 8 represents a significant reduction in the "time-to-cluster" metric. By replacing the complex etcd installation with a lightweight sqlite3 backend, the operational overhead is minimized, allowing the system to boot faster and consume fewer CPU and RAM resources. This is particularly impactful for developers who require a local Kubernetes environment without the resource exhaustion associated with full K8s.
The use of a single-binary approach allows for simplified lifecycle management. Because the installation is handled by a script that can dynamically resolve versions and handle SELinux RPMs, the risk of configuration drift during the initial setup is greatly reduced. The ability to transition from a single-node setup to a multi-node cluster via a simple token-based authentication mechanism streamlines the scaling process.
Furthermore, the compatibility with Helm ensures that K3s is not a "crippled" version of Kubernetes, but rather a "distilled" version. The fact that it passes CNCF conformance tests means that the ecosystem of charts and operators available for K8s is entirely available for K3s. This creates a seamless path for applications to move from a K3s development environment to a production-grade K8s cluster without requiring code changes.
In the context of CentOS 8, the integration of firewalld and SELinux provides a robust security layer that, while initially challenging, ensures the cluster is hardened. The ability to run K3s in Docker further expands its utility, enabling "K3s-in-Docker" (K3d) patterns for rapid testing. Overall, K3s transforms Kubernetes from a heavy-duty infrastructure project into a portable tool that can be deployed across any architecture.