Blog on 5ok — sysadmin, devops, hosting

Why we moved to k3s

Thu, 18 Jun 2026 00:00:00 +0000

Three years ago we set up full Kubernetes on a set of our own servers. It was the right call — at the time. We had a team that knew what it was doing and applications that benefited.

Over time it became clear we were using a fraction of what Kubernetes offered. And maintaining the control plane itself started eating more time than running the applications on top of it.

Bare-metal to Proxmox with no downtime

Mon, 11 May 2026 00:00:00 +0000

The client had four physical servers, one application each. A classic 2015–2018 setup: one server = one service, no virtualisation, no backups beyond rsync to a NAS.

The brief: get it onto Proxmox, gain snapshots and live migration, and keep downtime under a few minutes per service.

The plan

The approach we use almost every time:

Build a new Proxmox cluster alongside (three nodes, Ceph pool).
For each service create a VM and deploy from configuration management — not by cloning the old disk.
Run both instances in parallel, synchronise data one-way.
Switch DNS / load balancer, watch, keep the old instance on standby for a week.

Point 2 matters. Cloning a physical disk into a VM (P2V) is fast, but it carries ten years of sediment with it — old packages, manual /etc edits nobody documented. If you have Ansible, rebuild instead.

systemd timers instead of cron

Sat, 21 Mar 2026 00:00:00 +0000

Cron has one enormous advantage: everyone knows it. And one disadvantage: when it fails, you find out by email to root@localhost, which nobody reads.

systemd timers fix exactly that.

The basics

A timer is two files — .service (what runs) and .timer (when).

# /etc/systemd/system/backup.service
[Unit]
Description=Nightly backup
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup nightly

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

What cron can’t do

Persistent=true — if the machine was off at the scheduled time, the job runs at next boot. Cron just skips it.