We have a customer-managed node where we run several containers. The setup started simple, so I used Ansible to deploy the containers, manage their state, configure mounted files, and handle updates. It has grown considerably: the application is now split into three independently configured groups, Alloy collects node metrics, and separate Alloy instances collect logs, traces, and metrics from each application group for our central observability stack. The applications use SQLite databases that I periodically inspect for debugging. Since this is still a proof of concept, we also need to pull database files for investigation, and I'm building an exporter that sends SQLite data to ClickHouse for inspection in Grafana. I'm also planning to add scheduled jobs. Ansible is becoming increasingly slow and difficult to manage. I use tags to run only parts of the playbook, but tags cannot be grouped logically, so every partial operation requires carefully tagging individual tasks. I'm considering running k3s on the node instead. Kubernetes would give us more structured deployment management, GitOps through a tool such as Argo CD, native CronJobs, volume configuration, and rollback capabilities without having to build them ourselves. Does k3s make sense for this use case, or would Docker Compose, systemd, or another lightweight approach be more appropriate?
3 Answers
I’d move to k3s only if rollout control, environment separation, and scheduled workloads are the main sources of pain. If this is still just one node with a few containers, Compose plus systemd timers could remain much simpler, particularly while you need direct access to mounted SQLite files and database copies. Before committing, separate and test the stateful pieces so you can confirm that Kubernetes storage, backups, and debugging workflows are manageable for your team.
You’re reaching the point where Ansible is starting to become the platform rather than just the provisioning tool. k3s on a single node is a reasonable fit: Ansible could install and bootstrap k3s, while GitOps handles application deployment, scheduled jobs, configuration, and rollouts. Keep in mind that it adds another system to operate, so it is worth it only if the lifecycle and deployment benefits outweigh that overhead. For SQLite, use one replica, avoid concurrent writers, and make backup and restore part of the deployment process. A Recreate strategy can help ensure that two instances never use the same database file.
The combination of three application configurations, observability agents, cron jobs, and rollback requirements makes k3s a sensible next step. It gives you native CronJobs, ConfigMaps, deployment strategies, and a better foundation for GitOps. Start small on the single node and keep the control plane and deployment tooling minimal. Local storage can work well for SQLite, but make sure you have reliable backups and test recovery rather than treating the node’s disk as durable storage.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures