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

191–200 of 233 posts

Re: What job interviews taught me about Kubernetes

#191

Post by d675 »

xlii wrote: post #103
d675 wrote: post #40

Earlier quoted context omitted.

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.

yeah. Was always the jr on a team full of seniors/staff. Always switching context, so many verticals and systems.

True startups need only senior+ and big ones don't wanna interview often.

Re: What job interviews taught me about Kubernetes

#192

Post by englishspot »

makeitdouble wrote: post #57
himata4113 wrote: post #43

Earlier quoted context omitted.

I don't know... running a startup sized kubernetes is relatively easy and pain free these days (k3s). Especially when it comes to scaling up. CNPG is an absolute monster (in a good way). cert-manager is easier than the docker alternative, calico has never failed me (except in bgp mode which has some footguns like not being able to come back from a dead state since it has a chicken and an egg problem unless you point…

I think parent would wish for something close to what heroku represented (what would it be ?) K8s is easier at smaller scales (I understand k3s as a packaged version ?), but you still need one or two people in your team to properly understands all of the concepts and inner workings of k8s, and be able to neck deep into if/when shit hits the fan. For a small team that's a lot of commitment for something that is usuall…

even with just k3s and a few plugins/operators, it still takes someone dedicated to babying it. I've been running a k3s cluster at home for years and I dread upgrading all the things running on it, and all the things needed to keep it running.

and more to that last point, we haven't talked about maintaining the actual nodes themselves yet.

Re: What job interviews taught me about Kubernetes

#194

Post by sharts »

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…

Without kubernetes you end up gluing a bunch of plumbing together anyways. It’s just that people don’t see the glue because they’re so used to it and learning something outside of that framework creations friction.

This isn’t so different from say Linux vs BSD. You can roll your own things and call it a system. Or you can just use something that targets a spec to provide a (mostly) cohesive and consistent layer to build upon.

Re: What job interviews taught me about Kubernetes

#195

Post by bionsystem »

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 deployment that are the same really.

Standardized knowledge ? The operating system is standardized knowledge. Any competent SRE should be able to login into a Linux box and figure out what's running there. And if you let your previous ops shadow it all you're just a pretty bad CTO.

Tracing who does what ? First of all anybody with admin access can run one time jobs just like anybody with sudo can run one time commands. That's like chapter 01 of the kube doc. Also again at the kube layer itself, below the helm chart, the ops who set that up or updates it can and will change stuff that breaks stuff.

Kube isn't necessarily bad and has it's purpose but it's not a product. It's like Linux, a complex piece of tech that requires a lot more knowledge than "just push this helm chart" to work.

Re: What job interviews taught me about Kubernetes

#196

Post by insanitybit »

ddreier wrote: post #104
singron wrote: post #99

Earlier quoted context omitted.

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).

Unfortunate that Nomad hasn't gotten the attention it deserves.

Re: What job interviews taught me about Kubernetes

#197

Post by WorldMaker »

aweiland wrote: post #187
rienbdj wrote: post #117

Earlier quoted context omitted.

There are compile-to-yaml config languages

Any good ones people would recommend?

In my experience I tried a few and kept returning to just Typescript with a good YAML serializer library. Most of what you need in YAML programming is "Typed JSON" and Typescript is an excellent "Typed JSON" and "Typed JSON modularization and merger tool". Then just a little bit of glue code to pass your finished "Typed JSON" into a YAML serializer, depending on any "complex" YAML features you might need.

Re: What job interviews taught me about Kubernetes

#198

Post by WorldMaker »

jbnorth wrote: post #5
mattmatters wrote: post #2

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.

Honestly I felt the same way for a while but the more I'm exposed to both Fortune 500 companies and ones who have a handful of employees I see Kubernetes as just a good starting point rather than adopting it later. It removes the overhead of a lot of what sysadmins and devs of yesteryear did by hand or had to have a career's worth of experience to do quickly. That's not to say that people don't need to know what they…

The big win seems to be "GitOps". There are other tools for "GitOps" than Kubernetes, Kubernetes is just the elephant in the room in terms of size/scale/current adoption patterns. (Certainly not "ease of use", though.) I think one of the themes in comments here is how much people want more "middle ground" "GitOps" tools somewhere between "Serverless" (especially given vendor lock in in that space) and Kubernetes.

Re: What job interviews taught me about Kubernetes

#199

Post by busterarm »

kilobaud wrote: post #97
busterarm wrote: post #38

Earlier quoted context omitted.

Nomad, Consul and Vault all running on VMs that you manage with Terraform. The problem is that when you run this long enough you want K8s features anyway.

And your starter “production” deployment of the Nomad/Consul/Vault stack is literally 12 VMs, comprising three independent Raft clusters. There is no decent way to do zero-downtime instance replacement without building your own orchestration layer, but also they’ve had a years-long track record of shipping bad upgrades and following up with only manual remediations or workarounds instead of a fix. As someone who has…

I'm in a similar boat and only somewhat agree. The gist of my post was that this exists but maybe just use Kubernetes anyway.

I don't entirely agree with your statement about zero-downtime instance replacement though. We built our terraform around doing one-at-a-time instance replacement and removing/adding nodes in Hashicorp Raft clusters is pretty much the easiest thing I've ever done with infrastructure.

That's really always been the biggest selling point around Hashicorp's stuff for me. They made bootstrap and maintenance operations easy enough that a caveman could do it. Even recovering from problems isn't terribly hard unless you're already doing something stupid (Roblox outage).

I also have deployed and managed _hundreds_ of these over the last 8 years or so and I'm not really having the same problems that you do. But we don't upgrade to the latest and greatest because it _does_ take them a few versions to get their feature launches correct. This is mainly a Nomad problem now though -- consul and vault are pretty brainless to operate.

Still though, we _also_ use Kubernetes and I prefer it. Most of our software engineers don't though because they don't actually want to take the time to understand it, they just want to run binaries and forget about it.

Post reply on HN