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

11–20 of 120 posts

Re: Why Fix Kubernetes and Systemd?

#11

Post by yjftsjthsd-h »

rwmj wrote: post #4

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

Those certainly do look a little funny next to each other in the same list, but I think it's fair to argue that it's a situation where one tool is being used in cases that don't really overlap properly and it creates tension on both sides.

Edit after further reflection: Alternatively, perhaps both of those complaints could be summarized as poor ability to interoperate with other tooling, in which case they really do fit together.

Re: Why Fix Kubernetes and Systemd?

#12

Post by kris-nova »

tacitusarc wrote: post #5

I think the virtual machine comments are the one area that doesn’t make sense to me. Everything else seems reasonable.

Good call out. I glossed over a lot of the semantics. To be fair I could write an equally as long and drawn out article about why virtualization and a lightweight hypervisor is in scope for a process management mechanism.

Re: Why Fix Kubernetes and Systemd?

#13

Post by kris-nova »

yjftsjthsd-h wrote: post #11
rwmj wrote: post #4

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

Those certainly do look a little funny next to each other in the same list, but I think it's fair to argue that it's a situation where one tool is being used in cases that don't really overlap properly and it creates tension on both sides. Edit after further reflection: Alternatively, perhaps both of those complaints could be summarized as poor ability to interoperate with other tooling, in which case they really do…

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.

Re: Why Fix Kubernetes and Systemd?

#14

Post by sp332 »

kris-nova wrote: post #12
tacitusarc wrote: post #5

I think the virtual machine comments are the one area that doesn’t make sense to me. Everything else seems reasonable.

Good call out. I glossed over a lot of the semantics. To be fair I could write an equally as long and drawn out article about why virtualization and a lightweight hypervisor is in scope for a process management mechanism.

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?

Re: Why Fix Kubernetes and Systemd?

#15

Post by drewcoo »

rwmj wrote: 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.

Re: Why Fix Kubernetes and Systemd?

#16

Post by zozbot234 »

kris-nova wrote: post #12
tacitusarc wrote: post #5

I think the virtual machine comments are the one area that doesn’t make sense to me. Everything else seems reasonable.

Good call out. I glossed over a lot of the semantics. To be fair I could write an equally as long and drawn out article about why virtualization and a lightweight hypervisor is in scope for a process management mechanism.

Systemd can manage virtual machines already, see systemd-machined and machinectl. It has no support for clustered/distributed state as of yet, however.

Re: Why Fix Kubernetes and Systemd?

#18

Post by PuercoPop »

The author did a great job explaining the motivation for Aurae. I fully agree that there should be tighter integration between k8s and the init system on each node. But thinking of the desktop, having a gRPC server on PID 1 seems unnecessary. dbus is the RPC used by systemd. Is there a reason why gRPC instead of dbus[0]? Or is the goal of Aurae to replace systemd in the cloud/server Linux space?

[0]: dbus normally is used over a unix socket but afaik you can use dbus over a regular tcp socket

Re: Why Fix Kubernetes and Systemd?

#19

Post by mariusor »

kris-nova wrote: post #13
yjftsjthsd-h wrote: post #11

Earlier quoted context omitted.

Those certainly do look a little funny next to each other in the same list, but I think it's fair to argue that it's a situation where one tool is being used in cases that don't really overlap properly and it creates tension on both sides. Edit after further reflection: Alternatively, perhaps both of those complaints could be summarized as poor ability to interoperate with other tooling, in which case they really do…

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

Re: Why Fix Kubernetes and Systemd?

#20

Post by kris-nova »

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

Earlier quoted context omitted.

Good call out. I glossed over a lot of the semantics. To be fair I could write an equally as long and drawn out article about why virtualization and a lightweight hypervisor is in scope for a process management mechanism.

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 think having what kubernetes calls "namespaces" as an isolation boundary on each node running as a VM is the move here. It SHOULD run like this as a default. Pods are another story. Namespaces however -- should always have a VM boundary.

Getting the network device integration is going to be a big thing here. I suspect this means each namespace now has 1 or more NICs it will be able to leverage.

Firecracker went with the bridge mentality which I kind of disagree with: https://github.com/firecracker-microvm/firecracker/blob/main...

I want to see tools like Tailscale that leverage network devices as the "true network interface" find value in the guest namespace paradigm.

Hope this helps!

Post reply on HN