There are a couple of things here: first off, minikube isn't tuned for low resources, it's a full k8s packaged for developers. Second, it doesn't burn much CPU at all unless you blew it up and it's churning pods. Third, try to remember that you're running a tool that provides most of what you need to run a service, it's not a bare VM, it comes with reverse proxy, tons of tools, and cluster management.
Basically those minimal specs let you actually run quite a lot of stuff on that minikube, they're not just for the management system.
k0s needs roughly 500MB RAM and 1.5GB drive to run a controller+worker. Can probably pare k3s down to that as well.
And I repeat, this gets you single pane cluster management across all your laptops, reverse proxy, DNS, resource shaping, namespaces, etc. Only big problem with it is that adding distributed storage is quite heavy and unstable (longhorn) or really heavy (ceph), so storage management might need to be manual which is a pain in k8s.
You noticed that I said "(intermittently) half of the CPU power", yeah?
> Third, try to remember that you're running a tool that provides most of what you need to run a service...
I already get everything that I need to run a service with old-ass systems like OpenRC+netifrc or -hack, gag- systemd and its swarm of dependencies. "Run a service on a *nix box" is a thing that we've had pretty well nailed down for decades now. It is -after all- how the services that run Kubernetes get run. Do note that you're talking to someone who does Linux system administration both as a hobby and professionally.
> Sorry I meant k0s. Off by one error at 3 am.
Sure, no problem. Shit happens.
So, k0s? Compared to minikube, the official minimum spec tables [0] indicate that -if you colocate the controller and worker- it cuts the CPU and RAM needs in half, and cuts the disk space by a factor of ten. That's nice, but that's still an eighth of the RAM and (intermittently) a quarter of the CPU of our hypothetical-but-plausible castoff laptop. That's still a lot of resources. And compared to what it costs you, you don't get much. If we were talking about some big, bad, mutually-untrusted-multitenant situation, it could be worth the cost, but -despite what folks like the CNCF might like you to believe- that's not the only scenario out there.
Also Mirantis is responsible for k0s? [1][3] After their rugpull with their Openstack distro way back when, I don't trust that they'll keep maintaining and providing complex stuff that's free to use for long enough to make it worth making a critical part of one's business. (Yes, this has absolutely nothing to do with its resource usage. I'm absolutely not bringing it up to support that argument in any way. I "just" thought it important to mention that I don't trust that Mirantis's free stuff will continue to be free for long enough to safely build (more of?) your business on.)
[1] From [2] "Mirantis offers technical support, professional services and training for k0s. The support subscriptions include, for example, prioritized support (Phone, Web, Email) and access to verified extensions on top of your k0s cluster."
[3] As additional evidence, the only two humans on the first page of commits to the k0s repo are Tom Wieczorek, whose Github profile indicates his affiliation with Mirantis [4], and Jussi Nummelin who is very, very obviously a Mirantis employee. [5] I tried to look at the complete Github contributor list for the k0s repo, but it simply wouldn't load. [6] But, I'd be shocked if this wasn't Mirantis's totally-functional-but-still-pet project that intends to more than make up the cost of development and maintenance with support contracts.
Hey I'm not arguing that you in particular shouldn't use old tech for fun. Heck serve your emacs written internet website via nc from your Amiga for all I care.
I'm just pointing out that it's easy and sufficiently efficient to run k8s on old computers, which makes running homelabs quite easy and also allows projects such as the OP to really shine. You seem to really enjoy telling me how bad it is that k8s needs 0.05 CPU and 500MB of RAM to run but the thing is it will scale horizontally a lot, and also presents the APIs you'll be expected to know in a devops job in 2026.
There are a couple of things here: first off, minikube isn't tuned for low resources, it's a full k8s packaged for developers. Second, it doesn't burn much CPU at all unless you blew it up and it's churning pods. Third, try to remember that you're running a tool that provides most of what you need to run a service, it's not a bare VM, it comes with reverse proxy, tons of tools, and cluster management.
Basically those minimal specs let you actually run quite a lot of stuff on that minikube, they're not just for the management system.
k0s needs roughly 500MB RAM and 1.5GB drive to run a controller+worker. Can probably pare k3s down to that as well.
And I repeat, this gets you single pane cluster management across all your laptops, reverse proxy, DNS, resource shaping, namespaces, etc. Only big problem with it is that adding distributed storage is quite heavy and unstable (longhorn) or really heavy (ceph), so storage management might need to be manual which is a pain in k8s.