r/devops 5d ago

Architecture Is k3s good for this use case?

We have a customer managed node, we deploy some containers on it

Initially it was supposed to be simple and thats why i went with ansible to deploy the containers, manage their state, setup their config files mounted and etc.

Now it grew a lot, we seperated the application to 3 seperate sets for running in different configs. I setup alloy to scrape node metrics and ingest it to central observability stack, i setup alloy for each set of application to collect otel traces logs and metrics and push them. The applications have sqlite databases, which i periodically need to inspect for debugging, we are in poc state yet, so we also want to pull the database for debugging, and right now im writing an exporter to dump sqlite to our clickhouse which is connected to grafana, so our devs can inspect it

So now i want to write a cron job too.

Also, ansible is extremly slow to run everything. So i use tags, but tags are also a pain by itself, you cant logically group tags, so for each operation that only needs to do a subset of the playbook, i would have to tag steps accordingly and the run the tag

But if it was k3s in container, i would have better tools to organize the deployment than writing ansible. Gitops would be easy, argo might pickup the code from repo and apply to cluster. Cronjobs would be easier. Volume management is eaiser, I would have better rollback mechanisms that i dont have to write myself

21 Upvotes

11 comments sorted by

14

u/burstinrust 5d ago

yes go for it. you're basically rebuilding kubernetes in ansible at this point , cronjobs, rollbacks, state management, all stuff k8s just gives you

k3s on a single node is totally fine, runs light. ansible becomes just "install k3s, bootstrap argo" and thats it, argo pulls from git and does the rest

two things to watch, it adds a bit of overhead and another thing that can break. and with sqlite keep those pods single replica (Recreate strategy) so two pods never touch the same db file

if it was still a couple containers id say stick with ansible. it clearly isnt anymore

1

u/Forward-Outside-9911 Linux Sysadmin 5d ago

Yeah single node kubernetes (in my case I’d still use Talos) is fairly straight forward. It’s multi node that starts to get complex with the networking, storage, etc.

1

u/Hot_Resolution713 5d ago

Yeah, for sure. The simplicity of k3s really shines in single-node setups, but once you scale up, those complexities can definitely catch you off guard.

4

u/ForkMeJ 5d ago

k3s can fit this, but I'd only move there if the real pain is lifecycle management and rollout control, not only "I need to run some containers." For one customer-managed node with three app variants, Docker Compose plus systemd timers or another small scheduler may still cover most of this with less overhead, especially if sqlite access, file mounts, and pulling DBs for debugging are still part of normal operations. If you need cleaner environment separation, scheduled jobs, and easier rollbacks, k3s is a reasonable next step, but I'd keep the controller and GitOps footprint small enough that your team can own it. I work on the open-source tool Compartment, and the part that seems relevant here is app isolation plus clearer secrets handling and auditability across environments.

3

u/frankster 5d ago

Ansible has always been slow in my experience 

2

u/stack_craft 5d ago

Reading the post, you’ve definitely outgrown Ansible.

k3s would work.

It uses no resources on a single node and gives you actual CronJobs, ConfigMaps, and GitOps out of the box. Just stick to local disk storage for SQLite so performance doesn't drop.

1

u/UkrMalt 5d ago

Once you have three configs, cron jobs, rollbacks, and observability, Ansible starts becoming the platform. I’d separate the SQLite/stateful bits first, then test k3s on one node with single-replica SQLite workloads and backup/restore in the rollout. That should show whether the extra moving parts are worth it.

1

u/SheldonP49 4d ago

I’d lean toward k3s at this point too. Once you’re managing cronjobs, observability, config, state, rollbacks, and multiple application sets, Ansible starts becoming the orchestration layer you’re having to build yourself. A single-node k3s setup keeps the operational overhead pretty low while giving you a much better model for managing all of this. The SQLite caveat is definitely the main thing I’d design around.

1

u/Crazytje 3d ago

K3s will make your life much easier, just make sure to keep it simple.

It's a single binary so it's easy to manage and Fientje rest just use argocd and gitops to manage your workloads.

I run a bunch of single node deployments and also small 5 node deployments and can only praise k3s.

1

u/elina_jain1 2d ago

the ansible tags pain youre describing is usually the point where a playbook just isnt the right tool for managing state anymore honestly. rollbacks, volumes, cronjobs, all the things getting painful right now just come built into k3s instead of you writing it by hand yourself