HN Distilled

Essential insights from Hacker News discussions

Replacing Kubernetes with systemd (2024)

Fleet's Untapped Potential

Several commenters lamented the early abandonment of CoreOS Fleet, suggesting it was a promising technology cut short. "agreed, coreos pivoted to k8s almost immediately after releaseing fleet and didn't really get the chance to use and develop it much," according to pa7ch. llarsson added, "That's also where etcd came from. It really felt, to me, like the precursor to Kubernetes." thebeardisred shared a practical, positive note: "Well, it's funny you mention that because I started working on a PoC of running vLLM atop Fleet this morning. :grin:" and klooney was glad to hear it still worked.

Podman and Quadlet as a Modern Alternative

The discussion quickly shifted to Podman and Quadlet as potential modern solutions for container management, especially in the context of systemd. byrnedo introduced "skate" as a similar multi-host solution with Kubernetes manifest support, built on Podman and systemd. masneyb then pushed for Quadlet, stating "The next step to simplify this even further is to use Quadlet within systemd to manage the containers." rsolva agreed enthusiastically ("This us the way! Quadlets is such a nice way to run containers, really a set and forget experience.") and overtone1000 shared their positive experience migrating their home server from Docker Compose to rootless Podman Quadlets.

Quadlet's Capabilities and Docker Compose Migration

The capabilities and limitations of Quadlet compared to Docker Compose were a significant point of discussion. sureglymop asked, "Seems very cool but can it do all one can do with compose?" and highlighting the simplicity of Compose, further asking "In other words, declare networks, multiple services, volumes, config(maps) and labels for e.g. traefik all in one single file?". 0xC0ncord suggested converting Docker Compose files to Kubernetes YAML for Quadlet deployment, which sureglymop acknowledged as "really nice" but also more complicated, expressing a wish for a simpler ".compose extension." grimblee then offered a tool ("podlet") for converting Compose files (and other formats) to Quadlets.

Challenges and Quirks of Rootless Podman

While generally positive, the discussion also highlighted some challenges and quirks when using rootless Podman with systemd. zokier questioned the use of --user and lingering logins instead of systemd service management. phoronixrly explained the rationale: "You want rootless podman because docker is the defacto standard way of packaging non-legacy software now including autoupdates. I know, sad... Podman still does not offer convenient and mature way for systemd to run it with an unprivileged user. It is the only gripe I've had with this approach..." While ggpsv countered this with Podman 5 and Quadlet, phoronixrly requested documentation. chaz6 raised a performance penalty issue with preserving the original source IP address in rootless Podman. soraminazuki noted the incompatibility between systemd's User=/DynamicUser= and Podman, resulting in the usage of --user as a replacement but labelled the practice as "messy".

A Simpler Alternative: Direct Systemd Services

Some participants expressed a preference for eschewing containers altogether in favor of directly running services with systemd. VWWHFSfQ shared their approach of packaging debs and running them directly on EC2 instances with systemd and Ansible, explaining "really raw-dogging it here but I got tired of endless json-inside-yaml-inside-hcl. ansible yaml is about all I want to deal with at this point." SvenL concurred, finding systemd to be "delightful" and highlighting the benefits of cgroup support running many services on a single VPS with assigned users and minimal privileges. secabeen further emphasized the advantage of easier library updates with this approach: "I also really like in this approach that if there is a bug in a common library that I use, all I have to do is apt full-upgrade and restart my running processes, and I am protected."

The Pain of Managing YAML

A recurring undercurrent in the discussion was the frustration with complex configuration formats, particularly YAML. r3trohack3r succinctly captured this sentiment: "The number of human lifetimes wasted on the problem domain of 'managing YAML at scale'..." This highlights a broader dissatisfaction with the complexity often associated with modern infrastructure management tools.