Is k3s the right next step for a growing single-node deployment?
Asked by
MellowCedar42
We deploy several containers onto a customer-managed node. This started as a simple setup managed with Ansible, including container state, configuration files, and mounted volumes. It has since grown into three application configurations, node and application observability with Alloy, OpenTelemetry logs, metrics and traces, SQLite databases that need periodic inspection, database downloads for debugging, and an exporter that sends SQLite data to ClickHouse for visualization in Grafana. I also need to add scheduled jobs soon.
Ansible is becoming increasingly slow and difficult to manage. I use tags to run only parts of the playbook, but the tags are hard to organize and require extra maintenance whenever a new operation needs a subset of tasks.
Would moving to k3s on this single customer-managed node make sense? It seems like Kubernetes would give me better deployment organization, GitOps through a tool such as Argo, native CronJobs, volume management, and rollback mechanisms without having to build everything myself. Are the added complexity and overhead justified, or would Docker Compose, systemd, or another simpler approach be a better fit?
Answers
You’re getting close to the point where Ansible is turning into a homegrown platform. k3s on a single node is a reasonable choice and is lightweight enough for this use case. You could reduce Ansible to installing k3s and bootstrapping GitOps, then let the cluster manage deployments, scheduled jobs, configuration, and rollouts.
The main cautions are the extra component to operate and the fact that SQLite needs careful handling. Keep those workloads at one replica, use a Recreate strategy so two instances never access the same database file, and make backup and restore part of the deployment process.
Reply to this answer
Based on the number of configurations, observability components, scheduled work, and rollback requirements, k3s is a reasonable next step. It gives you native CronJobs, ConfigMaps, deployment strategies, and a cleaner Git-driven workflow. For SQLite, keep the data on local storage, run a single replica, and test backup and restore before relying on automated rollouts.
Reply to this answer
I’d move to k3s only if lifecycle management, rollout control, scheduled jobs, and environment separation are the real pain points. If you mainly need to run a handful of containers, Docker Compose with systemd timers may still be simpler, especially while SQLite files, bind mounts, and database extraction are central to your workflow.
If you do choose k3s, keep the setup small and avoid introducing more controllers than you can operate. Start with one node and migrate a non-critical application first.
Reply to this answer
Before migrating everything, separate the stateful SQLite pieces from the stateless services and try k3s with one application configuration. That will show whether the deployment and rollback improvements outweigh the added moving parts. Also, Ansible being slow by itself may be worth profiling, but the growing operational scope is a stronger reason to change tools than performance alone.
Reply to this answer
A single-node cluster is fairly straightforward, but the complexity rises quickly once you add multiple nodes, networking, and storage. If you stay with one node, k3s can work well; just be realistic about the operational overhead and make sure your team can maintain the control plane and GitOps tooling.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions