feat: add support for k0s

[eznix86]

fixes #122

[ctrox]

Thanks for the PR! Looks good on a first skim, I'll validate this later and do a full review. Eventually it would be very nice if we had some way to validate the installer in e2e tests for all the different distros. But no need for you to add anything for now, I'll give this a try at some point later.

[eznix86]

Yes, also I was thinking also maybe we should have different file like distros/generic distros/k0s etc... so we can add more with time. I wanted to add for https://github.com/portainer/kubesolo, but i want to see for this PR first.

[Matthew-Beckett]

@ctrox can you allow builds for this so I can test?

[ctrox]

@ctrox can you allow builds for this so I can test?

I approved the checks and also pushed the branch myself as PRs can't trigger image pushes (would be a bit problematic if they could).

[Matthew-Beckett]

I just tested this, when the manager started up it crashed out failing to find PEM data in the certificate input.

prepare-bpf-fs bpf on /sys/fs/bpf type bpf (rw,relatime,mode=700)
installer 2025/12/27 21:13:07 installed criu binaries from ghcr.io/ctrox/zeropod-criu:v4.2
installer 2025/12/27 21:13:07 installing runtime for k0s
installer 2025/12/27 21:13:07 runtime already configured, refreshing zeropod drop-in
manager {"time":"2025-12-27T21:13:19.338895728Z","level":"INFO","msg":"starting manager","metrics-addr":":8080","node-server-addr":":8090","version":"","revision":"","go":"go1.25.5"}
installer 2025/12/27 21:13:07 installed runtime
manager {"time":"2025-12-27T21:13:19.33918563Z","level":"INFO","msg":"no sandbox pids found"}
manager {"time":"2025-12-27T21:13:19.379178703Z","level":"INFO","msg":"init","component":"podlabeller"}
installer 2025/12/27 21:13:07 installed runtimeClass
manager {"time":"2025-12-27T21:13:19.379193105Z","level":"INFO","msg":"init","component":"podscaler"}
installer 2025/12/27 21:13:07 installed ca cert
installer 2025/12/27 21:13:07 installer completed
manager {"time":"2025-12-27T21:13:19.379198395Z","level":"INFO","msg":"init","component":"event_creator"}
manager {"time":"2025-12-27T21:13:19.379343053Z","level":"ERROR","msg":"creating node server","err":"initializing TLS certificates: tls: failed to find any PEM data in certificate input"}
stream closed: EOF for zeropod/zeropod-node-9pj2g (prepare-bpf-fs)
stream closed: EOF for zeropod/zeropod-node-9pj2g (installer)
stream closed: EOF for zeropod/zeropod-node-9pj2g (manager)

UPDATE: scratch that, I'd deployed it in the wrong namespace and it always expects zeropod-system and I'd deployed it in zeropod

[ctrox]

Tested the installer on a fresh k0s cluster, nice work! Just a few comments regarding the path handling which could be simplified.

[ctrox]

any reason this can't be in the existing var block?

[eznix86]

It cannot be a const since it uses fmt.Sprintf. Main has the same line now anyway, happy to move it into the test func if you prefer.

[eznix86]

Will address the changes :)

[ctrox]

@Matthew-Beckett

UPDATE: scratch that, I'd deployed it in the wrong namespace and it always expects zeropod-system and I'd deployed it in zeropod

Oh would be nice if that would work out of the box. Created #127 to address this.

[andrelohmann]

Hi @eznix86 @ctrox , I have a PR waiting, that is integrating microk8s (#128) with a second branch with big documentation updates (kybernate#2) - still in progress.

As there are some overlapping changes on the installer/main.go (seems like me and @eznix86 are using the same code agent ;-), I'd like to integrate the k0s integration into my merge (if it is ok) and in the same time, add the regarding k0s runtime documentation (following my current first draft).

I want to go on with development, adding cuda checkpointing support (as I need this for a different project I want to work on), but I want to avoid forking zeropd and have them diverging from each other.

[eznix86]

Sorry for the late reply, made some changes!