Live data from Hacker News

Dear friend, you have built a Kubernetes (2024)

macchaffee.com

51–60 of 183 posts

Re: Dear friend, you have built a Kubernetes (2024)

#51
post #20

Kubernetes networking is an inefficient mess.

Some CNIs are definitely better than others. Unfortunately it seems 99% of people want to work against the k8s networking model.

Shit just gets really weird when your network isn’t split for k8s in an equivalent way to what GCP/AWS expect. Like, if you have other services running on the nodes that you want things inside k8s to talk to, or if the nodes are in a flat subnet with other stuff in it, things get annoying. Those are worst practices for a reason, but pretty common in environments with home rolled k8s clusters.

Re: Dear friend, you have built a Kubernetes (2024)

#52
As someone rolling their self-hosted stuff via Compose and shell scripts instead of K8s specifically for the simplicity of the experience, this is 100% why you need to understand what Kubernetes solves before writing it off entirely.

I'm not doing overlay networks, I'm using a single bare-metal host, and I value the hands-on Linux administration experience versus the K8s cluster admin experience. All of these are reasons I specifically chose not to use Kubernetes.

The second I want HA, or want to shift from local VLANs to multi-cloud overlays, or I don't need the local Linux sysadmin experience anymore? Yeah, it's K8s at the top of the list. Until then, my solution works for exactly what I need.

Re: Dear friend, you have built a Kubernetes (2024)

#53
post #40
post #37

Earlier quoted context omitted.

I just feel like "you can do this with Kubernetes" is a slippery slope. "You can do X with Y, so use Y" is a great way to add a dependency, especially if it is "community vetted" already. Sometimes simple is better - you don't need to add anything that implements some of you logic as a dependency to stay DRY or whatever you want to call it. It really feels like we are drowning in self-imposed tech debt and keep addin…

You can use k8s on $2/mo digital ocean projects. It probably even works on the free tier of a lot of providers. And there's zero setup. Just a deployment yaml that specifies exactly what you want deployed, which has the benefit of easy version control. I don't get why people are so bent on hating Kubernetes. The mental cost to deploy a 6-line deployment yaml is less than futzing around with FTP and nginx. Kube is the…

>And portable.

This made me audibly guffaw. Kubernetes is a lot of things, but "portable" is not one of them. GKE, EKS, AKS, OCP, etc., portability between them is nowhere near guaranteed.

Re: Dear friend, you have built a Kubernetes (2024)

#54
post #4

The saddest part about Kubernetes is… after you set it all up, you still need a hacky deploy.sh to sed in the image tag to deploy! And pretty soon you’re back to “my dear friend you have built a Helm”. And so the configuration clock continues ticking…

Or if your colleagues are "smarter" than you they make it in Clojoure instead, with an EDN-but-with-subroutines config language, so that not only yaml-aware editors are useless, but EDN-aware editors cannot make heads or tails of the macros.

Fun times.

Re: Dear friend, you have built a Kubernetes (2024)

#55
post #16

"Except if you quit or go on vacation, who will maintain this custom pile of shell scripts?" LLMs can reason about and fix them quite well.

Not as well as they can reason (or others can google) something as standardized as kubernetes. There’s just less context (in both senses of the term) needed to understand something running on a common substrate versus something bespoke, even if the bespoke thing is itself comprised of standardized parts.

Re: Dear friend, you have built a Kubernetes (2024)

#56
post #40
post #37

Earlier quoted context omitted.

I just feel like "you can do this with Kubernetes" is a slippery slope. "You can do X with Y, so use Y" is a great way to add a dependency, especially if it is "community vetted" already. Sometimes simple is better - you don't need to add anything that implements some of you logic as a dependency to stay DRY or whatever you want to call it. It really feels like we are drowning in self-imposed tech debt and keep addin…

You can use k8s on $2/mo digital ocean projects. It probably even works on the free tier of a lot of providers. And there's zero setup. Just a deployment yaml that specifies exactly what you want deployed, which has the benefit of easy version control. I don't get why people are so bent on hating Kubernetes. The mental cost to deploy a 6-line deployment yaml is less than futzing around with FTP and nginx. Kube is the…

> Suddenly you have to become Sysadmin/SRE

I don't you made that argument but could a valid conclusion of your comment be that, because Kubernetes is so ubiquitous, using it frees you from being a Sysadmin/SRE?

Re: Dear friend, you have built a Kubernetes (2024)

#57
im just about giving OPs premise another go. compose just feels so much better as abstraction especially with small and medium setups looking close to the optimum of expressiveness without boilerplate to describe what is needed. The missing pieces seem to also be in the compose compatible “docker stack” aka new docker swarm, which i ignored for probably too long as i assumed it was the discontinued old swarm. Even if new swarm mode sucks how hard can it be to make something compose shaped vs running k8?

Re: Dear friend, you have built a Kubernetes (2024)

#58
I can tell you how vendors deliver a software solution that runs on Kubernetes: very poorly.

The needed tweaks, the ability to customize things, basically goes to zero because the support staff is technical about the software, but NOT about Kubernetes.

I am not joking: a recent deployment required 3x VMs for Kubernetes, each VM having 256 gigabytes of RAM; then a separate 3x VMs for a different piece. 1.5TB of RAM to manage less than 1200 network devices (routers etc. that run BGP).

No one knew, for instance, how to lower the MongoDB (because of course you need it!) resource usage, despite the fact that the clustered VMware install is using a very fast SSD storage solution and thus MongoDB is unlikely accelerate anything; so over 128GB RAM is being burned on caching the results coming back from SSDs that are running at many-GB/s throughput.

Re: Dear friend, you have built a Kubernetes (2024)

#59
post #21
post #5

> I know you wanted to "choose boring tech" to just run some containers. The people advocating for boring tech generally aren't interested in containers. You can just run programs.

Containers are just statically-linked programs for the rest of us.

I am a big fan which is why I am saying this: you're dismissing the kernel and ABI surface is a huge assumption that must hold true for your comment to hold stavros.

If you had said "unikernels" I would have had no arguments to make.

Re: Dear friend, you have built a Kubernetes (2024)

#60
> Ah, but wait! Inevitably, you find a reason to expand to a second server

>> The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

-- Donald Knuth, Computer Programming as an Art (1974)

EDIT:

> Except if you quit or go on vacation, who will maintain this custom pile of shell scripts?

Honestly? I don't care. There is a reason why I quit and 99% of time it's the pay. And if the company doesn't pay me enough to bother then why should I? Why should I bother about some company future in the first place?

Post reply on HN