Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What job interviews taught me about Kubernetes

notnotp.com

Post reply on HN
Print view View original

181–190 of 233 posts

Re: What job interviews taught me about Kubernetes

#181

Post by TZubiri »

mikeocool wrote: post #14

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 p…

>I think there is a real hole in the market for a simple solution that lets you deploy some containers

Containers? In this climate? What's the kernel LPE rate at after copyfail and copyfail2? No containers, VM or harden. No half measures.

If there's going to be something new, it needs to be topical, and containers are out.

Re: What job interviews taught me about Kubernetes

#182

Post by TZubiri »

imglorp wrote: post #180

> shared, hireable knowledge So it's the same motivation as enterprise java.

But if you just build bash scripts on top of vms, the talent pool is much larger, necessarily.

I feel the motivation goes a bit in the opposite direction. Yes a commoditized worker who speaks a common k8s language, but not too common a language, there has to be some selection here, a talent pool of 100K engineers that know linux is too big, but a pool of 5k engineers that know k8s apparently is just right.

Gotta filter those resumes somehow!

Re: What job interviews taught me about Kubernetes

#183

Post by corvad »

singron wrote: post #99
mikeocool wrote: post #14

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 p…

I really wish there was an 80% kubernetes. I think you could get there with some changes: 1. No overlay networks. 1 IP per machine. pods use dynamically allocated ports, and the kubelet enforces pods listen only on their assigned ports using seccomp. 2. No kube-proxy or equivalent Layer-4 "load-balancer". It's not good, but it's often used. You should use some kind of Layer-7 load balancing instead. Also you need to…

I believe this is more like Borg if anything.

Re: What job interviews taught me about Kubernetes

#184

Post by TZubiri »

hadlock wrote: post #23
xlii wrote: post #10

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 work…

Strong agree, if there's one thing LLMs are excellent at, it's writing Terraform and Kubernetes deployments (and/or helm charts). What used to be half a day of research, trial and error, is now 20 seconds of AI churn and 98% of the time it nails it on the first try. And then point it at grafana and tell it to write you a dashboard for the new service/s. Easy peasy lemon squeezy. What used to require a team of 4 devop…

on the other hand, it might be a benefit that an AI can't spin up instances.

Do I want potential to increase expenditure by infinite percent? Or do I want to sign a contract for 2 500$/mo dedicated servers?

Let's be real the latter can handle 20k concurrent users without breaking a sweat, and that's like 99.9% of companies and projects.

Re: What job interviews taught me about Kubernetes

#185

Post by esbeeb »

xylon wrote: post #179

I assumed the reason there are so many job offerings for kubernetes engineers is either because these jobs have high churn, or because kubernetes takes more work to maintain. I think linux+nginx+postgres+favourite-lang is still the most sensible way to go. Good engineers don't overcomplicate things.

"linux+nginx+postgres+favourite-lang" - I agree here. Yes, don't over-complicate things.

Re: What job interviews taught me about Kubernetes

#186

Post by zsoltkacsandi »

mikeocool wrote: post #14

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 p…

I had exactly the same experience, and we went into the same direction (ansible + ec2). No regrets.

Re: What job interviews taught me about Kubernetes

#187

Post by aweiland »

rienbdj wrote: post #117
aaronbrethorst wrote: post #85

The knowledge is in the YAML Exactly why I hate CloudFormation, K8S, GitHub Actions, etc. yaml is a terrible format for the knowledge encoded in these artifacts.

There are compile-to-yaml config languages

Any good ones people would recommend?

Re: What job interviews taught me about Kubernetes

#188

Post by embedding-shape »

xav0989 wrote: post #150
embedding-shape wrote: post #32

Earlier quoted context omitted.

It doesn't require Consul IIRC, but bunch of features does depend on it, like service discovery and related stuff. But Nomad is totally usable without Consul for simpler setups.

They’ve now had nomad-native services without consul for a while, including health checks!

Oh neat, wasn't aware! Cheers for providing the update, now if they only could revert the license it might be something one could use again.

Re: What job interviews taught me about Kubernetes

#189

Post by jmaw »

sethammons wrote: post #167
DrScientist wrote: post #135

Earlier quoted context omitted.

+1 on the problem of moving complexity from programming languages to configuration. One of the main problems here is that programming languages typically have lots of tools to help validate correctness, whereas configuration tools are typically either much less mature or woefully underused. There is nothing more frustrating in something failing due to a misconfiguration - but you've no idea what the correct value sho…

My helm adventures (a while back now, so maybe better these days): > You have an error in your config on line 1. Good luck.

Wait did it actually say "Good luck" in the error message? If so that is hilarious

Re: What job interviews taught me about Kubernetes

#190

Post by JohnMakin »

mschuster91 wrote: post #178
zbentley wrote: post #73

Earlier quoted context omitted.

I think the best supported and most mature pattern on most big cloud providers is precisely > do stuff in parallel either by hand or by terraform …specifically by terraform. Making k8s own the provisioning and management of external infrastructure on principle (as opposed to when that makes sense, e.g. load balancers/gateway/CSI providers) is not a good approach. Sure, it feels unified, but the cost of unification is…

> Sure, it feels unified, but the cost of unification is incredibly not worth it. That's the cost I was talking about. It is indeed annoying and time-consuming to get it set-up once, but once it works... it is amazing for developers to have the ability to spin up a completely identical to prod environment for a hotfix branch to test stuff out, with no involvement from ops or anyone else. And also, it's much easier IM…

Yea, I used to believe this too, and still sort of agree - I got so tired of the argument in maintaining k8s infra in terraform I gave up and wrote what is essentially a terraform wrapper module around helm. The charts break terraform quite a bit sometimes, so you have to keep it simple, and god help you if you want to use CRD's, hashicorp providers have the notion no one actually needs those.

I had dismal hopes of it working for very long but it's remained mostly untouched going on 3 years now which really surprised me, and it's been easy to work with. I think if you run EKS resources like node groups, autoscalers, LB type of resources in the same state file as helm deployments you're going to have a very bad time though.

Post reply on HN