What job interviews taught me about Kubernetes

mattmatters

A pretty nothing burger of a post with a bunch of ai-isms. Is this written by a real human? K8s is a complicated beast. CTOs hiring for their 10 person company because of its "used everywhere" is a bad reason to adopt a major piece of technology. You can always graduate to it later if need be.

mikgp

Kubernetes is so ubiquitous that yeah, as long as you're not trying to run it yourself, a small Kubernetes cluster just isn't all that much to manage. I think it's been so long, people forget how annoying it is to manage servers. All said and done Kubernetes is becoming more the "Boring Technology"

JohnMakin

> I still don't totally get why the shift happened when it did. Five years ago all three camps were doing fine. Now the VM+systemd crowd has basically disappeared from job postings, serverless stayed niche, and K8s just won. > > My best guesses: managed K8s (EKS, GKE, AKS) got mature and the talent pool flipped: enough people learned it that hiring for anything else became the harder choice. And Helm made "just use someone else's chart" a real option. But I'm not certain. If you were there for the shift and have a better theory, I'd genuinely like to know. Pretty much, almost. Have spent a bunch of time in my career working on the "VM + systemd" setups, stuff running on a rack, or in an ec2 on cloud - managed kubernetes is a lot better for me than those cobbled together messes. There's "easier" setups but usually end up costing me a lot more in time and $. To answer simply, it became good + convenient. I could complain about plenty, and people here like to, but honestly you couldn't pay me to go back to the old way. The one legitimate gripe is the upgrade schedule is exhausting, on AWS it's about every 6 months before you go into extended support. I also hate being at the mercy of arbitrary decisions like "ok we know a huge chunk of the web going back a decade has architected off our Ingress API, but recently we decided we dont really like that way anymore and we want you to use Gateway API instead, so, um, like ya we know it just killed off one of the most used open source ingress configs (ingress-nginx) but yea trust us bro this is going to be so much better " kind of thing.

clickety_clack

Adopting k8s when you hire your _second_ engineer (first after the CTO)? That’s a red flag that the CTO’s priorities are wrong and he’s just enjoying tinkering with his infra instead of solving the users’ problems.

xlii

One year ago I might agree that Kubernetes is an overkill but today? Ask your favorite GPT to generate manifests, get primary app into cluster with telepresence or execute straight from container and switch contexts and clusters like it's 90s again. One reason I dislike Docker Compose and Docker is lack of isolation. Yes sure if you put your arm deep enough you can get it, but on local k8s I can spin cluster per workspace and not worry about conflicting ports between PostgreSQL instances. Before LLMs writing consistent YAMLs was PITA but today on low/development scale it's pretty much free lunch.

Glyptodon

Even as a solo dev there's generally been a yawning gap between k8s and manual infra that nothing has ever filled that well and it's part of why things like Heroku were so popular for a while.

mikeocool

I made this decision at a startup (albeit when the eng team was ~30 people, and we had a monolith with ~10 supporting services). I wouldn’t do it again, even for the reasons stated in the article. The uniformity is nice, we were moving from apps running directly ec2 instances provisioned with ansible. Each time we spun up a new service it was a process to get the ec2 instances provisioned just so. But k8s is such a pain in the ass. One thing that I think people new to it don’t realize is that it’s not at all batteries included - to get a basic managed cluster setup, you’re still going to be installing a bunch of additional controllers (ingress, cert-manager, external dns to start). And then you’re on the hook for making sure all those processes stay up (hope the admission webhook controller for a critical resource doesn’t go down!). Then you’ve got to do a major upgrade on not only your cluster, but all of those controllers every ~3 months. And no one is shy about introducing breaking changes. Also you’re introducing a huge amount of complexity with the k8s networking and dns layer that most startups have zero need for (if you’re on EKS, make sure to read about scaling and monitoring CoreDNS). I think there is a real hole in the market for a simple solution that lets you deploy some containers to some instances in a declarative fashion without all of that complexity and does decent LTS versions. I imagine there’s something out there that does this, but k8s has really sucked up all the oxygen.

