Live data from Hacker News

Why Fix Kubernetes and Systemd?

medium.com

31–40 of 120 posts

Re: Why Fix Kubernetes and Systemd?

#31
post #21

Earlier quoted context omitted.

that line is in your article as well, can you explain what it means? I am missing the reference

Its just a joke. Most folks from the U.S. who enjoy eating chicken tenders (breaded chicken breast with sauce) view it as a safe/comfort food that has never been a poor choice to eat. I feel the same way about systemd, its safe, reliable, and always a good choice for "dinner". Basically I am saying that systemd has withstood the test of time and has never disappointed me.

> I feel the same way about systemd, its safe, reliable, and always a good choice for "dinner".

> Basically I am saying that systemd has withstood the test of time and has never disappointed me.

IMO, when you make a reference specifically to chicken tenders, there is an implication of childishness - implying that systemd is a bit of a toy implementation. It doesn't sound like you mean that particular interpretation.

It would be the same if you mentioned red jello, milk boxes, capris suns, fruit snacks, or any other stereotypically children's food.

Re: Why Fix Kubernetes and Systemd?

#32
post #26
post #8

I find kubernetes - systemd overlap angle as a very valid point. When I first started to learn kubernetes more often than not I was thinking 'hey, we can do that with systemd as well!'

Same - we now use systemd to sandbox our apps, set resource limits, hide the rest of the system, mount read-only FS, etc. Add a custom SELinux policy for your service, and you get a compelling alternative to containerization (at least at runtime).

Do you have a blog perchance? I'd love to read more about this, maybe with fully-featured examples.

Re: Why Fix Kubernetes and Systemd?

#34
post #21

Earlier quoted context omitted.

that line is in your article as well, can you explain what it means? I am missing the reference

Its just a joke. Most folks from the U.S. who enjoy eating chicken tenders (breaded chicken breast with sauce) view it as a safe/comfort food that has never been a poor choice to eat. I feel the same way about systemd, its safe, reliable, and always a good choice for "dinner". Basically I am saying that systemd has withstood the test of time and has never disappointed me.

Ah, that's funny -- I took it to mean like... an OK in a pinch and generally unobjectionable, but not something to be excited about. Which is basically how I feel about systemd (as someone who doesn't do systems engineering or run a distro, so, probably I don't see where it becomes exciting)

Re: Why Fix Kubernetes and Systemd?

#35
post #15
post #4

Lack of Unix philosophy [...] Missing rest/gRPC/json API OK ...

I think those are meant differently. I don't think "Unix philosophy" means "communicate via streams" in this context. I think it means things like the single responsibility principle. Once we introduce APIs, we can't just chain services together with pipes. But I agree that this use of "Unix philosophy" is confusing.

That section of the post seemed to be generating a lot of friction. I revised the language a little bit.

I think the original sound-byte I was trying to capture was "do one thing" which in my opinion neither Kubernetes nor Systemd do. To be fair -- neither would Aurae. So I just scrapped the entire comment.

I wasn't trying to nitpick systemd as much as I was trying to draw attention to the fact that it does in fact -- get nit picked -- and often unnecessarily.

Re: Why Fix Kubernetes and Systemd?

#36
post #26
post #8

I find kubernetes - systemd overlap angle as a very valid point. When I first started to learn kubernetes more often than not I was thinking 'hey, we can do that with systemd as well!'

Same - we now use systemd to sandbox our apps, set resource limits, hide the rest of the system, mount read-only FS, etc. Add a custom SELinux policy for your service, and you get a compelling alternative to containerization (at least at runtime).

Yes, I reached the same conclusion when setting up the (fairly simple) servers needed for my company. SystemD + standard scripting can take you a long way, perhaps with Ansible if you need more. I've only used Kubernetes a bit, but I used Borg for quite some years. A fantastic system if you need an incredibly regularized prod environment with lots of replicas for everything i.e. if you're trying to replicate Google's internal setup. Extremely painful the moment you need to step outside that world. I had to do that once or twice at Google and quickly started wishing I could just grab some normal Linux machines and install some packages that depended on Apache and a DB.

