K3s - Kubernetes That Doesn't Suck

K3s is Kubernetes for people who don't want to become Kubernetes experts just to run some containers. It's the same Kubernetes API you know, but without the operational nightmare. CNCF certified and production-ready, it strips away the complexity while keeping the power.

Why K3s Doesn't Suck

Regular Kubernetes requires you to install and configure about 20 different pieces. K3s said "fuck that" and stuffed everything into one binary. Instead of dealing with etcd's bullshit, K3s uses SQLite by default. Revolutionary.

The memory usage is actually reasonable - I've run it on a Pi 4 with 4GB RAM and still had space for actual applications. Try that with regular Kubernetes and watch your Pi catch fire. Check the official resource profiling for exact numbers.

Current stable release is v1.33.4+k3s1 as of September 9, 2025, tracking Kubernetes v1.33.4. K3s v1.34.0-rc1+k3s1 is available (tracks Kubernetes v1.34.0 released August 27). So you get all the latest features without the installation drama. Track the release schedule and roadmap for what's coming.

What You Get Out of the Box

Here's the clever part - K3s includes everything you need to actually run workloads:

• Traefik ingress controller (works better than nginx-ingress, fight me)
• Flannel networking that just works
• CoreDNS because you need DNS resolution
• Local path provisioner for storage that isn't a pain in the ass
• Containerd runtime because Docker is dead

No more spending 3 hours configuring an ingress controller. No more debugging CNI networking hell. It just fucking works. Need proof? Check out production case studies from companies actually using this in the real world. Scaleway uses Kubernetes extensively in their cloud platform.

Resource Usage That Won't Bankrupt You

I've actually measured this on my homelab Pi cluster and 2019 MacBook (tested August 2025 with K3s v1.33.x):

• Memory: Server nodes use 1.2-1.8GB depending on workload (measured with free -h after boot, matches official profiling)
• CPU: Idles at 1-3% on decent hardware, spikes during pod scheduling
• Disk: Binary is 72MB for arm64, total install about 450MB after pulling container images
• Startup: 45 seconds on my MacBook, about 90 seconds on Pi 4 with decent SD card

Compare that to regular Kubernetes which needs at least 3-4GB RAM just to breathe. On a Pi 4, regular K8s will eat your entire 4GB and cry for more. K3s leaves you room to run actual applications. The benchmarks prove it - K3s consistently outperforms standard K8s distributions in resource-constrained environments.

When K3s Breaks (Because Everything Does)

The GitHub issues are usually pretty helpful, unlike some other projects I could name. Common gotchas I've personally hit:

• SELinux will fuck with you on RHEL/CentOS - learned this the hard way on production deployment. Check the SELinux guide
• Firewall rules get weird with multi-node - spent 3 hours debugging why nodes wouldn't join. See the networking requirements
• Don't run it rootless unless you hate yourself - rootless mode is experimental and breaks in creative ways
• The installation script works 90% of the time - when it doesn't, check the troubleshooting guide. Corporate proxies are usually the culprit

Installation Reality Check

Yeah, it's one command: curl -sfL https://get.k3s.io | sh -

This actually works about 90% of the time. The other 10%:

• Your firewall hates you
• SELinux is having opinions
• You're on some weird architecture
• The network gods are angry

When it works, you get a working Kubernetes cluster in under a minute. When it doesn't, you'll spend 2 hours debugging why your corporate proxy is blocking GitHub.

Here's what the install script actually does (when it doesn't break)

The install script does this:

• Downloads the K3s binary (around 60-80MB depending on arch) from GitHub releases
• Dumps it in /usr/local/bin/k3s - check the installation options for alternatives
• Creates a systemd service for automatic startup
• Generates kubeconfig at /etc/rancher/k3s/k3s.yaml - see cluster access for details
• Starts everything up with embedded SQLite by default

Your kubeconfig ends up with crazy-restrictive permissions. Copy it somewhere you can actually use it:

sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER ~/.kube/config

Multi-Node Setup

For more than one machine, you grab a token from the first machine and tell other machines to join:

## Get the token from the server
sudo cat /var/lib/rancher/k3s/server/node-token

## On other nodes
curl -sfL https://get.k3s.io | K3S_URL=https://your-server:6443 K3S_TOKEN=your-token sh -

Simple enough until you hit networking issues, then you're back to debugging iptables like it's 2015. The multi-server setup docs cover the gory details, and the agent configuration reference explains all the knobs you can turn.

When It Breaks (Troubleshooting Guide)

"dial tcp 192.168.1.100:6443: connect: connection refused"

• Firewall is blocking port 6443. Check systemctl status ufw or firewall-cmd --list-ports - see networking requirements
• K3s died during startup: systemctl status k3s and journalctl -u k3s will tell you why - check the systemd service guide

"Permission denied" errors

• Kubeconfig permissions are fucked. See the copy command above - cluster access docs explain the details
• You're not in the right group: sudo usermod -aG docker $USER (then logout/login)

"Unable to connect to the server: x509: certificate signed by unknown authority"

• You copied the kubeconfig but didn't update the server IP - certificate management explains why
• Edit ~/.kube/config and fix the server line

SELinux is being a pain

• Quick fix: sudo setenforce 0 (don't do this in production, your security team will murder you)
• Proper fix: Install the RPMs and configure policies - took down our staging cluster for 2 hours when I upgraded RHEL and forgot about this. SELinux support guide has the answers

Production Deployment Reality

The docs are actually decent. Key things they don't emphasize enough:

High Availability: You need 3+ server nodes with embedded etcd. Don't try to be clever with 2 nodes - split-brain scenarios will ruin your week. Check the HA setup guide for the full process.

External Database: If you want HA but don't trust embedded etcd, use PostgreSQL or MySQL. Don't use SQLite in production unless you like data loss. The external datastore docs explain the setup.

Load Balancer: Put something in front of your K3s servers. HAProxy works, so does nginx. Cloud load balancers work too - see the load balancer setup guide.

Networking: Default Flannel networking works for most stuff. If you need something fancy, you can swap in Calico or Cilium. Check the networking options for alternatives.

Backup: Snapshot etcd regularly. The built-in snapshot feature works: k3s etcd-snapshot save. Test your restore process before you need it - the backup and restore guide covers everything.