Cloud Native 10 min read

What Sets K3s Apart from Full‑Featured Kubernetes? A Hands‑On Guide

This article explains the lightweight nature of K3s, compares it with standard Kubernetes, and provides step‑by‑step commands for installation, cluster access, node addition, service deployment, and ingress configuration, highlighting practical differences and use‑case considerations.

Liangxu Linux
Liangxu Linux
Liangxu Linux
What Sets K3s Apart from Full‑Featured Kubernetes? A Hands‑On Guide

Overview

K3s is a CNCF‑certified, lightweight distribution of Kubernetes. It bundles the core Kubernetes control‑plane components (api‑server, scheduler, controller‑manager, etcd or an embedded SQLite datastore) and common add‑ons (CoreDNS, Traefik ingress) into a single binary that is typically under 100 MiB. Because optional drivers, cloud integrations and many volume plugins are omitted, K3s can run on a Linux host with as little as 512 MiB RAM and a single CPU, making it suitable for edge devices, IoT boards (e.g., Raspberry Pi) and CI environments.

Key differences from standard Kubernetes

Single‑binary packaging with minimal external dependencies.

Reduced hardware and memory requirements.

Can be deployed as a single‑node server or in a high‑availability (HA) mode using an external datastore (etcd, MySQL, PostgreSQL).

Flannel is the default CNI; Traefik is the default Ingress controller.

Installation

The official installation script installs K3s as a systemd service. curl -sfL https://get.k3s.io | sh - To disable the bundled Flannel CNI (e.g., when you plan to use another CNI), pass the --flannel-backend none flag either via the environment variable or directly in the install command:

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

Alternatively, set the environment variable before invoking the server binary:

INSTALL_K3S_EXEC="--flannel-backend none" k3s server

Cluster access

K3s writes a kubeconfig file to /etc/rancher/k3s/k3s.yaml. Export it so that kubectl can communicate with the cluster: export KUBECONFIG=/etc/rancher/k3s/k3s.yaml Or copy the config to the standard location:

mkdir -p ~/.kube
sudo k3s kubectl config view --raw | tee ~/.kube/config
chmod 600 ~/.kube/config

Verify the control plane is up:

kubectl get nodes

Adding worker nodes

On the server, obtain the node‑join token: cat /var/lib/rancher/k3s/server/node-token On each worker, run the same install script, providing the server URL and the token:

curl -sfL https://get.k3s.io | \
  K3S_URL=https://<code>MASTER_IP</code>:6443 \
  K3S_TOKEN=<code>NODE_TOKEN</code> sh -

Deploying a sample application

Create a three‑replica Nginx deployment:

kubectl create deployment nginx \
  --image=nginx \
  --port=80 \
  --replicas=3

Check that the pods are running: kubectl get pods Expose the deployment with a ClusterIP service (the default service type):

kubectl create service clusterip nginx --tcp=80:80

Inspect the service to see its internal IP and endpoint list:

kubectl describe service nginx

Ingress configuration (Traefik)

Define an Ingress resource that forwards HTTP traffic on / to the Nginx service:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx
            port:
              number: 80

Apply the manifest and verify the Ingress object:

kubectl apply -f nginx-ingress.yaml
kubectl describe ingress nginx

The Ingress will be served by the built‑in Traefik controller. Access the application by sending an HTTP request to the node’s IP address (e.g., http://192.168.1.103/).

Comparison with full Kubernetes

Both K3s and upstream Kubernetes share the same API, resource definitions, and tooling (kubectl, Helm, etc.). The primary differences are:

Packaging: K3s is a single binary; upstream Kubernetes consists of many binaries and system services.

Resource footprint: K3s runs on minimal hardware (≈512 MiB RAM, 1 CPU) whereas a standard cluster typically requires several gigabytes of RAM and multiple CPUs.

Startup time: K3s can bring up a functional cluster in seconds, useful for development, edge, or CI pipelines.

Architecture support: K3s provides native ARMv7/ARM64 builds, enabling use on Raspberry Pi and other low‑power devices.

HA and datastore options: By default K3s uses an embedded SQLite store; HA setups can replace it with external etcd, MySQL, or PostgreSQL.

For production workloads that demand extensive add‑ons, custom networking plugins, or multi‑cloud integrations, a full Kubernetes installation remains the recommended choice. K3s excels in scenarios where low resource consumption, rapid provisioning, and simplicity are paramount.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

DockerKubernetesClusterIngressK3slightweightTraefik
Liangxu Linux
Written by

Liangxu Linux

Liangxu, a self‑taught IT professional now working as a Linux development engineer at a Fortune 500 multinational, shares extensive Linux knowledge—fundamentals, applications, tools, plus Git, databases, Raspberry Pi, etc. (Reply “Linux” to receive essential resources.)

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.