Except you own ops, management, extension, interoperability, access, security, scalability, redundancy… words cannot express how ridiculous all of the koober propaganda is
Cloud’s big promise was speed to market and price, and let’s be honest, price is no longer there compared to a decent operation.
The one thing where clouds remain kings is speed for small teams. Any large enough company should probably Ask themselves whether running their own operation using ias would be a better choice.
Because on prem is inelastic, we are at sub 10% peak utilization of compute resources. If we added in the likely higher cloud utilization rate we are talking of 30%+ savings from on prem.
so... you bought way too much hardware?
Oh, and all the documentation for that YAML assumes you've memorized as much vocabulary as a Foreign Language 101 class.
(And there is a mad god that says: if you try to use click-ops to get around this without knowing the vocabulary, you're going to have a bad time.)
But on the other hand: to put it in terms of the "3 servers" - the moment you think you'll have 3 servers, and any level of uptime expectations, you'll inevitably have to rebuild them, services and logging and all, from scratch often and quickly enough that you might as well have 20 servers with how stressful that rebuild will be.
k8s can be a saving grace there, and I recommend it to anyone with the time and interest in how cluster best practices work! But it's not a free option or a weekend skill-up.
- Upgrading a kubernetes cluster may as well be an olympic sport. its so draconian most best practice documentation insists you build a second cluster for AB deployment.
- load balancers come in half a dozen flavours, with the default options bolted at the hip to the cloud cartel. MetalLB is an option, but your admin doesnt understand subnets let alone BGP.
- It is infested with the cult of immutability. pod not working? destroy it. network traffic acting up? destroy the node. container not working? time to destroy it. cluster down? rebuilt the entire thing. At no point does the "devops practitioner" stop to consider why or how a thing of kubernetes has betrayed them. it is assumed you have a football field of fresh bare metal to reinitialize everything onto at a moments notice, failure modes be damned.
what your company likely needs is some implementation of libvirtd or proxmox. run your workloads on rootless podman or (god forbid) deploy to a single VM.
MetalLB is good yes, and admins should have IP knowledge. I ask this in interview questions.
Yes, sheep not pets is the term here. Self healing is wonderful. There's plenty to dig into if you run into the same problem repeatedly. Being able to yank a node out that's misbehaving is very nice from a maintenance pov.
Talos on bare metal to get kubernetes features is pretty good. That's what my homelab is. I hated managing VMs before that.
The complaint isn't immutability, the complaint is that k8s does immutability is a broken, way too granular fashion.
I know that is the whole point of sheep vs pets but it somehow became the "did you restart the pc" version for operations.
Immutability is like violence: if it doesn't solve your problem, you aren't using enough of it.
Maybe get someone competent then? Why are you tasking running onprem setup someone who doesn’t understand basic networking?
And in related news, Proxmox VE is often probably a more sensible thing to use for a private cloud environment, because it is far more flexible and easier to use than Kubernetes.
Longhorn just kinda worked out of the box though with a couple kernel/system settings. No s3 api though.
But this isn't k8s fault out all.
I suspect both of them will go down together if/when they do.
That being said, once it was set up, there was not a lot of maintenance. Kubernetes is quire resilient when set up properly, and the cost savings were significant.
K8s is complicated as hell to learn to use. Its learning curve is very shallow. Yes, you can get a "hello world" running quickly, but that is not the benchmark for whether you actually understand what's going on, or how to make it do what you need.
But once you do learn it thoroughly, it's ridiculously fast to ramp up on it and use it for very complex things, very quickly. As a developer medium, as an operational medium, it accelerates the kind of modern practices (that for some reason most people still don't know about?) that can produce a lot of value.
But that's if someone else is building and maintaining the underlying "guts" of it for you. If you try to build it from scratch and maintain it on bare metal, suddenly it's incredibly complicated again with another shallow learning curve and a lot of effort. And that effort continues, because they keep changing the fucking thing every 6-12 months...
It's like learning to drive a car or ride a bike. At first it's difficult and time-consuming. But then you get it, and you can ride around pretty easily, and it can take you far. However, that does not mean you understand car/bike mechanics, or can take it apart and rebuild it when something breaks. So be prepared to pay someone for that maintenance, or be prepared to become a mechanic (and do that work while also doing your day job). This analogy is stretched thinner by the fact that nobody's constantly changing how your car works...
This is not a good reason to have done it. To me this means that the expectations and outcomes were flawed as they are solving a problem that shouldn't have existed. I can't really agree with the sentiment or overview of this post
High Scale/Revenue
│
│
Managed Services │ Self-hosted K8s
(Overpaying but │ (article is
no choice) │ pitched here)
│
────────────────────────────┼────────────────────────────
Low capacity │ High capacity
│
│
Managed Services │ Managed Services
(Right choice - │ (Wasting money on
focus on product) │ platform team)
│
Low Scale/Revenue
Or something like that. Maybe as a function of time as well but that might be harder to do in 2d.Sure I can absolutely manage my own k8s, but there is no doubt it's easier for me to spin up postgres and ship faster on my own. At enterprise scale it's definitely a lot easier to do everything in k8s and be able to manage as many aspects as possible. I have experience of both.
Kubernetes is a rat nest and I long hope for Kubernetes be simpler (Who needs this Gateway API?) but Devs keep building crazy and crazy solutions so we have to pivot to keep up.
And while k8s can do all the same things and much more with a bit of trying, but it requires a mission control the second you add a second developer, you will have built-in primitives that will compete all the time with the ones you bolt-on, etc etc. Nomad feels much more opinionated and in a good way.
Nomad is one of those things that gets you 90% of the way with 20% of effort, and only then if you need something, you can add things to it. K8S is great, way more flexible, there are managed options out there, massive ecosystem, but it always feels like out of the box you need to glue 5 different tools to it, just get it going.
Also Incus. Stephane Graeber is doing lords work by sticking to his thing. That's also super fun to mess with.
Glyptodon•1h ago
cbsmith•1h ago
bakies•1h ago
pavel_lishin•1h ago
bakies•1h ago
pavel_lishin•1h ago
zer00eyz•1h ago
I dont need to autoscale my home lab...
I want a better UI/DX/Interface than Kubernetes...
I need to be able to do things "by hand" as well as "automated" at home...
There is a reason that I use Proxmox at home. Because it is a joy to work with for the simple needs of my home lab.
barbazoo•55m ago
This doesn't seem to be aimed at homelab but small teams.
0x1ch•48m ago
mono442•9m ago