Author of the article here. One of the main reasons is that I want to update weechat without rebuilding the container, taking advantage of weechat's soft upgrade method: https://weechat.org/files/doc/weechat/stable/weechat_user.en...

And at that point, it may as well just be a normal Ubuntu server.

Ah I didn't know wechat could do that, but, I remember that from my irssi days.

I would personally consider that a bit of an anti-pattern (I would always want to have software upgrades tied to the container) but that makes sense!

As a long-time Docker-slonker I agree, however then that requires me to remember to upgrade the container images which means that it's harder to ensure that it's up to date. If you set up a cronjob to update the VMs packages and then a script that runs `/upgrade` on the weechat server every time the weechat package version changes, then you don't need to think.

Consider having Renovate handle this for you - using a git repo to apply your manifests will make it pull updated container images

I have this very easily setup to a set of simple commands which I can run to deploy new versions of packages.

Basically 3 paths for:

- things with well-maintained upstream helm charts (checks the latest version of the helm chart and updates helmfile)

- things where I wrote a helm chart (checks for the latest container image and updates the values.yaml)

- things where there is no (reasonable) public docker image, or my own software, where I have full CI/CD to build and deploy a new container image.

Probably takes me 15 minutes a week to keep my two personal clusters fully up-to-date.

So why not just make it a VM and skip k8s altogether?

Because I already have a kubernetes cluster with distributed storage. This way makes it somewhat standard with the rest of my setup. In SRE things the real enemy is when parts are unique in ways that conflict with the normal way of doing things. Look up at the "unique/standard" comment above and then take a moment to think about it. It sounds absurd from the first read; but when you realize that it allows me to reuse the hardware I have and take advantage of the second order properties I've done, then it makes more sense.

This is also why I design all my config files to use YAML. I've already got powerful tools to deal with its quirks (JSONSchema, yq, yamllint)

Mostly because VM tooling is stuck in the past.

You can do that in a container, no need for a VM.

    docker run -itd ubuntu:24.04
    ...
    docker exec -it df36 /bin/bash
    ...
    root@df365a3d2257:/# apt update
    ...
    root@df365a3d2257:/# apt upgrade
    ...

Then when the container gets rescheduled I'm suddenly running the old version of weechat

Wouldn’t an init container in the pod definition help here? Nice article btw!

Why not use Persistent Volumes and Nix container?