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

101–110 of 233 posts

Re: What job interviews taught me about Kubernetes

#101

Post by portly »

zbentley wrote: post #67
liampulles wrote: post #61

There is a core 20% to Kubernetes which is very nice, mostly being the Deployment and Service management stuff. That along with a very basic GitOps for cluster management (an infra repo for operators using Flux, applying service level yaml from app repos in CI) above a cloud managed Kubernetes cluster, where you still keep your DB and build servers off the cluster, can be quite nice for a small team. Beyond that, the…

Spot on. I have a lot of trouble convincing cloud folks that for durable state, you probably don’t want kubernetes. It’s not that e.g. the CSI drivers and operators for clustered databases aren’t top notch—they are; the era of “avoid stateful kube services” is long behind us—it’s that the cloud provider managed services for e.g. blob stores or databases are so much more reliable . The S3s and Auroras of the world are…

Also cluster migrations are required pretty often in my company. Having state on a cluster means migrating that as well, which is a complex and time consuming operation. Having your state in S3 or external database makes migrations a breeze.

Re: What job interviews taught me about Kubernetes

#102

Post by ddreier »

mikeocool wrote: post #24
embedding-shape wrote: post #18

Earlier quoted context omitted.

> 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 Hashicorp's Nomad basically is just that, supports various way of running stuff too which is neat. Shame about the license change which basically killed all my interest in it, so seems the hole is indeed still unf…

Yeah I’ve always meant to check out nomad and never had an opportunity. Though as I recall, it makes heavy use of consul, which I have used in anger, and makes me a little weary (though that experience is likely very out of date).

Nomad has gained basic service discovery and K/V store without Consul. However, health checking is extremely limited.

Re: What job interviews taught me about Kubernetes

#103

Post by xlii »

d675 wrote: post #40
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…

as I got into SWE 4 yrs ago, this was a big part of my job as a SRE/SDET and my next job came b/c of that SRE exp which was never used, so just became an SDET. Now am laid off, and hard to find a job...

I'm sorry to read that.

Unfortunately it's an industry wide problem, and it touches many areas and levels of expertise. Some believed that AI can drop costs and compressed job spaces.

It starts to bounce off but it's not back to - what I could fall - normal baseline.

Re: What job interviews taught me about Kubernetes

#104

Post by ddreier »

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…

Unless you hate HCL, 1, 2, and 3 pretty much describe Nomad exactly. We run over 100k production applications on Nomad. But migration to AWS from private data centers, our HashiCorp bill, and the severe lack of Nomad talent, have finally pushed us to k8s (EKS).

Re: What job interviews taught me about Kubernetes

#105

Post by aurisl »

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…

We also had similar problems at our small scale startup. We tried k8s for a pilot project, and observation was the same: the complexity was not worth it for us. We needed something simpler instead we adopted Nomad, which actually fit our use case. It had its own issues and bugs, but overall, it was much more straightforward to work with.

Re: What job interviews taught me about Kubernetes

#106

Post by xlii »

bigstrat2003 wrote: post #84
johnsmith1840 wrote: post #82

Earlier quoted context omitted.

Don't. Get a chatgpt subscription and spin up a minikube cluster and launch some stuff and play around. K8s is incredibly deep and complex but with AI it's finally easy to just hello world it.

This is absolutely terrible advice. You should never ever use LLMs to work on something you don't understand already, because you have no way to catch the machine when it screws up (and it will screw up). Just like with every other form of automation before LLMs, a smart person only automates things he already knows how to do himself.

"Only a Sith deals in absolutes" ;-)

I mostly agree it's an area that's risky to wander into mindlessly but it is much more easier to validate knowledge than to practice it.

E.g. I can't write Chinese but can validate if piece of Chinese is a valid one (by feeding to N translators, other LLMs or asking a friend who knows Chinese).

Under assumption of "LLM output is false until proven otherwise" it's not a bad approach and worked for me in various scenarios. (E.g. I asked for implementation of algorithm in Rust and then validated it against base definition).

Re: What job interviews taught me about Kubernetes

#107

Post by globular-toast »

aleksiy123 wrote: post #92
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…

Finally just bought a piece of my own hardware and got LLM to deploy k3s cluster on it. I think diy homelab/hosting is more accessible than ever. Cut costs on cloud spend and invest into AI spend. For a solo dev on a budget, I think it just makes sense.

It's not an investment, it's just a spend. If you had learnt to deploy k3s yourself, which is really easy, but still, that would be an investment. Paying for LLMs is basically renting.

Re: What job interviews taught me about Kubernetes

#108

Post by globular-toast »

I pushed k8s in the medium sized company I work for much the same reasons. We use flux for gitops which works really well. The problem is we now have as many clusters as we did bare metal hosts before. There's production clusters, dev clusters, ones in other regions etc. The idea was to have "one place, one way to deploy" but it's actually many places. Am I doing it wrong? Should it all be one cluster and just have different nodes for different reasons and RBAC etc?

Re: What job interviews taught me about Kubernetes

#109

Post by codemog »

It's not uniformity, it's cargo culting and offloading thinking to group norms. Doesn't help engineers are some of the most arrogant people alive and refuse to admit anything is complicated, as they consider it some kind affront to their intelligence.

I would not advise asking the majority of CTOs these questions either. Many got to that position by saying what people want to hear, which is the "average" safe answer. They will parrot whatever is "hot" at that time because it's the least risky response. They are not your friend nor a reliable source.

Re: What job interviews taught me about Kubernetes

#110

Post by te_chris »

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…

GCP cloud run is pretty close to this. We’re using it now and I’ve a lot of experience with gke.

They’ve announced persistent “instances” recently which solves a big problem for us - sometimes you want continual long running workloads.

Post reply on HN