nitwit005

> First one was uniformity. Every service deploys the same way. My current company makes this claim, but it's not true. They also have serverless apps, and also have some services running directly on EC2. They just think of the Kubernetes deployments as the "standard" way. > Second was shared, hireable knowledge. K8s is basically a lingua franca now. People were demanding experience with Kubernetes, long before it was reasonable to expect it. Everyone added it to their resume, because they had to.

SamuelAdams

This seems to be less about K8’s and more about the infra as code movement. It doesn’t matter if you use K8, CDK, or terraform - you get the same benefits the OP stated across the board. It is nice to be able to have a consistent deployment pattern, with traceability, rollback support, and production approval checks. It’s nice to not have some archaic something stuck in someone’s head. It’s also nice to be able to see how something works by reading the code, which is usually up to date and deployable.

avhception

Well, I totally get the benefits that made those people choose Kubernetes. It's just that those benefits could be had w/o running a massively complicated piece of machinery that is mostly engineered to solve problems I don't have.

vasco

It's a bit odd that the author presents no data other than their interviewing and declares that the shift happened recently. It's not true, there's been steady growth of adoption of kubernetes for years. Just reading CNCF surveys from last years before posting would tell them that. Their identified reasons are OK though.

shevis

> The CTOs I talked to aren't making a dumb choice. They're solving real problems. Unrelated to the content of the article, this sentence structure is a dead giveaway of LLM writing.

h4kunamata

Taught me that companies follow hype. I worked once at a bankm fully kubernetes, the amount of problems were out of reality from this world. Complexities are being added for no reason at all.

crefiz

Another complementary approach is what Vasilios shared today[1] (the ex-Attlasian guy that recently got attraction) [1] https://youtu.be/Iv9hoYTQp_8?si=5YsUxYayFUY-RfKC

suralind

So I’m personally a huge fan of k8s and while I agree it may be „complicated”, it’s because deploying applications is complicated. (I want to point out that there is no requirement no set up cert manager, ArgoCD, external secrets, etc. - and many people who’d consider a VPS would happily slap a .env with an unencrypted secret then ssh to update, but when they choose Kubernetes they take the long route of doing proper GitOps and complain that there are so many things to configure :) But I found funny that the OP summarized to use Kubernetes when CTO is no longer the only dev.

reillyse

The reason this is accelerating recently is agents are really good at spinning up k8s clusters. They've made devops work super super simple. Basically all the annoying stuff you know you should do but it's way too much hassle - using let's encrypt to create unique certs for every app in your cluster to enable zero trust, configuring permissions and security profiles for everything etc etc (never mind just standing them up in the first place) - it's all simple now.

louwrentius

I'm going against the grain but I read: we have a cultural/policy issue and we 'fix' it with tools. I think what you hear is never the whole story, there is much more going on.

stego-tech

OP gets it. Right now, I’m one dinosaur managing a startup’s tech portfolio. Everything lives in my head first, then in my break-glass vault for addressing the bus problem. Our public cloud footprint is a single KMS for backups. We have no VMs, everything is a cloud service. The literal fucking second we have real infrastructure requirements for compute, it’s right to GCE. No ifs, ands, or buts. Here’s our Git Repo, here’s the managed K8s control plane, make it work. If (or when) we need on-prem compute, we add them to the K8s control plane as worker nodes and taint accordingly. It’s just so much more interchangeable, even if the learning curve for non-SDEs can be a little steeper than VMs.

FpUser

I call BS on that. I serve SMB clients and many are happy like a clams with monoliths deployed using those proverbial bash scripts that also does lots of other things. Understanding scripts in the age of AI is trivial for newcomers. I for example fed my own uber script to AI as an experiment and it has produced all encompassing nice documentation with examples and tests.

mianos

This is exactly why I call it 'resume++'. You have to use it to attract talent. People want to use it to expand their employment pool. This is not justification to using it. To use it is a whole different question, and not in any way related to job interviews. I have worked in places that are crazy for not using it and others where using it was even crazier.