Actually said company makes packaging tools and Linux packages are fairly simple so we started with the ability to make server packages that use systemd.

That support is still there and makes it fairly easy to build a signed apt repository from build system outputs (e.g. jars, native binaries), or even by re-packaging an existing server download [1]. What you get out is debs that start up the service on install, ensure it starts automatically at boot, restarts it across upgrades and shuts it down cleanly if the machine shuts down. Such packages can be built from any machine including Windows and macOS. The nice thing about doing packaging this way is you can specify dependencies (both install and service startup) on things like postgresql, and you get a template nginx/apache2 reverse proxy config as well. Unfortunately there doesn't seem to be a way to make those templates 100% usable out of the box due to limits in their config languages, but it's still nice to have.

There's also pre-canned config snippets for sandboxing, setting up cron jobs and other useful systemd features [2]. We package and run all our servers this way. One big rented colo machine is sufficient right now. If there was a need for clustering we'd just point the machines at the same apt repo and use some shell scripting or Ansible, I think.

There's lots of tools for making Docker containers out there already, but I never really clicked with Docker for various reasons. Conveyor is mostly focused on desktop apps but perhaps there's more demand for easily making systemd using packages than I thought. The server side support is there and we dogfood it, but isn't really advertised and it lacks a tutorial.

[1] https://conveyor.hydraulic.dev/2.1/tasks/server/

[2] https://conveyor.hydraulic.dev/2.1/stdlib/systemd/

Re: Why Fix Kubernetes and Systemd?

#37

Earlier quoted context omitted.

Its just a joke. Most folks from the U.S. who enjoy eating chicken tenders (breaded chicken breast with sauce) view it as a safe/comfort food that has never been a poor choice to eat. I feel the same way about systemd, its safe, reliable, and always a good choice for "dinner". Basically I am saying that systemd has withstood the test of time and has never disappointed me.

> I feel the same way about systemd, its safe, reliable, and always a good choice for "dinner". > Basically I am saying that systemd has withstood the test of time and has never disappointed me. IMO, when you make a reference specifically to chicken tenders, there is an implication of childishness - implying that systemd is a bit of a toy implementation. It doesn't sound like you mean that particular interpretation.…

Good feedback. I went ahead and removed the reference and just called out my sentiment directly.

Re: Why Fix Kubernetes and Systemd?

#38
post #8

I find kubernetes - systemd overlap angle as a very valid point. When I first started to learn kubernetes more often than not I was thinking 'hey, we can do that with systemd as well!'

I often noticed this as well. After reading the article I wonder: Would it be feasible to write a kubernetes-shim for systemd to reduce the overlap instead of reinventing everything? This would not fix any of the valid criticism the author has of systemd but instead make it do even more things. Nevertheless I somehow find the idea very intriguing

Re: Why Fix Kubernetes and Systemd?

#39

Earlier quoted context omitted.

Yeah -- I think I was just reciting what I hear folks say a lot. Basically its IPC and a stable interface for clients that is the core of the concern. Thats really what the takeaway is.

But Systemd has IPC and a stable interface for clients, it's "the D-Bus interface of systemd"[1]. I would think that exposing that over http would be a little reckless, but I'm sure one can create a proxy that can do it in a "secure"-ish way. [1] https://www.freedesktop.org/software/systemd/man/org.freedes...

There is this:

    systemctl --host=whatever.abc status apache2
It uses ssh and UNIX domain socket forwarding behind the scenes. There's a writeup of how to do this with minimal privs here:

https://sleeplessbeastie.eu/2021/03/03/how-to-manage-systemd...

If you want to speak the protocol without the systemctl program then you can do the same trick. Use an SSH library, connect to the dbus socket and connect to systemd. You do need a dbus library though. They are less common than HTTP stacks.

Re: Why Fix Kubernetes and Systemd?

#40
post #8

I find kubernetes - systemd overlap angle as a very valid point. When I first started to learn kubernetes more often than not I was thinking 'hey, we can do that with systemd as well!'

This is how fleet on CoreOS was designed. It just managed systemd containers across your nodes (IIRC its been a while)
Post reply on HN