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

381–390 of 436 posts

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

#381

Post by zelphirkalt »

erinaceousjones wrote: post #232
torginus wrote: post #201

Earlier quoted context omitted.

Kubernetes starts sucking at first sight and is kind of the sign of the ailment of modern times. Let me try to explain: First, you encounter the biggest impedance mismatch between cloud and on prem: Kubernetes works with pods, while AWS works with instances as the unit of useful work, so they must map to each other, right? Wrong, first each instance needs to run a Kubernetes node, which duplicates the management infr…

Being nitpicky about Python specifically, Python not necessarily single-threaded; gunicorn gets you a multiprocess HTTP/WSGI server if you configure it to. asyncio and gevent have made it easier to do things actually-concurrently. Judicious use of generator functions lets you stream results back instead of blocking I/O for big chunks. And we have threads. Yeah, the Global Interpreter Lock is still hanging around, it'…

Here I thought you would bring multiprocessing and process pool in Python.

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

#382

Post by kortilla »

tombert wrote: post #368
kortilla wrote: post #212

Earlier quoted context omitted.

All of these anecdotes seem to come from people who don’t bother to try to learn kubernetes. > YAML files, and then spend a day fixing them by copy-pasting increasingly-convoluted things on stackexchange. This is terrible behavior. Its not any different from yanking out pam modules because you’re getting SSH auth failures caused by a bad permission on an SSH key. > If I get to tens of millions of users, maybe I’ll wo…

Sure, because Kubernetes is convoluted and not fun and is stupidly bureaucratic. I might learn to enjoy being kicked in the balls if I practiced enough but after the first time I don't think I'd like to continue. > This is terrible behavior. Its not any different from yanking out pam modules because you’re getting SSH auth failures caused by a bad permission on an SSH key. Sure, I agree, maybe they should make the en…

> Sure, because Kubernetes is convoluted and not fun and is stupidly bureaucratic.

Describe what you think bureaucratic means in a tool.

> I might learn to enjoy being kicked in the balls if I practiced enough

This is the same thing people say who don’t want to learn command line tools “because they aren’t intuitive enough”. It’s a low brow dismissal holding you back.

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

#383

Post by kortilla »

secondcoming wrote: post #218
kortilla wrote: post #212

Earlier quoted context omitted.

All of these anecdotes seem to come from people who don’t bother to try to learn kubernetes. > YAML files, and then spend a day fixing them by copy-pasting increasingly-convoluted things on stackexchange. This is terrible behavior. Its not any different from yanking out pam modules because you’re getting SSH auth failures caused by a bad permission on an SSH key. > If I get to tens of millions of users, maybe I’ll wo…

Just because you're using VMs doesn't mean you're now dealing with state. It's 100% possible to have stateless VMs running in an auto-scaling instance group (in GCP speak, I forget what AWS calls them)

Once you have the tools to manage all of that, you effectively have kubernetes. Container vs VM is largely irrelevant to what the op is complaining about when it comes to k8s.

People that don’t like k8s tend to be fine with docker. It’s usually that they don’t like declarative state or thinking in selectors and other abstractions.

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

#384

Post by Havoc »

tombert wrote: post #365
Havoc wrote: post #295

Earlier quoted context omitted.

“let me install everything myself” doesn’t generalise well and gets messy even if you IaC it. There is a reason k8s gang keeps going on about “cattle not pets”. The starting assumptions and goals are fundamentally different vs “give me a physical server” Both have their place I think so not really one is right other is wrong

Everyone says this, but do we actually have data to back that up? I feel like I spend so much time working around CloudSQL for postgres support in GCP at work, to a point where I'm not actually sure I'm saving a ton of time over running and managing it myself. That's probably not true, I'm sure there are edge cases that I'm not accounting for, but I'm a little tired of everyone acting like AWS and GCP and Azure are t…

Not sure how you’d even measure that meaningfully.

My comment above was more k8s vs classic server rather than thinking about cloud k8s in particular.

I do agree that cloud is stuff is a huge time sink. I’ve learned to look at it in terms of how close it is to FOSS like world. Things that follow normal protocols and standards like say it speaks Postgres or is a docker image then cloud is ok. Things that are cloud vendor specific or a custom product…run for the hills. Not only is it lock in but also that’s where the pain you describe is. The engineering around it just becomes so much more granular and fragile

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

#385

Post by p_l »

cyberpunk wrote: post #378
p_l wrote: post #357

Earlier quoted context omitted.

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. :}

I didn't mean replace istio with cilium, I meant running the proxy and routing operations as shared part per node instead of per pod

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

#386

Post by cyberpunk »

p_l wrote: post #385
cyberpunk wrote: post #378

Earlier quoted context omitted.

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. :}

I didn't mean replace istio with cilium, I meant running the proxy and routing operations as shared part per node instead of per pod

How does that even work with envoy? The magic sauce behind istio is that every connection is terminated using iptables into the envoy process (sidecar), and istiod spaffs envoy configurations around the place based on your vs/dr/pas/access controls etc.

I suppose you could have a giant envoy and have all the proxy-configs all mashed together but I really don't see any benefit to it? I can't even find documentation that says it's possible..

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

#387

Post by withinboredom »

zelphirkalt wrote: post #379
withinboredom wrote: post #275

Earlier quoted context omitted.

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

Wherever they came from, I suppose. There’s a reason they left.

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

#388

Post by p_l »

cyberpunk wrote: post #386
p_l wrote: post #385

Earlier quoted context omitted.

I didn't mean replace istio with cilium, I meant running the proxy and routing operations as shared part per node instead of per pod

How does that even work with envoy? The magic sauce behind istio is that every connection is terminated using iptables into the envoy process (sidecar), and istiod spaffs envoy configurations around the place based on your vs/dr/pas/access controls etc. I suppose you could have a giant envoy and have all the proxy-configs all mashed together but I really don't see any benefit to it? I can't even find documentation th…

Couldn't check all details yet, but from quick recap:

It's called ambient mode, and uses separate L4 and L7 processing on ways that would be familiar to people who dealt with virtual network functions - and neither l4 nor l7 parts require sidecar

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

#389

Post by gavindean90 »

osigurdson wrote: post #14
gavindean90 wrote: post #5

K8s always seems like the tool that people choose to avoid cloud vendor lock in but there is something to be said for C k8s lock in as well as the article points out. If you end up with exotic networking or file system mounts you can just be stuck maintaining k8s forever and some updates aren’t so stable so you have to be more vigilant that windows updates.

I don't think it makes sense to conflate vendor lock-in with taking a dependency on a given technology. Do we then have "Linux lock-in" and "Postgres lock-in"? The term "lock-in" shouldn't be stretched to cover this concept imo.

It’s not quite the same thing as a commercial vendor lock in but it’s close.

You can have Postgres lock in as much as Wordpress has MySql lock in.

I agree that you have less Linux lock in but Docker still requires a Linux kernel everywhere it goes. BSD need not apply.

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

#390

Post by mmcnl »

voidfunc wrote: post #107
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…

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…

I didn't grow up in the trenches like you did, but nonetheless I think Kubernetes has a very user-friendly API. Imo Kubernetes is only complex because IT infrastructure is complex. It just makes the complexity transparant and manageable. Kubernetes is a friendly guide helping you navigate the waters.
Post reply on HN