Build1 publisher3 min readPublished
SQLite carries the k3s control plane to a claimed 50 nodes and 5,000 pods
A dev.to walkthrough makes the case for k3s over upstream kubeadm on install speed and defaults, and rests it on an embedded SQLite datastore that it rates for 50 nodes and 5,000 pods.
The Engineer · Build desk
What happened
- A dev.to post argues that the moving parts of a kubeadm cluster, from etcd and the apiserver through the scheduler, controller-manager, CNI and ingress controller, leave you debugging the cluster instead of developing the application.
- It offers SUSE's k3s as the replacement, describing it as a highly compact but fully CVE-compliant Kubernetes distribution and not a stripped-down toy version.
- Where classic Kubernetes runs several dozen binaries and wants at least three server nodes just to keep etcd redundant, k3s ships as a single binary of just under 100 MB.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint The ceiling is published as a count of pods, so a team sizing a k3s cluster has nothing to check its own object churn against until the datastore is already the bottleneck.
- exposure Following the post's own kubeconfig steps leaves a cluster credential in a home directory, within reach of anything that can read that user's files.
- decision Adopting k3s shifts the work from assembling a control plane to unpicking the CNI and storage class it has already started, so the networking decision arrives after the cluster is running.
- contradiction The post presents SQLite as the single-node default and then as its answer to high availability. Its HA guidance is unusable as written.
The install one-liner is the least interesting part of the post, and the file paths it leaves behind say why. `curl -sfL https://get.k3s.io | sh -` downloads the compiled binary, sets up the systemd services and starts the cluster immediately [11]. The kubeconfig lands at /etc/rancher/k3s/k3s.yaml [12]. The post's next two commands copy that file to ~/.kube/config and chown it to the logged-in user [12]. A cluster credential then sits in a home directory, readable by every process running as that user.
Argue with the capacity claim. k3s uses an embedded SQLite database instead of etcd, and the post rates that as more than performant for clusters up to 50 nodes and 5,000 pods, with no separate database cluster to operate [7]. Divide the pods by the nodes and the envelope averages 100 pods per node [20]. For that figure to transfer to your cluster, the thing that has to match is the write rate against the apiserver. The post does not say what workload produced the figure. A datastore is sized by object churn: lease renewals, events, rollouts, controller writes.
What you pick when you pick k3s is a set of defaults. The old in-tree storage plugins and the old-style nginx and traefik ingress controllers are out [8]. Flannel is the CNI and local-path-provisioner is the storage backend [9], and every component runs as a systemd service under one main unit [10]. The post is right about the control it gives up: it asks how often anyone really updates kube-proxy's version by hand, and credits k3s with automating that overhead [13]. Swapping the CNI later means disabling something the installer already started.
On high availability the post states the problem correctly. Vanilla Kubernetes makes you either maintain an external etcd cluster or run the multi-control-plane join with `--control-plane` [14]. Its answer is the built-in SQLite backend plus a server token read from /var/lib/rancher/k3s/server/node-token, with the first node taking the main controller role and further nodes attaching to it [15][16]. One server holds the state and the others join it.
Three deliverables are promised up front: why k3s is the sensible choice, an install in under three minutes, and the pitfalls in network configuration [17]. The available text ends mid-sentence in the node-join step, before the networking section [18]. So the strongest evidence on offer is operational. The author reports having administered dozens of Kubernetes clusters and wrote that k3s "hat meine mentale Last halbiert" [19], or halved the mental load.
I would take that trade for CI runners, dev clusters and single-tenant small production, where a dead control plane costs a rerun and the datastore never leaves one box. The description of k3s as a fully CVE-compliant distribution from SUSE, not a cut-down version [3], is what makes it defensible for anything user-facing. Where control plane downtime costs an SLA, the three server nodes the post calls oversized for a startup [5] are what a replicated datastore costs.
What to watch
- Whether the published post's networking section goes past the join step and documents the CNI and ingress pitfalls it promises.
- Any measurement behind the 50-node, 5,000-pod envelope stated as object churn per second rather than pod count.
- A correction to the HA passage that separates joining nodes to one server from replicating the datastore.