Well, technically true, but systemd is a whole lot more than 3000 lines...
I can see another binary in the demo video called apid, does that one not count?
Any comparison with Bottlerocket OS?
Well, technically true, but systemd is a whole lot more than 3000 lines...
I can see another binary in the demo video called apid, does that one not count?
Any comparison with Bottlerocket OS?
I don’t think the complexity it brings is required for Kubernetes.
Something along the lines of "...not needing a general purpose init system that integrates with logging, network and mounting, when all we are running is Kubernetes."
There's also a neat feature of podman that runs pods as systemd units, which is a nice intermediate step between a more traditional pet server and a full kubernetes cluster.
Although what I was thinking of was an article written somewhere and posted here in HN, and more a broad rethink on Kubernetes.
It can even kind of replace cron with timers, and no more mucking with grub. Also, true parallel init tasks. Love it.
I have systemd on the laptop I am typing on right now. Do I want it on some tiny embedded linux device? probably not.
I'm using projectbluefin.io for all my laptops/desktops and love it. Wouldn't want the same on single-purpose, production servers.
Notably the kubelet is also missing from the list because it's not built into the OS but pulled as needed from the correct version of Kubernetes requested.
Bottlerocket runs systemd and also runs 2 versions of containerd. One for the system and one for workloads. This (in theory) hardens the OS more, but in practice makes things extremely annoying to manage because you have to get a shell on the host to access the API.
disclaimer, I used to work at AWS on EKS and closely with the Bottlerocket team.
It makes sense that a lot of the other services in systemd depend on the init daemon, it provides a lot of baseline services and features that are used for the rest of it. As a matter of fact, I don't even know what other init daemon I would choose if I wanted similar features around system daemon management, as there's a lot in the surface area that is genuinely useful. Honestly, there's a lot of useful stuff for handling secrets, handling UNIX domain sockets, temporary files, sandboxing apps, setting resource limits, managing unit lifecycles, etc. There are a few features I find somewhat more dubious (personally I'm not sold on DynamicUsers) but by and large I actually like a lot of the surface area systemd's init daemon provides and if I were to use something else I'd want something in a similar ballpark.