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

201–210 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#201

Post by aristofun »

Relevant question https://news.ycombinator.com/item?id=25944804

Im still wondered how people could give a green light to something that makes their life _harder_ not _better_ just because “it’s Google”.

My guess is — you can make more money on something as overcomplicated and non-developer friendly as k8s.

Imagine how many companies would never even exist if k8s was like a bit advanced version of swarm.

How many talented developers would be free to make something valuable for the world.

Instead of just solving stupid problems created by another developers with questionable design choices.

Re: Google admits Kubernetes container tech is too complex

#202

Post by nanis »

As I understand it, the main benefit of Kubernetes is the ability to pack multiple applications in a single VM. This way, one uses fewer paid resources to deploy a service mesh. In return for actually being able to show that you are not wasting any RAM or IO, you give up isolation.

The "declarative" part of Kubernetes control buried in YAML seems to fail to live up to that label.

Is there any literature that shows that the cost savings from packing more than one service per VM are significant enough to outweigh the cost of the messes created by middling developers who have trouble reasoning about the functioning of single process application at non-Google companies create when they think they should do what Google does?

Re: Google admits Kubernetes container tech is too complex

#203

Post by moksly »

dmingod666 wrote: post #191
bob1029 wrote: post #176

I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…

After that single node crashes, the app you're running on that one server will run a little more slowly.. How big should the one server that serves the whole of netflix be..?

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.

Re: Google admits Kubernetes container tech is too complex

#204

Post by nanis »

runeks wrote: post #119
fen4o wrote: post #13

I understand their rationale. We manage thousand Kubernetes clusters and end-users can find lots and lots of creative way to shoot themselves in the foot: - I can store anything in a secret? Let's have thousands of cat images. Etcd then stops working because we have over 2GB of funny cats in the key store. - I can run a root Pod? Lets mount the docker socket and start building images with it. Oh and by the way, I nev…

> I can store anything in a secret? Let's have thousands of cat images. Why would someone want to store non-secret information as a secret?

> Why would someone want to store non-secret information as a secret?

Top reason given to me by developers: "I don't want to spend time thinking about the distinction."

Re: Google admits Kubernetes container tech is too complex

#205

Post by fendy3002 »

bob1029 wrote: post #176

I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…

I suppose your apps ran on windows. It isn't a problem (or at least it's a smaller problem) with windows ecosystem, especially enterprise one, since usually you're using same version and installation steps handled by infra with AD. Even without AD usually the installer and windows version is same, and Microsoft usually great at backwards compatibility.

But it's not the case in linux, or at least non-enterprise / ldap linux. Installing mysql/redis/elastic/dotnet core/etc on each machine may be different, and has different installer available.

With docker I just need to instruct them to install docker, setup docker compose and everything is handled via containerization.

Re: Google admits Kubernetes container tech is too complex

#206

Post by dmingod666 »

ant6n wrote: post #193
dmingod666 wrote: post #191

Earlier quoted context omitted.

After that single node crashes, the app you're running on that one server will run a little more slowly.. How big should the one server that serves the whole of netflix be..?

"You can handle millions of simultaneous clients without blinking. Who even has that many total customers right now?" Apparently netflix has that many customers. Then again, if you split Netflix into regions and separate all the account logic from the streaming, the recommendations engine and the movie-content, you could perhaps run the account logic for one region in one server.

Besides just giving you a warm fuzzy feeling of running only one server.

What is the point of running one server?

Do you also object to them running in the cloud in VMs and not on physical hardware that they own? Sounds like an old man's "kids these days" rant..

Re: Google admits Kubernetes container tech is too complex

#207

Post by FridgeSeal »

cies wrote: post #128
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…

I once have been told that development teams smaller than 20 developers have no business in using k8s, due to the complexity to brings. If something as essential as the infra so complex it is not readily understood by everyone on the team, a few (more than one) team members need to become the experts on the matter. For small teams this is simply not worth it.

As part of a small team currently using Kubernetes, I suspect it’s more how you use it - the tools and ecosystem have matured immensely in the last couple of years since I’ve first started using it.

I don’t think it suits all teams and use cases, but for us it’s absolutely fantastic and without going down the rabbit-hole of cloud-provider specific tools and recreating half the issues it solves, I’m not super sure what we’d use.

Re: Google admits Kubernetes container tech is too complex

#208

Post by bedobi »

At a previous job, our build pipeline

* Built the app (into a self container .jar, it was a JVM shop)

* Put the app into a Ubuntu Docker image. This step was arguably unnecessary, but the same way Maven is used to isolate JVM dependencies ("it works on my machine"), the purpose of the Docker image was to isolate dependencies on the OS environment.

* Put the Docker image onto an AWS .ami that only had Docker on it, and the sole purpose of which was to run the Docker image.

* Combined the AWS .ami with an appropriately sized EC2.

* Spun up the EC2s and flipped the AWS ELBs to point to the new ones, blue green style.

The beauty of this was the stupidly simple process and complete isolation of all the apps. No cluster that ran multiple diverse CPU and memory requirement apps simultaneously. No K8s complexity. Still had all the horizontal scaling benefits etc.

Re: Google admits Kubernetes container tech is too complex

#209

Post by lordlimecat »

fendy3002 wrote: post #205
bob1029 wrote: post #176

I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…

I suppose your apps ran on windows. It isn't a problem (or at least it's a smaller problem) with windows ecosystem, especially enterprise one, since usually you're using same version and installation steps handled by infra with AD. Even without AD usually the installer and windows version is same, and Microsoft usually great at backwards compatibility. But it's not the case in linux, or at least non-enterprise / ldap…

Forgive my ignorance, but can't that be solved by statically linking things?

Don't you just end up with a less hackjob version of a container when you do that?

Re: Google admits Kubernetes container tech is too complex

#210

Post by pjmlp »

fendy3002 wrote: post #205
bob1029 wrote: post #176

I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…

I suppose your apps ran on windows. It isn't a problem (or at least it's a smaller problem) with windows ecosystem, especially enterprise one, since usually you're using same version and installation steps handled by infra with AD. Even without AD usually the installer and windows version is same, and Microsoft usually great at backwards compatibility. But it's not the case in linux, or at least non-enterprise / ldap…

Back when I was doing big boys UNIX, the respective package managers took care of everything.

Which we later replicated in Red-Hat with RPM.

Bare bones OS install + bunch of OS packages => done.

And in what concerns containers I was working with HP-UX Vault in 1999.

Post reply on HN