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

211–220 of 233 posts

Re: What job interviews taught me about Kubernetes

#211

Post by JohnMakin »

mschuster91 wrote: post #201
JohnMakin wrote: post #190

Earlier quoted context omitted.

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

> 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. There's no alternative to that anyway... otherwise even a terraform apply -refresh=false will quickly take well over 10 minutes.

seperate applies in different state files? I establish hard loosely coupled separations here and it’s been fine as terraform wrapper around helm. I’d rather run ci jobs around gitops + charts using whatever your preferred flavor but current terraform providers seem fine with it as long as you arent overly relying on crd’s that like to track state via timestamps, terraform doesnt like that, but someone might depending on their use case.

Re: What job interviews taught me about Kubernetes

#212

Post by bakies »

TZubiri wrote: post #184
hadlock wrote: post #23

Earlier quoted context omitted.

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.

Oh what would I do with $2,500 a month in dedicated servers..? Kubernetes.

Re: What job interviews taught me about Kubernetes

#213

Post by bakies »

bionsystem wrote: post #195

None of those arguments make sense. Uniformity ? Try deploying openbao inside kube, if kube decides to restart your pods, you're in for unsealing them at 3am, waking up everybody who owns a Shamir key. So bao stays out of the cluster, or pinned to certain nodes, defeating the purpose entirely. Also, with the ultra wide variety of tools at every layer of the stack, uniformity is a joke ; there are no 2 kube cluster de…

Sounds like you had specific issues with openbap and your cluster provider. Whatever the tech stack it's all presented the same way and easily discoverable. Kubernetes is a cloud operating system- this is exactly the point about standardized knowledge.

Re: What job interviews taught me about Kubernetes

#214

Post by jcattle »

eamon0989 wrote: post #176
jcattle wrote: post #163

Earlier quoted context omitted.

This blurb gave me the idea to try and quantize this. Scrape the top HN blogs over the last few years and see how occurences of common phrases change. I'd expect to see a huge increase in "solving real problems" over the last months.

I would love to see the results of this if you actually do it!

A coding agent should make short work of that. However I'm a bit doubtful if the results would actually be meaningful.

I'm thinking that some of the LLM-isms are a bit more complex than just repeated phrases. It's often more that short, punchy writing style with quick setups and punchlines. But would be interesting nonetheless. I really think that some things (like "solving real problems" or "it's not"/"this isn't") would show up.

Re: What job interviews taught me about Kubernetes

#215

Post by bionsystem »

bakies wrote: post #213
bionsystem wrote: post #195

None of those arguments make sense. Uniformity ? Try deploying openbao inside kube, if kube decides to restart your pods, you're in for unsealing them at 3am, waking up everybody who owns a Shamir key. So bao stays out of the cluster, or pinned to certain nodes, defeating the purpose entirely. Also, with the ultra wide variety of tools at every layer of the stack, uniformity is a joke ; there are no 2 kube cluster de…

Sounds like you had specific issues with openbap and your cluster provider. Whatever the tech stack it's all presented the same way and easily discoverable. Kubernetes is a cloud operating system- this is exactly the point about standardized knowledge.

I give a counter example to a general statement, in logic, it is enough to debunk the original statement. My point is, SOME things wouldn't run predictably inside the cluster (in that case without pinning to nodes, which the article says isn't necessary, and which in general defeats the purpose), so you'd need to run some things outside of it.

As per standardized knowledge, I can't see how somebody even proficient with kube, could jump into any app and troubleshoot bad behavior. Apps each have their quirks and subtleties, specific components that behave a certain way. The layers still exists, the kube cluster itself (which again has many component options at every layer of the stack ; hard to know them all), and the app (which will require at least some specialty knowledge).

If it's just about pushing helm charts we wouldn't need SRE anymore, just a CI.

Re: What job interviews taught me about Kubernetes

#216

Post by foobarian »

mikeocool wrote: post #205
vbezhenar wrote: post #141

Earlier quoted context omitted.

Docker swarm is that simple solution you're looking for. But people don't need simple solutions. They want scalable solutions and Kubernetes fits this niche perfectly. You can deploy it on single server today and scale to 100 servers managed cluster tomorrow. Just to provide a similar example. Linux system is insanely complicated. Kernel alone has thousands of options. Distos have tens of thousands of packages. Where…

People think they want infinitely scalable solutions. But I think what they fail realize is that by the time they actually hit a scale where it matter they’re going to have to change so much about their infra that prematurely using the scalable solution didn’t really but them much except a bunch of headaches when they didn’t have scale.

At our shop we're still cleaning up load-bearing tech debt 20 years later, a lot of which seems to have been built with an expectation "nah no way will this still be running next year"

Re: What job interviews taught me about Kubernetes

#217

Post by bakies »

bionsystem wrote: post #215
bakies wrote: post #213

Earlier quoted context omitted.

Sounds like you had specific issues with openbap and your cluster provider. Whatever the tech stack it's all presented the same way and easily discoverable. Kubernetes is a cloud operating system- this is exactly the point about standardized knowledge.

I give a counter example to a general statement, in logic, it is enough to debunk the original statement. My point is, SOME things wouldn't run predictably inside the cluster (in that case without pinning to nodes, which the article says isn't necessary, and which in general defeats the purpose), so you'd need to run some things outside of it. As per standardized knowledge, I can't see how somebody even proficient wi…

The same way you're describing sysadmins knowing how to look at a linux system and understand what's going on. I feel exactly I can jump into any app and troubleshoot on k8s. And I draw on a lot on top of my previous sysadmin exp.

Re: What job interviews taught me about Kubernetes

#218

Post by linksnapzz »

linksnapzz wrote: post #193
threethirtytwo wrote: post #172

Earlier quoted context omitted.

There is money in simplicity as well. The market demands and prefers it.

This so isn't true, that it's not even wrong.

Ahem:

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” ― Edsger Wybe Dijkstra

Re: What job interviews taught me about Kubernetes

#219

Post by bionsystem »

bakies wrote: post #217
bionsystem wrote: post #215

Earlier quoted context omitted.

I give a counter example to a general statement, in logic, it is enough to debunk the original statement. My point is, SOME things wouldn't run predictably inside the cluster (in that case without pinning to nodes, which the article says isn't necessary, and which in general defeats the purpose), so you'd need to run some things outside of it. As per standardized knowledge, I can't see how somebody even proficient wi…

The same way you're describing sysadmins knowing how to look at a linux system and understand what's going on. I feel exactly I can jump into any app and troubleshoot on k8s. And I draw on a lot on top of my previous sysadmin exp.

So you agree that it is not kube specific, then ?

Re: What job interviews taught me about Kubernetes

#220

Post by bakies »

bionsystem wrote: post #219
bakies wrote: post #217

Earlier quoted context omitted.

The same way you're describing sysadmins knowing how to look at a linux system and understand what's going on. I feel exactly I can jump into any app and troubleshoot on k8s. And I draw on a lot on top of my previous sysadmin exp.

So you agree that it is not kube specific, then ?

The debugging? Not really. It comes from sysadmining. But k8s is a standardized way to deploy software amongst a fleet of machines. Which makes it easy to debug complex systems because I know how to access it all.
Post reply on HN