Show HN: Managing on-premise servers without Kubernetes
github.comI have to ask why someone would choose this over ansible, ssh, and a proper monitoring and metrics stack.
Something like this allows unconstrained config drift with no audit trail.
You shouldn't. If you are small enough, use Docker Compose with Ansible.
Once you get big enough, Kubernetes for 99% of companies, is next logical step.
Kubernetes does not manage servers anyway. You still need something to put Kubernetes on those servers.
Why would you manage a server with Kubernetes in any case??
Because otherwise you have to use this! Or some other DIY gobbled together whatever.
That's tongue in cheek but a pretty hard check too, imo. The thing of it is, I like kubernetes, I think you'd have to be mad to opt to re-figure this all out, to get adequate parity. But but but I do want there to be competition, evolution, I want people trying things.
Usually though the competition is trying to do far less. When people eskew Kube, it's usually because they think they are right sizing their approach, "you might not need Kube". Usually they are trying to avoid building an API based platform that scales across different concerns (no CRD, no api-server). Usually they are trying to avoid autonomics, avoid OODA loops, avoid self healing. Usually the desired state management is fairly limited.
I'd like to see more attacks on kubernetes that are from above, and not below. Why is yours better? Being smaller, doing less, is so far the only reason I've heard, the only reason I've seen people go for, what to me, is their own personal tilt at the windmills that Kube has done. This is a hard foe to try to tilt at, and I wish yee tilters the best, I just think it needs to be a more principled still general approach to actually be meaningful. Otherwise: you should Kube.
I'm still lost on how Kube has anything to do with server management (as someone who used to be a sysadmin and manage many servers, maybe my definition is just different?). Kubernetes doesn't solve any of the problems this does, it is so far from anything I would reach for to "manage" anything.
SRE here, when most people say "Server Management" they are talking the root of their problem. "I have this set of Applications and that need to run on this fleet of servers. How do I do this?" and Kubernetes is commonly the answer but not only answer.
Yes, you still need to something to "install" the Kubernetes but that is generally easier surface area with something like Talos OS, K3s, whatever Canonical/Red Hat cooked up.
Kubernetes is only another application to me, it just manages containers (which probably run applications, which may be serving something, I guess?). Definitions have got a bit muddy since the advent of devops imo! (Maybe part of the weirdness is that this post is about an app that manages crons and files and other os-level stuff)
Sure, it's just another application technically. On more practical level, it's pretty much an OS.
There's systems like Talos where you are pretty much explicitly not allowed to touch Linux, where essentially the only thing the computer presents that you can control is Kubernetes itself. At that point, the OS is kubernetes basically; I find it much harder to entertain pretenses that it's not when you get that far along. https://github.com/siderolabs/talos
But it's really a gradient. As more and more services and systems move from being systemd services (or whatever) to in kubernetes, I see it as the position along a gradient shifting. Both are operating systems. They're different operating systems, doing different things, but both manage and provide resources for user payloads, both run apps, both host a user interface (apiserver for kubernetes), both have state (also apiserver, vs file-systems).
How is this different than Cockpit?
Manage containers and env values without effort