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

91–100 of 120 posts

Re: Why Fix Kubernetes and Systemd?

#91

Post by up2isomorphism »

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…

It seems LP squad is getting old enough to publicly show their victory in the cooperate space . Even considering that, to call it “awesome” is still cringing.

No, Systemd is anti-Unix and unnecessary. Its demand never comes from the community and many non-systemd distributions work much better than redhat, like alpine/gentoo/Slackware.

Re: Why Fix Kubernetes and Systemd?

#92

Post by gravypod »

kris-nova wrote: post #20
sp332 wrote: post #14

Earlier quoted context omitted.

I get that VMs have certain advantages, but I was surprised that they are the default (only?) choice for namespace management. Is it that unusual for containers to mix and match, e.g. have different filesystem namespaces, but share a network namespace?

This is a good call out. One of the philosophies of the project I am trying to maintain is instilling my opinion into things while still having the project play nice with the rest of the ecosystem. On one hand I over-engineer a systemd hypervisor that is only meaningful to me. On the hand I create another ambiguous junk drawer that is meaningless without a team of experts to tell you how to configure everything. I th…

To me it sounds like it might incur a lot of overhead for minimal gains. At the end of the day you are trusting both the software and hardware implementation for isolation when using virtualization. Virtualization comes with a substantial relative performance penalty.

In an ideal world, where virtualization has no performance penalty, it might make sense to wrap everything in VMs but in the real world I think having the option to switch isolation mechanisms might be the best idea.

Some may need "better" (subjective) security and opt for VMs which could be the default platform. Others may be fine with something more lax like gvisor or even just having different users for each namespace.

Re: Why Fix Kubernetes and Systemd?

#93

Post by customkitchen »

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.

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.

Re: Why Fix Kubernetes and Systemd?

#94

Post by arinlen »

master_crab wrote: post #90
arinlen wrote: post #89

Earlier quoted context omitted.

> 'hey, we can do that with systemd as well!' But does systemd do these things in a user-friendly way? Or at least as friendly as Kubernetes? Unfortunately, no. Don't underestimate the importance of UX.

Systemd do things in as friendly a way as kubernetes? No one should ever confuse kubernetes for user-friendly.

> No one should ever confuse kubernetes for user-friendly.

Kubernetes is user-friendly, specially when compared to each and any of its alternatives.

And moreso when compared with systemd.

We live in a day and age where it's possible to get a whole web app up and running in a Kubernetes cluster from a fresh Ubuntu install with a single snap installation and a kubectl apply -k . How long would it take to get systemd to containerize a single app?

Re: Why Fix Kubernetes and Systemd?

#95

Post by ghoward »

I really don't get why people make things so complicated.

Here's how to fix Kubernetes and systemd: make a non-sucky build system and then use it to build systems.

Systemd builds a running system. Kubernetes builds a distributed system. Make a build system that can build both. Then you're golden.

And it will also not be monolithic (i.e., it will follow the Unix philosophy) because a build system just hooks together smaller tools.

Yes, the build system needs to be able to respond to events, but that's a simple extension.

Disclaimer: I'm currently building such a build system. I wish the author luck, but I am a competitor.

Edit: I might have sounded snarky. I'm not trying to be; it's just late at night. The author has a lot of good ideas; I just think that the ideas could be followed just a little further to something great.

Re: Why Fix Kubernetes and Systemd?

#96

Post by dilyevsky »

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…

The real question though is can it read emails?

Re: Why Fix Kubernetes and Systemd?

#97

Post by tadfisher »

arinlen wrote: post #94
master_crab wrote: post #90

Earlier quoted context omitted.

Systemd do things in as friendly a way as kubernetes? No one should ever confuse kubernetes for user-friendly.

> No one should ever confuse kubernetes for user-friendly. Kubernetes is user-friendly, specially when compared to each and any of its alternatives. And moreso when compared with systemd. We live in a day and age where it's possible to get a whole web app up and running in a Kubernetes cluster from a fresh Ubuntu install with a single snap installation and a kubectl apply -k . How long would it take to get systemd to…

systemd-nspawn -x -a [command] [args]

Re: Why Fix Kubernetes and Systemd?

#98

Post by sass_muffin »

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).

How do you scale across multiple computers reliably?

Re: Why Fix Kubernetes and Systemd?

#99

Post by andrewstuart3 »

customkitchen wrote: post #93
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.

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 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.

I think there are other reasons why people dislike systemd (and recalling a few articles with people ranting about it; I think there are many around), and usefulness of standards and alternatives/choice wouldn't necessarily make sense either, but here is at least one of the ways to view it.

As for init scripts, I think it can be even a bit nicer than that, since systemd provides some backward compatibility with sysV-style init scripts [1], but in that systemd acts almost like a swappable implementation.

[1] https://www.freedesktop.org/software/systemd/man/systemd-sys...

Re: Why Fix Kubernetes and Systemd?

#100

Post by dijit »

xani_ wrote: post #84
shrubble wrote: post #59

Earlier quoted context omitted.

You're not the one who is insane. Assume you have a $25k budget for a Dell server and $20k for attached storage . Go see what you can build on Dell.com's online configuration tool. You could colocate everything you can buy for $45k in a half rack at a reputable datacenter for $750 per month including a burstable to 1gbit internet connection. I estimate that at least 75% of the people who are commenting on these threa…

Yes but you need semi-competent people to manage it and have actual ops dept. Then again we got a bunch of racks and our ops dept is 3 people. We have few dozen different apps running on it, anything from "just a wordpress" to k8s cluster (mostly because our customers want us to deploy app they are paying us to develop on k8s). So far the only actual value k8s provides is self-service aspect of it. Nothing that is ru…

I’ve never seen a functioning org that has not had dedicated ops people for their cloud systems.

AWS skills are as arcane or more than traditional hardware management skills; I’m not sure I could make the argument in good faith that you need less people overall with cloud.

An (anecdotal) example: I worked on an e-commerce SaaS platform responsible for 1% of internet traffic in 2011 with a team of 6 sysadmins, with 60~ developers working purely on the product.

My last company had 23~ “SREs” (that did not code aside from DSLs) operations staff handling AWS deployments.

Post reply on HN