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

I Didn't Need Kubernetes, and You Probably Don't Either

benhouston3d.com

Post reply on HN
Print view View original

401–410 of 436 posts

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#401

Post by CursedSilicon »

tombert wrote: post #90

I’ve come to the conclusion that I hate “cloud shit”, and a small part of me is convinced that literally no one actually likes it, and everyone is playing a joke on me. I have set up about a dozen rack mount servers in my life, installing basically every flavor of Unix and Linux and message busses under the sun in the process, but I still get confused by all the Kubectl commands and GCP integration with it. I might j…

Are you hiring? (only somewhat sarcastic)

I did a 15~ month stint at AWS. Originally I was signed on to be a support engineer for their Linux teams, which sounded great! Absolutely within my skillset and a great way to get to play with new technologies and features at scale that I haven't before (Ansible, etc)

After going through all the hoops I get sidelined into the "Containers" team and have to learn Kubernetes, ECS, Fargate etc all effectively from scratch

It's all miserable. All of it. Massive Rube Goldberg machines of complexity for the sake of complexity that you need a team to decipher, let alone maintain.

Unfortunately it feels like all the Sysadmin jobs have been replaced either by "DevOps" or Cloud Engineers. There's little market left for people who just want to keep boxes inside a datacenter (or on prem) humming along. The ones that do all want that also seem to be all wedded to MSP's unfortunately

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#402

Post by jterrys »

wruza wrote: post #219
carlmr wrote: post #210

Earlier quoted context omitted.

>expert blindness at work. >It's not that complicated if you limit yourself to the core stuff. Isn't this the core problem with a lot of technologies. There's a right way to use it, but most ways are wrong. An expert will not look left and right anymore, but to anyone entering the technology with fresh eyes it's a field with abundance of landmines to navigate around. It's simply bad UX and documentation. It could pro…

This and a terminology rug pull. You wanted to upload a script and install some deps? Here’s your provisioning genuination frobnicator tutorial, at the end of which you’ll learn how to maintain the coalescing encabulation for your appliance unit schema, which is needed for automatic upload. It always feels like thousands times bigger complexity (just in this part!) than your whole project.

You nailed it. Genuinely the most frustrating part about learning kubernetes... is just realizing that whatever the fuck they're talking about is a fancy wrapper for a concept that's existed since 90s.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#403

Post by pas »

otabdeveloper4 wrote: post #225
ants_everywhere wrote: post #42

People talk about Kubernetes as container orchestration, but I think that's kind of backwards. Kubernetes is a tool for creating computer clusters. Hence the name "Borg" (Kubernetes's grandpa) referring to assimilating heterogeneous hardware into a collective entity. Containers are an implementation detail. Do you need a computer cluster? If so k8s is pretty great. If you don't care about redundancy and can get all t…

> Containers are an implementation detail. They really aren't. Personally I have a big Nix derivation to deploy my (heterogeneous) cluster to bare metal. None of the k8s concepts or ideas apply here.

how does it work? how many nodes? what do you use for consensus, request routing, etc...?

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#404

Post by fhke »

>The high cost arises from needing to provision a bare-bones cluster with redundant management nodes.

?!

How else are you managing your infrastructure besides having redundancy in the control plane? Even if it’s a chef or puppet server, or even sysadmin Dave running scripts on his laptop, you should still have redundancy.

> Moreover, Kubernetes’s slow autoscaling meant I had to over-provision services to ensure availability, paying for unused resources rather than scaling based on demand.

??????

Slow compared to what exactly? Anecdotally, k8s with karpenter is significantly faster to scale than auto scaling groups.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#405

Post by fhke »

coldtea wrote: post #266
voidfunc wrote: post #107

Earlier quoted context omitted.

I'm always kind of blown away by experiences like this. Admittedly, I've been using Kubernetes since the early days and I manage an Infra team that operates a couple thousand self-managed Kubernetes clusters so... expert blindness at work. Before that I did everything from golden images to pushing changes via rsync and kicking a script to deploy. Maybe it's because I adopted early and have grown with the technology i…

> Before that I did everything from golden images to pushing changes via rsync and kicking a script to deploy. Sounds like a great KISS solution. Why did it regress into Kubernetes?

> Why did it regress into Kubernetes

The “KISS solution” didn’t scale to the requirements of modern business. I remember running chef - essentially a complicated ruby script - on 100ks of servers, each of which with their own local daemon & a central management plane orchestrating it. The problem was that if a server failed… it failed, alongside everything on it.

Compared to that setup, k8s is a godsend - auto healing, immutable deployments, scaling, etc - and ultimately, you were already running a node agent, API, and state store, so the complexity lift wasn’t noticeable.

The problem came about when companies who need to run 5 containers ended up deploying a k8s cluster :-)

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#406

Post by pas »

rnts08 wrote: post #216

The worst thing about the whole kubernetes-cult and the like is that IaC and CM was supposed to help us reduce configuration, to make it less prone to failure and easier to manage. But the truth is that we ran service based architecture, network meshes and containers with bash just fine before cloud everything, usually with less effort than it is to do literally anything today. Sure you had to know how to set up netw…

Good for you, my bash on balls was unfortunately not able to solve service based meshtainer architecture :(

I remember how kernel module params for ALG/bonding/teaming had to be figured out for each fancy NIC/driver, it was fun, but definitely not great. Of course this is mostly solved if you pay the cloud premium.

Most businesses need a product guy/gal, a website, then a developer, then later one VM or Heroku or something. And maybe if there's at least a few customers, yeah, it makes sense to think about ops (as in business ops), and then eventually sure, engineering needs to scale to solve the challenges, and that might mean getting a sysadmin.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#407

Post by stitched2gethr »

shrubble wrote: post #16
valenterry wrote: post #12

Earlier quoted context omitted.

So, let's say you want to deploy server instances. Let's keep it simple and say you want to have 2 instances running. You want to have zero-downtime-deployment. And you want to have these 2 instances be able to access configuration (that contains secrets). You want load balancing, with the option to integrate an external load balancer. And, last, you want to be able to run this setup both locally and also on at least…

Do you know of actual (not hypothetical) cases, where you could "flip a switch" and run the exact same Kubernetes setups on 2 different cloud providers?

I'm just happy to see the tl;dr at the TOP of the document.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#408

Post by jiggawatts »

pdimitar wrote: post #400
jiggawatts wrote: post #397

Earlier quoted context omitted.

That was pretty boring too! The "script" was just a few hundred lines of C# code triggering Selenium via its SDK. The requirement was simply to load a set of URLs with two different browsers, an "old" one and a "new" one that included a (potentially) breaking change to cookie handling that the customer needed to check for across all sites. I didn't need to fully crawl the sites, I just had to load the main page of ea…

EXTREMELY nice. Wish I was paid to do that. :/

So do I! :(

I only get a "fun" project like this once every year or two.

Selling this kind of thing is basically impossible. You can't convince anyone that you have an ability that they don't even understand, at some fundamental level.

At best, you can incidentally use your full set of skills opportunistically, but that's only possible for unusual projects. Deploying a single VM for some boring app is always going to be a trivial project that anyone can do.

With this project even after it was delivered the customer didn't really understand what I did or what they got out of it. I really did try to explain, but it's just beyond the understanding of non-technical-background executives that think only in terms of procurement paperwork and scopes of works.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#409

Post by czhu12 »

gizzlon wrote: post #320
czhu12 wrote: post #44

I'm not sure google cloud run can be considered a fair comparison to Kubernetes. It would be like saying AWS Lambda is a lot easier to use than EC2. I've used both Kubernetes and GCR at the current company I cofounded, and theres pros and cons to both. (Team of about 10 engineers) GCR was simple to run simple workloads, but, an out of the box Postgres database can't just handle unlimited connections and so connecting…

> an out of the box Postgres database can't just handle unlimited connections and so connecting to it from GCR without having a DB connection proxy like PG bouncer risks exhausting the connection pool. Good point. How many connections can it handle? Seems like it's up to 262142 in theory? Or am I reading this wrong: https://cloud.google.com/sql/docs/postgres/flags#postgres-m ?? But even 1000 seems ok? 1 per container…

This assumes your Postgres has a an infinite amount of memory which would also be very expensive. I think you'd probably want to assume each connection takes ~10-20MB of memory.
Post reply on HN