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

Google admits Kubernetes container tech is too complex

theregister.com

Post reply on HN
Print view View original

261–270 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#261

Post by eeZah7Ux »

keanebean86 wrote: post #18
taeric wrote: post #3

I can't fight the feeling that this is all circling back to the application server stuff that was popular for a time. And, really, I can't tell when those went so wrong. :(

The circle of tech: 1. Someone has an idea. It's alright. Really good for their use case. Someone else hears about it, likes it, and adapts it to a similar use case. So and so forth until the idea has a large user base 2. Employees of large companies hear about the idea and implement it 3. Marketing gets a hold of the idea, gives it a flashy name, and uses it in promotions 4. A majority of the loudest voices in the i…

This is quite accurate. On top of that:

1. Build an opinionated solution that you control fully (e.g. difficult to fork).

2. Convince everybody to adopt it. Nobody gets fired for choosing $bigcorp

3. Grow it complex and expensive to maintain over time.

4. SELL software and services to manage its complexity.

...and the industry is getting more marketing/fad/resume-driven every day.

Re: Google admits Kubernetes container tech is too complex

#262

Post by alephu5 »

KronisLV wrote: post #155
sofixa wrote: post #79

Earlier quoted context omitted.

Docker Swarm is pretty much abandonware/on life support at best, so one should avoid using it for new stuff. Hashicorp's Nomad is the best choice on the complexity for features scale IMHO, and that's why i'm writing an article how great it is, how easier some things are and what's missing compared to Kubernetes.

And yet, Docker Compose is pretty popular for local development, so much so, that it's not uncommon to find a docker-compose.yml in the repositories for many open source projects. And Docker Swarm builds on that, by bridging the gap between Docker Compose and multi-server deployments, with tools like Swarmpit and Podman for easier management of it as well, much like Rancher does for Kubernetes. I agree that Docker Sw…

I quite like swarm for its compatibility with docker-compose, in particular to have the option of zero downtime deploys. If I wanted to manage a real cluster though I'd probably use nomad or GKE to avoid getting burned when the system is under load.

Re: Google admits Kubernetes container tech is too complex

#264

Post by OldHand2018 »

dmingod666 wrote: post #219
moksly wrote: post #203

Earlier quoted context omitted.

Stackoverflow has always run on a couple of IIS instances. If you’re not bigger than them don’t worry. You can pretend to be Netflix or Google, and build your tech-stack like they do. Or you can stop wasting your resources setting up a tech stack that you’re never going to get a return of investment on.

Why a few though? Couldn't they do with just 1..? that would make people on HN more happier it seems. Stack Overflow is not a unit of measurement that anyone would be able to take seriously or find useful? How many stack overflows is one asana? Or how many stack overflows is one trello? Horizontal scaling, docker K8s have their own benefits that are many and obviously to the industry. you don't need to be google to d…

> Or how many stack overflows is one trello?

I shall not express any opinion on this topic other than to say that Trello is not a good example to bring up. The entire customer base of Trello is not using a single shared board and thus they could scale in any direction they wanted to maximize ROI.

Re: Google admits Kubernetes container tech is too complex

#265

Post by bavell »

dtech wrote: post #77
trinovantes wrote: post #36

Kubernetes has to be most complex software I've ever tried to learn. I eventually gave up and decided to stick with simple single machine docker-compose deployments. I figure by the time any of my personal projects actually need to scale beyond 1 machine, I'd probably have enough revenue that I can afford to hire someone else to worry about it.

Yes, k8s is not built for solo outfits and small projects. In places with 10+ developers and 10+ services on a single cluster it works surprisingly well from the user (developer) side.

Hmm, I guess I should shut down my business then since I'm a solo founder using k8s exclusively for my hosting for 3+ years...

Definitely a learning curve but honestly not bad if you like ops. Absolutely possible and beneficial for any size team. As always, it depends on what your goals are and how you want to use k8s.

Re: Google admits Kubernetes container tech is too complex

#266

Post by yowlingcat »

vp8989 wrote: post #247
anchochilis wrote: post #221

I work on a 3-person DevOps team that just finished migrating ~20 services from GCE vms running docker-compose to GKE. It's taken us a little over a year. Partly because K8s has a steep learning curve, but also because safely transitioning services without disrupting product teams adds a lot of overhead. The investment is already yielding great returns. Developers are happy. Actual quote: "Kubernetes is the biggest q…

"Kubernetes is the biggest quality-of-life improvement I've experienced in my career." Can you elaborate? What exactly about Kubernetes improved the developers life?

Can only speak for myself personally, but having gone through a similar moment, it was 50% docker QoL improvements and 50% k8s QoL improvements -- most significantly around prod/dev parity. Every engineer in my org really did gain a significant amount of confidence around being able to spin up and deploy new services (when necessary) without being nervous about something going wrong in prod that wasn't configured properly in a lower environment.

Re: Google admits Kubernetes container tech is too complex

#267

Post by ThinkBeat »

yonixw wrote: post #257
rbanffy wrote: post #217

Earlier quoted context omitted.

When you approach the limits of what your kernel can handle, then it may be time to split your workload across boxes or to carve smaller boxes out of your metal (and probably directly attaching NICs to the VMs to the host OS doesn't have to deal with them). Making your workload horizontally scalable is always a sound engineering choice. But... Splitting a horizontally scalable workload across a dozen virtual servers…

> When you approach the limits of what your kernel can handle Even before. If you want low latency. And banks handle more than 10K concurrent every day. Cost example: https://pt.slideshare.net/markmyers106/vertical-vs-horizonta...

Yes some banks need it As do giants like Google Facebook etc

Chances are very high that the problem domain you are working in does not.

Like the author said “1%” I think maybe 5% to 7%

The point being that masses of software is developer everyday on a cargo cult adoption of solution they do not require.

Re: Google admits Kubernetes container tech is too complex

#268

Post by Guest42 »

vp8989 wrote: post #250
z9e wrote: post #233

Earlier quoted context omitted.

... Until they hire you back because entropy exists :P I'm on the DevOps side as well going through the same transition, k8s also allows insane customization, and I have some colleagues that are delaying our rollout unintentionally so they can play around with developing more tooling for deployments which is really frustrating. The k8s scene seems to be filled with constant scope creep and refactoring to get it just…

"I have some colleagues that are delaying our rollout unintentionally so they can play around with developing more tooling for deployments which is really frustrating." My impression is that the primary purpose of Kubernetes is to give SRE teams political air cover to rewrite a lot of their existing processes. Whether Kubernetes is actually required for that, or even net superior seems questionable. This unsexy work…

Yes, the number of proposed db switched I’ve seen is remarkably high. I once interviewed for a role as a database developer and was confused to find out they didn’t have the database that the role pertained to. One of the early questions in the interview was how quickly I could migrate production from ms sql to pg. Needless to say that was a gigantic red flag and I hope they found the right person for that job.

I’ve also seen a switch from rdbms to Hadoop because a company had “millions” of rows. Luckily on this one I only had to rewrite a handful of queries.

Re: Google admits Kubernetes container tech is too complex

#269

Post by kyrra »

ec109685 wrote: post #23
kyrra wrote: post #2

Googler, opinions are my own. Direct link to the docs: https://cloud.google.com/kubernetes-engine/docs/concepts/aut... Google has a tool by the same name (autopilot) internally that does close to the same thing. There was a paper published on it 10 months ago talked about here: https://news.ycombinator.com/item?id=22980467

Is this really the same thing? The paper is talking about auto adjusting workload limits based on job history, right?

Probably the scaling aspect of k8s autopilot is the only part that is similar. The rest looks similar to functionality provided by other tools internally.

But likely they shared little in common.

Re: Google admits Kubernetes container tech is too complex

#270

Post by orthoxerox »

FlyingSnake wrote: post #109

Putting on my Asbestos Longjohns: The more I look into k8s ecosystem, the more I'm convinced that it's one of those things that suits FAANG etc, but the regular Joe developer has caught on the fad and wants to add it to his repertoire, even though it's an overkill. After all no one got fired for buying IBM and recommending Kubernetes. Most teams need a simpler deployment strategies that other's have succinctly mentio…

In my opinion, k8s starts to shine when you have to manage hundreds of containers. When you have just dozens of them it's an overkill, but there's no way to smoothly slot in another solution between "docker-compose up -d" and spinning up a k8s cluster: you will (or think you will) hit a maintainability ceiling again and have to migrate to k8s.
Post reply on HN