Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Fix Kubernetes and Systemd?

medium.com

Post reply on HN
Print view View original

111–120 of 120 posts

Re: Why Fix Kubernetes and Systemd?

#111

Post by eternityforest »

andrewstuart3 wrote: post #79
andrewstuart wrote: post #73

systemd is better than "fine" or "great" - systemd is awesome. systemd is a real power tool and the more I learn about it the better I like it. When you need to get something done, systemd often as not has your back. Simple example - recently I needed to ensure a given service could not send more data than a given limit. Easy - systemd includes traffic accounting on a per service basis - all I needed to do was switch…

Those are common arguments for systemd, similarly to other batteries-included software. But the opponents of such software (and of systemd in particular) tend to expect the whole system being like that: having all the useful components playing nicely together, and easily swappable in addition to that. Which is harder to achieve, but supposed to be nicer.

The trouble is that the system as a whole becomes a product that requires testing and bugfixes. When things are swappable, every system is unique and has only been built a few times.

Plus, it creates fragmentation instead of concentrating efforts on one project.

It's easy to get situations like "I need feature F but that's only in B, we use A because C needs it".

Use of any features outside the lowest common denominator quickly makes things nonswappable.

Re: Why Fix Kubernetes and Systemd?

#112

Post by Terretta »

_pob wrote: post #87
Frost1x wrote: post #60

Earlier quoted context omitted.

>I call it CVops instead of DevOps. CV being another word for resume... I might borrow this, although I'm leaning towards Res[ume]Ops

I call it RDD - Resume Driven Development.

About 12 years too late to claim RDD.

Here's Tom Preston-Werner's "Readme Driven Development" in 2010:

https://news.ycombinator.com/item?id=17427593

https://tom.preston-werner.com/2010/08/23/readme-driven-deve...

// Same energy as Amazon 'Working Backwards':

https://www.allthingsdistributed.com/2006/11/working_backwar...

Re: Why Fix Kubernetes and Systemd?

#113

Post by pjmlp »

patrickthebold wrote: post #52
politelemon wrote: post #29

Earlier quoted context omitted.

I noticed the same but came away with a different conclusion, "hey, k8s is reimplementing the OS.". In other words, concepts which have existed for years, battle tested and well known, are new and untested in the k8s world.

But k8s is distributed across several computers. If you could have Linux manage resources and run processes across several computers I think people would do that.

As in,

https://en.wikipedia.org/wiki/Beowulf_cluster

https://en.wikipedia.org/wiki/MOSIX

That is the thing with repeating history.

Re: Why Fix Kubernetes and Systemd?

#114

Post by sph »

andrewstuart wrote: post #81
andrewstuart3 wrote: post #79

Earlier quoted context omitted.

Those are common arguments for systemd, similarly to other batteries-included software. But the opponents of such software (and of systemd in particular) tend to expect the whole system being like that: having all the useful components playing nicely together, and easily swappable in addition to that. Which is harder to achieve, but supposed to be nicer.

https://images.news18.com/ibnlive/uploads/2021/12/spiderman-... It's like I'm in a hall of mirrors...... It's the integration of systemd, the common approach that yields the giant payoff. I understand the "lots of independent utilities" Unix philosophy but systemd's consistent broad scope yields increasing benefits.

Sometimes a monolith is better.

See also vim vs Emacs.

Re: Why Fix Kubernetes and Systemd?

#115

Post by vetinari »

andrewstuart3 wrote: post #99
customkitchen wrote: post #93

Earlier quoted context omitted.

You can still do that with systemd though. If you want to swap out some components then just don't use those features in your unit file, instead have your unit file run a shell script that uses your components. The "opposition" to systemd has never made any sense to me on any level.

Can't speak for the whole systemd "opposition", especially since I'm not really a part of it, but I think it is rather a matter of multiple implementations sharing standardized interfaces, versus a single implementation with its custom interfaces: compare systemd's timers to cron implementations sharing crontab format, or systemd journal to syslog implementations, sharing its standardized protocols. With a single int…

> compare systemd's timers to cron implementations sharing crontab format, or systemd journal to syslog implementations, sharing its standardized protocols.

Well, but then you must be aware that you are leaving lot of effectiveness, unification and deduplication on the table.

See, many people think of systemd as if it was init replacement that grew timer support too. They are looking at the wrong level of abstraction: it is an event machine, that manipulates units when events happen. That event might be boot to certain runlevel, timer, hotlplug, incoming request on socket, dbus activation, whatever.

By cutting and dragging out one of the event handlers outside into special-cased, custom flow component that duplicates existing functionality anyway, you are ending up with a worse system.

Re: Why Fix Kubernetes and Systemd?

#116

Post by customkitchen »

mike_hearn wrote: post #39
mariusor wrote: post #19

Earlier quoted context omitted.

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…

>They are less common than HTTP stacks.

libsystemd includes a d-bus library for exactly this reason.

Re: Why Fix Kubernetes and Systemd?

#117

Post by customkitchen »

andrewstuart3 wrote: post #99
customkitchen wrote: post #93

Earlier quoted context omitted.

You can still do that with systemd though. If you want to swap out some components then just don't use those features in your unit file, instead have your unit file run a shell script that uses your components. The "opposition" to systemd has never made any sense to me on any level.

Can't speak for the whole systemd "opposition", especially since I'm not really a part of it, but I think it is rather a matter of multiple implementations sharing standardized interfaces, versus a single implementation with its custom interfaces: compare systemd's timers to cron implementations sharing crontab format, or systemd journal to syslog implementations, sharing its standardized protocols. With a single int…

>compare systemd's timers to cron implementations sharing crontab format, or systemd journal to syslog implementations, sharing its standardized protocols. With a single interface and different implementations, you can easily swap those, but with a monolith like systemd you are mostly stuck if the software actually makes use of it.

But this still makes no sense. You can just develop another thing that converts from the systemd format to something else, or make the other daemon capable of loading the systemd format directly. It isn't even hard to do this, I've seen various things do it. And depending on where you are the systemd formats are arguably more standardized than old crons and sysloggers in the current year.

Re: Why Fix Kubernetes and Systemd?

#118

Post by ghoward »

pjmlp wrote: post #107
ghoward wrote: post #103

Earlier quoted context omitted.

Well, yeah, just because the philosophy isn't perfectly followed doesn't mean it's not good to strive for in certain cases. This is one of those cases because it means the build system will be more easily extended and still be simple.

The philosophy was never a thing in commercial UNIXes, just got picked up by the FOSS movement from a book remark as if it ever had been the case.

What's your problem with the Unix philosophy? Also, I never said it applied in every case, just that it's useful to have in this one.

Re: Why Fix Kubernetes and Systemd?

#119

Post by doublerebel »

e1g wrote: post #26
betaby wrote: 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).

This sounds like SMF on Solaris (and derivatives). I used that pattern successfully on Illumos/SmartOS for several years.

Re: Why Fix Kubernetes and Systemd?

#120

Post by golf_mike »

kris-nova wrote: post #47
golf_mike wrote: post #33

Great stuff! So would you say that, in a way this is implementing a node-level control plane?

I think the term "control plane" is overloaded but -- yes. I just think of it as a node API more than anything. Having a comprehensive set of features/library/API for the node seems like it would unlock a lot of features we are seeing in large service mesh and large platform shops are turning to sidecars to solve.

Completely agree. You make some great points in the article and Ill be keeping an eye on the project(s). Good stuff, thanks!
Post reply on HN