I bet colos will plug a KVM into your hardware and give you remote access to that KVM. I also bet rachelbythebay has at least one article that talks about the topic.
> ...can't scale if you suddenly had a surge of traffic.
1) If your public server serves entirely or nearly-entirely static data, you're going to saturate your network before you saturate the CPU resources on that laptop.
2) Even if it isn't, computers are way faster than folks give them credit for when you're not weighing them down with Kubernetes and/or running swarms of VMs. [0]
Yeah. I got bored a couple of hours after I posted that speculation and found several other colo facilities that mentioned that they'd do remote KVM. I'd figured that it was a common thing (a fair chunk of hardware you might want to colo either doesn't have IPMI or doesn't have IPMI that's worth a damn), but wasn't sure.
You (the person paying to co-locate hardware) don't buy the KVM that the colo facility uses. The colo facility hooks up the KVM that they own to your hardware and configures it so that you can access it. Once you stop paying to colo your hardware, you take your hardware back (or maybe pay them to dispose of it, I guess) and they keep the KVM, because it's theirs.
k8s doesn't really weigh you down, especially if tuned for the low end use case (k1s). It encourages some dumb decisions that do, such as using Prometheus stack with default settings, but by itself it just eats a lot of ram.
Now using CPU limits in k8s with cgroups v1 does hurt performance. But doing that would hurt performance without k8s too.
> k8s doesn't really weigh you down, especially if tuned for the low end use case (k1s).
Sorry, what "k1s" are you referring to? The only projects with that name that I see are either cut-down management CLIs and GUIs that only work with a preexisting Kubernetes cluster, or years-old abandoned proof-of-concept/alpha-grade Kubernetes reimplementations that are completely unsuitable as a Kubernetes replacement.
The only actually-functional cut-down Kubernetes I'm aware of is 'minikube'. Minikube requires -at minimum- 2 CPUs, 2GB of RAM and 20GB of disk space. [0] That doesn't fit on either of the machines 'nrdvana' was talking about... not the "tiny ... digital ocean droplet", with its 1CPU, 1GB of RAM, and 25GB of disk space [1], nor the "tiny linode" (which has roughly the same specs [2]).
Given that it's not at all uncommon for discarded laptops to have 4 CPUs, 8GB of RAM, and like 250GB of disk, eating 1/4th of the RAM, (intermittently) half of the CPU power, and roughly a tenth of the disk space just for Kubernetes housekeeping kinda sucks. That's pretty damn "heavy", in my judgment. So. Do you have a link to this 'k1s' thing you were talking about? Does it use less than 2 CPUs, 2GB of RAM, and 20GB of disk?
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.
I bet colos will plug a KVM into your hardware and give you remote access to that KVM. I also bet rachelbythebay has at least one article that talks about the topic.
> ...can't scale if you suddenly had a surge of traffic.
1) If your public server serves entirely or nearly-entirely static data, you're going to saturate your network before you saturate the CPU resources on that laptop.
2) Even if it isn't, computers are way faster than folks give them credit for when you're not weighing them down with Kubernetes and/or running swarms of VMs. [0]
3) <https://www.usenix.org/system/files/conference/hotos15/hotos...> (2015)
[0] These are useful tools. But if you're going to be tossing a laptop in a colo (or buying a "tiny linode or [DO] droplet"), YAGNI.