Skip to content
@syahshiimi Homelab Docs

202501272235 Kubernetes Through K3s

If you have looked at my Homelab Topology, especially these Homelab Topology.pngk3s Cluster Topology.png You might be wondering why I chose K3s as the distribution flavour for Kubernetes.

I got ahead of myself and proceeded to design my homelab and cluster topology without having the opportunity or making a choice to document my decision. I think it’s quite simple – I wanted an easier way to deploy Kubernetes into my homelab. What defines easy? I think there are a few points of why that choice became easy.

  1. K3S is a lightweight distribution that can be deployed with its provided binaries. The lightweight distribution removes many of the K8s binaries, such as ceph, glusterfs, and others, that would bloat an environment that might not use them at all. In short – I wanted a very minimal distribution while at the same time being opinionated enough to say hey, this is the lightest and simplest way to do Kubernetes for a production environment
  2. I didn’t want to use Kubeadm to deploy – I’ve used it before and granted it made me learn more about Kubernetes, but it wasn’t an enjoyable experience.
  3. An opinionated but simplified way of doing this.
    1. It comes with its own ServiceLb and opinionated way of handling distributed cluster datastore
      1. I can opt to do an embedded Sqlite datastore if I need to. That simplifies a lot of operational overhead to get things done fast.
      2. I find this very interesting as one of the goals of the 202412271311 Homelab Goals 2025 is to distribute computing across space.
    2. Additional “batteries-included” dependencies on top of core Kubernetes binaries
      1. CoreDNS
      2. Flannel
      3. containerd
      4. Local-path provisioner
  4. k3s has a Docker version in the form of k3d. I use it at work to run applications in a close-to Kubernetes environment and found it great to understand the system infrastructure as a whole. This offers the benefit of creating a “playground” cluster locally for testing and dev. I want to adopt a Kubernetes-first deployment methodology if that makes sense.