There's work in a new kublet replacement that moves things that would normally go into daemonset into systemd (or something like systemd).
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.
it could have been said without the x lines of code comment.
"lines of code" is so often used as a "disparagement" about software rather than a metric for understandability.
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."
The second I learned how to write systems unit files was the second I evicted initv/rc.d scripts from my mind. Well, okay, from my search terms at least ;-)
It can even kind of replace cron with timers, and no more mucking with grub. Also, true parallel init tasks. Love it.
Many of the binaries you see in the demo video are showing processes running from inside containers. There will be a lot more processes once you start pulling containers and starting containerized services.
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.
In retrospect, it would've saved a lot of trouble and misunderstandings if systemd had called the init daemon "systemd-init" to make it clear that not literally everything that is under the umbrella is part of the init daemon.
It's not the other way around though, which is a very important distinction. You don't need to use systemd-networkd or systemd-resolved or any manner of other things just to use the init daemon. The init daemon itself is extremely useful, and there are many machines that use the init daemon without most of the other services under the umbrella.
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.
Comments
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?
The systemd hate is getting long in the tooth now. It's not like it doesn't do anything with its line count, or that the code is obfuscated.
I’m actually a big fan of systemd. It’s an awesome, general purpose, and flexible init system.
I don’t think the complexity it brings is required for Kubernetes.
There's work in a new kublet replacement that moves things that would normally go into daemonset into systemd (or something like systemd).
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.
https://github.com/cpuguy83/containerd-shim-systemd-v1 to do this with containerd.
Also this one: https://github.com/virtual-kubelet/systemk
Although what I was thinking of was an article written somewhere and posted here in HN, and more a broad rethink on Kubernetes.
it could have been said without the x lines of code comment. "lines of code" is so often used as a "disparagement" about software rather than a metric for understandability.
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."
The second I learned how to write systems unit files was the second I evicted initv/rc.d scripts from my mind. Well, okay, from my search terms at least ;-)
It can even kind of replace cron with timers, and no more mucking with grub. Also, true parallel init tasks. Love it.
I'm not reading that as hate, I read that as criticising systemd in the context of a stripped down system designed to do one thing.
I have systemd on the laptop I am typing on right now. Do I want it on some tiny embedded linux device? probably not.
Thanks for clarifying because that was the vibe I was going for (not hate).
I'm using projectbluefin.io for all my laptops/desktops and love it. Wouldn't want the same on single-purpose, production servers.
So there is a quantum of criticism/observations about systemd that can be made but after that, no more is acceptable?
Many of the binaries you see in the demo video are showing processes running from inside containers. There will be a lot more processes once you start pulling containers and starting containerized services.
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.
In retrospect, it would've saved a lot of trouble and misunderstandings if systemd had called the init daemon "systemd-init" to make it clear that not literally everything that is under the umbrella is part of the init daemon.
Eh... Most of the other components have a hard dependency on the init part; I'm not convinced that they're all that separate.
It's not the other way around though, which is a very important distinction. You don't need to use systemd-networkd or systemd-resolved or any manner of other things just to use the init daemon. The init daemon itself is extremely useful, and there are many machines that use the init daemon without most of the other services under the umbrella.
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.