I JUST was finally in a position to muster enough courage to open source a fresh project.
The Aurae Runtime project gets the bold goal of replacing systemd, while also making some improvements to the core the different parts of Kubernetes.
I have already been focusing on the project very casually in my own free time. Among the questions I have already been getting asked as more people join Aurae is excatly why are you achieving this? How come Aurae exist?
I believe most individuals are thinking about understanding precisely what is the motivation for the project. Additionally why is Aurae unique? Where could it be different not to mention how come it even exist to begin with?
So lets focus on some problem statements, you can browse the original whitepaper on Aurae.
There exists a duration of arguments both for and against systemd. I wouldnt be foolish enough to attempt to pack all those arguments into this short article. The point I’m attempting to make here’s that generally systemd is excellent.
However from the enterprise platform perspective there are several what to call out. I’m approaching these topics with cloud enterprise infrastructure at heart. These gripes might not be highly relevant to most desktop/hobbyists.
My higher level concerns with systemd are:
- Monolithic architecture. It can a whole lot, and there’s a high barrier to entry.
- It assumes there exists a user in userspace. (EG: Exposing D-Bus SSH/TCP)
- Bespoke/esoteric mechanics with the toolchain. There exists a lot to understand, with bespoke client D-Bus stacks.
- IPC mechanisms with D-Bus arent built for multi tenancy interaction.
- Binary logs could be difficult to control in case the system is broken and systemd can’t start.
- A few of the assumptions systemd makes about a host break down in the container. EG: pid namespaces and running as pid 1.
Edit: After some joyful and illustrious comments on hacker news I returned and added even more thoughts here. I would like to be clear generally systemd is okay. I dont think systemd may be the problem. However if we have been tackling a fresh node, I really do believe most of the features that systemd manages today could be offered up to control plane in a multi-tenant and standardized way with an improved group of controls. These features are effectively what would constitute the Aurae standard library.
Now where you lose me is where Kubernetes started duplicating scheduling, logging, security controls, and process management a cluster level and fragment my systems yet-again. For me Kubernetes has re-created most of the same semantics of systemd only at the cluster level. That is difficult for both operators in addition to engineers building along with the machine.
This means being an operator, engineer, and end-user I find yourself having to learn, and manage both simultaneously.
The duplication of scope is among the main motivating reasons for Aurae. I really believe that distributed systems must have more ownership of what’s running on a node. I’m not convinced that systemd may be the way forward to perform that goal. This is actually the first reason I started Aurae.
Kubernetes includes a node daemon referred to as the kubelet that runs on each node in a cluster. The Kubelet may be the agent that manages an individual node inside a broader cluster context.
The kubelet runs being an HTTPs server, with a mostly unknown and mostly undocumented API. The majority of the Venn diagram above concerns the Kubelet way more than Kubernetes itself. Put simply the Kubelet may be the Kubernetes-aware systemd alternative that runs on a node.
Just what exactly schedules the kubelet and keeps it running?
That might be systemd.
Just what exactly schedules the node services that the kubelet depends upon?
That might be systemd.
For instance in probably the most simple Kubernetes cluster topology systemd is in charge of managing the kubelet, system logging, the container runtime, any security tools, and much more.
However any platform engineer will let you know that the architecture above is definately not enough to use a production workload.
Oftentimes platform teams may also have to manage services such as for example Cilium or HAproxy for networking, security tools such as for example Falco, and storage tools such Rook/Ceph. Many of these require privileged usage of the nodes kernel, and can mutate node level configuration.
While these services can be scheduled from Kubernetes there are several noteworthy concerns which begs the question should they be scheduled from Kubernetes?
Do we actually want to privilege escalate our core services into place from the DaemonSet? What goes on in case a node can’t talk to the control plane? What goes on if the container runtime falls? What else is running on a node that’s managed beyond Kubernetes? What else can be done to perform on a node that’s currently not supported by Kubernetes?
The node ought to be simple. Managing node services ought to be simple. We have to manage node services exactly the same way we manage cluster services.
Most of these thoughts kept me up during the night for years. For me there exists a boat load of untapped opportunity that the is prevented from innovating around, due to the fact it really is hidden from the scope of Kubernetes APIs.
Why do I wish to tackle systemd, the kubelet, and the node? Why did I opt to start Aurae?
To be candid I wish to simplify systems that operate on a node and I’d like the Node to be managed in exactly the same place the others of my infrastructure is managed.
I dont think a platform engineer must have to control both a systemd unit, in addition to a Kubernetes manifest for node resources and when we do they ought to work very well together and become aware of one another.
Considering the stack it became obvious if you ask me that there is a chance to simplify the runtime mechanics about the same node. WHEN I begun to explore the architecture more, the more I realized that the sidecar pattern was quite evident that another thing was wrong with my systems.
While there isnt necessarily anything intrinsically wrong with running sidecars themselves, I really do wonder if the uptick in sidecar usage is remnants of an anti-pattern? Do we should inject logic with an application to be able to accomplish some lower level basics such as for example authentication, service discovery, and proxy/routing? Or do we just need better controls for managing node services from the control plane?
I wonder if having a far more flexible and extensible node runtime mechanism could begin to check the boxes for these kinds of lower level services?
Sidecars ought to be Node Controllers.
Aurae calls out a straightforward standard library designed for each node in a cluster. Each node will undoubtedly be re imagined so that it is autonomous and made to work throughout a connectivity outage on the edge. Each node gets a database, and you will be in a position to be managed independently of hawaii of the cluster.
The Aurae standard library will observe suite of Kubernetes API for the reason that it’ll be modular. Components will be able to be flipped out according to the desired outcome.
The many subsystems at the node level will undoubtedly be implementable and flexible. Scheduling something such as for example HAProxy, a security tool like Falco, networking tools such as for example envoy or cilium will observe a familiar pattern of bringing a controller to a cluster. Nevertheless the state of the node will persist whatever the status of the control plane running at the top.
By simplifying the node mechanics and bringing container runtime and virtual machine management into scope we are able to also knock additional heavy hitters which have been ailing the Kuberenetes networking ecosystem for quite a while.
- IPv6 automagically.
- We are able to support network devices because the primary interface between a guest and the planet.
- We are able to support multiple network devices for every guest.
- We are able to bring NAT traversal, proxy semantics, and routing into scope for the core runtime.
- We are able to bring service discovery to the node level.
- We are able to bring authentication and authorization to the socket level between services.
There exists a lot to unpack here, however you start with a few of the basics first such as for example giving a network device to every guest we have to have the ability to iterate on the coming years.
I promised myself I wasnt likely to put the term Security in a box and say that has been going to be adequate. I wish to explain how this technique will potentially be safer.
We are able to standardize just how security tools are managed and how they operate. Fundamentally modern runtime security tools leverage some mechanism for instrumenting the kernel. (Such as for example eBPF, Kernel Modules, netlink, Linux audit, etc) We are able to bring generic kernel instrumentation into scope of Aurae and offer controls on what higher order services can leverage the stream. It is a win for both security in addition to observability.
Additionally we are able to create further degrees of isolation by leveraging virtual machine mechanics by bringing VMs to the party aswell.
Aurae intends to schedule namespaced workloads within their own virtual machine isolation sandbox following a patterns organized in Firecracker with the jailer. Put simply, each namespace gets a VM.
This feature would push multi tenancy a step of progress, while also addressing most of the other concerns in the above list like the sidecar antipattern.
Imagining a cluster aware or API centric process scheduling mechanism in a cloud environment is exciting.
Pausing/Debugging with ptrace(2)
For instance systemd integrates will with other low degrees of the stack such as for example ptrace(2). Having a cloud-centric process manager like Aurae means we’re able to explore paradigms such as for example pausing and stepping through processes at runtime with ptrace(2). We are able to explore eBPF features at the host level, and namespace virtualization level. All this could possibly be exposed at the cluster level and managed with native authn and authz policies in the enterprise.
Kernel Hot Swapping with kexec(8)
Even mechanisms like Linuxs kexec(8) and the capability to hot-swap a kernel on a machine could possibly be subjected to a control plane such as for example Kubernetes.
SSH tunnels certainly are a reliable, safe, and effective method of managing one-off network connections between nodes. The opportunity to manage these tunnels with a metadata service make it possible for point-to-point traffic is another feature that may be subjected to higher order control plane mechanisms like Kubernetes.
A lot more than just Kubernetes
Having a couple of node-level features exposed over gRPC would potentially enable a lot more than only a Kubernetes control plane.
Lightweight scheduling mechanisms will be possible to perform against a pool of Aurae nodes. Kubernetes is a single exemplory case of how this may be enabled.
So we started coding the mechanics of the systems out, and we made a decision to write Aurae in Rust. I really believe that the node systems will undoubtedly be close enough to the kernel that having a memory safe language like Rust can make Aurae as extensible since it must be to win the Node.
Aurae comprises several fundamental Rust projects, all hosted on GitHub.
Auraed (The Daemon)
Auraed may be the main runtime daemon and gRPC server. The intention is because of this to displace pid 1 on modern Linux systems, and ultimately replace systemd forever.
Aurae (The Library)
Aurae is really a Turing complete scripting language that resembles TypeScript that executes contrary to the daemon. The interpreter is written in Rust and leverages the gRPC rust client generated from the shared protobuf spec. We anticipate creating a LSP, syntax highlighting, and much more because the project grows.
Client Libraries (gRPC)
Your client libraries are auto generated and you will be supported because the project grows. For the present time the only real client-specific logic like the convention on where TLS material is stored lives in the Aurae repository itself.
We shall need to create a Kubelet and Kubernetes shim at some time that’ll be step one in bringing Aurae to a Kubernetes cluster. We shall likely follow the task in the virtual kubelet project. Eventually all the functionality that Aurae encapsulates will undoubtedly be exposed on the gRPC API in a way that either the Kubernetes control plane, or perhaps a simplified control plane can take a seat on top.
Aurae is likely to show into yet-another monolith with esoteric controls exactly like systemd. Way more Aurae can be libale to show into another junk drawer like Linux system calls and Linux capabilities. I wish to approach the scope cautiously.
I’ve considered most of the lowest level computer science concerns, and the best degree of product must form an impression on scope.
- Authentication and Authorization using SPIFFE/SPIRE identity mechanisms right down to the Aurae socket.
- Certificate management.
- Virtual Machines (with metadata APIs) leveraging Firecracker/QEMU.
- Lightweight Container Runtime (simplified cgroup and namespace execution similar runc, podman, or the Firecracker jailer).
- Host level execution using Systemd style security controls (Seccomp filters, system call filtering).
- Network device management.
- Block device management.
- stdout/stderr bus management (pipes).
- Node filesystem management.
You will see more impressive range subsystems of Aurae such as for example scheduling that’ll be stateful wrappers round the core. Nevertheless the core remains fundamental to all of those other system.
For instance a Kubernetes deployment may reason about where you can schedule a pod in line with the status from Aurae. Your choice is manufactured and the pod is started utilizing the Aurae runtime API directly.
The project is small, nevertheless the project is free and open. We havent established a formal group of project governance yet, however I am certain we will make it happen with time especially as folks show fascination with the work. For the present time the simplest way to become involved would be to follow the project on GitHub and browse the community docs.
We have been literally at the moment starting to draft up our first APIs. In case you are thinking about throwing down your unbiased technical opinion on Systemd we’ve a GitHub issue tracker looking forward to your contribution today.
The project carries an Apache 2.0 license and a CLA in the event the project moves to an increased level governing organization like the Linux Foundation later on.
Prior art and inspiration for might work includes the 9p protocol from plan9. And also my previous use COSI as a cloud option to POSIX. Possibly the most influential inspirations for might work have already been around ten years of my entire life managing systemd and the kubelet at scale.
Influenced by others before me: