Live data from Hacker News

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

benhouston3d.com

371–380 of 436 posts

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

#371

We dabbled with Cloud Run and Cloud Functions (which as of v2 are just a thin layer over Cloud Run anyways). While they worked fine for HTTP workloads, we wanted to use them to consume from Pub/Sub and unfortunately the "EventArc" integrations are all HTTP-push based. This means there's no back pressure, so if you want the subscription to buffer incoming requests while your daemons work away there's no graceful way t…

> The push subscription will just ramp up attempting to DoS your Cloud Run service Interesting. My assumption would be that Cloud Run should quickly* spin up more containers to handle the spike and then spin them down again. So there would be no need for back pressure? Guess it depends on the scale? How big of a spike are we talking about? :) *Let's say a few seconds

You typically have it configured with a cap on instances for cost reasons.

Even if you don't, if you have other services (like a database) downstream, you might not want it to scale infinitely as then you're simply DoS'ing the DB instead of the Cloud Run service.

Backpressure is really important for the resiliency of any distributed system, IMO.

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

#372

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…

If I had set up the infrastructure myself I'd probably have a different opinion on all of this stuff, but I came into this job where everything was set up for me. I don't know if it was don't "incorrectly", and I do fear that stating as such might get into territory adjacent to the "no true Scotsman" fallacy. I mostly just think that k8s integration with GCP is a huge pain in the ass, every time I have to touch it it…

What about your integration makes it a huge pita?

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

#373
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…

> I have set up about a dozen rack mount servers in my life,

yes, k8s and co are silly for trivially tiny systems like this.

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

#374

Earlier quoted context omitted.

If I had set up the infrastructure myself I'd probably have a different opinion on all of this stuff, but I came into this job where everything was set up for me. I don't know if it was don't "incorrectly", and I do fear that stating as such might get into territory adjacent to the "no true Scotsman" fallacy. I mostly just think that k8s integration with GCP is a huge pain in the ass, every time I have to touch it it…

What about your integration makes it a huge pita?

It's just a lot of stuff; we have a couple hundred services, and when I've had to add shit, it ends up with me updating like two hundred files.

Infrastructure as code is great, but lets be honest, most people are not thoroughly reading through a PR with 200+ files.

There's of course tpl files to help reduce duplication, and I'm grateful for that stuff when I can get it, but for one reason or another, I can't always do that.

It's also not always clear to me which YAML corresponds to which service, though I think that might be more of an issue with our individual setup.

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

#375
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…

I'll let you in on the joke. The joke is the demand for 100% availability and instant gratification. we're making services where anything less than 4 nines, which is 5 minutes month, is deemed unacceptable. three nines is 10 minutes a week. two nines is 15 minutes a day. there are some things that are important enough that you can't take a coffee break and wait for, but Kubernetes lets you push four nines of availabi…

I agree with you in theory, and maybe even in practice in some cases, but I do not feel like we have less downtime with k8s than using anything else.

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

#376
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…

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…

> It's not that complicated if you limit yourself to the core stuff

Completely agree. I use Kubernetes (basically just Deployments and CronJobs) because it makes deployments simple, reliable and standard, for a relatively low cost (assuming that I use a managed Kubernetes like GKE where I don’t need to care at all about the Kubernetes engine). Using Kubernetes as a developer is really not that hard, and it gives you no vendor lock-in in practice (every cloud provider has a Kubernetes offer) and easy replication.

It’s not the only solution, not the simplest either, but it’s a good one. And if you already know Kubernetes, it doesn’t cost much to just use it.

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

#377

Earlier quoted context omitted.

Why does a startup need zero-downtime-deployment? Who cares if your site is down for 5 seconds? (This is how long it takes to restart my Django instance after updates).

If you're doing CD where every push is an automated deploy a small company might easily have a hundred deploys a day. So you need seamless deployments.

I think it's a bit of an exaggeration to say a "small" company easily does 100 deployments a day.

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

#378
post #357

Earlier quoted context omitted.

To be fair, istio and cilium are extremely useful tools to have under your belt. There’s always a period of “omgwhat” when new senior engineers join and they want to improve things. There’s a short window between joining and getting bogged into a million projects where this is possible. Embrace it I recon.

Doing it well IMO requires not deploying everything as sidecar but maybe, maybe, deploying it as shared node service. In fact pretty sure I've read a write up from Alibaba? on huge wins in performance due to moving Istio out of sidecar and into shared node service.

Sure, cilium is also much faster than istio. But I guess it depends on your workload. We don't care all that much about performance vs compliance (non-hft finance transactional stuff) and I think we're doing things reasonably well. :}

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

#379
post #194

Earlier quoted context omitted.

Those "necessary" add-ons and sidecars are out of control, but its the people problem. I'm part of the infra team and we manage just couple of k8s clusters, but those are quite big and have very high traffic load. The k8s + terraform code is simple, with no hacks, reliable and easy to upgrade. Our devs love it, we love it too and all of this makes my job pleasant and as little stressful as possible. But we recently h…

> So its not inexperienced engineers wanting newest hotness because they have no idea how to solve stuff with the tools they have, its sometimes senior engineers trying to justify their salary, "seniority" by buying into complexity as they try to make themselves irreplaceable. The grass is always greener where you water it. They joined your company because the grass was greener there than anywhere else they could get…

They want to make it "greener" for whom? I think that is the question.

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

#380
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…

> There's a right way to use it, but most ways are wrong. This is my biggest complaint. There is no simple obvious way to set it up. There is no "sane default" config. > It's better to run minkube and get to know k8s first. Indeed. It should be trivial to set up a cluster from bare metal - nothing more than a `dnf install` and some other command to configure core functionality and to join machines into that cluster.…

That is actually what my "try out for a day" experience with Nomad was years ago. Just run the VMs, connect them, and they auto load balance. While it took a week or so to get even the most basic stuff in Kubernetes and not even have 2 hosts in a cluster yet, while having to deal with hundreds of pages of bad documentation.

I think since then the documentation probably has improved. I would hope so. But I will only touch Kubernetes again, when I need to. So maybe on a future job.

Post reply on HN