Live data from Hacker News

Google admits Kubernetes container tech is too complex

theregister.com

121–130 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#121
post #119
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?

I think it's just a cute way of saying "data". Like saying you're seeding Linux ISOs when you're actually seeding pirated movies on BitTorrent.

Re: Google admits Kubernetes container tech is too complex

#122
post #119
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?

"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools"

— Douglas Adams

Re: Google admits Kubernetes container tech is too complex

#123

I can understand the use of kubernetes in very large orgs to manage clusters of hundreds of nodes, but it seems to me the complexity isn’t justified if you only have 1-100 say. There are lots of possibilities between 1 server and 100, and lots of ways to have simple replicable deploys if your needs are simple (probably 95% of businesses). Simple load balancers without auto-scaling work fine! For smaller non-critical…

No, but it’s not just complexity. We’re a small company, but after spending about a month to setup our GKE a couple of years ago (incl learning terraform in the process), it’s been rock solid, low involvement and reliable. Declarative resource specification is a legitimate game changer and you couldn’t pay me to go back.

Standardised declarative config/setup I've found really useful, declarative resource specification (as in n servers for service y) I don't really have a use for though I could see how in larger companies with hundreds of servers and lots of employees it would be attractive. If it is rock solid and reliable and impossible to mess up, I could see it being really nice (as your experiences sounds), though it feels to me like end users of services like GKE should not have to know about kubernetes or its complexity, nor have a chance to mess it up by editing configs directly.

I guess the ultimate goal of services like GKE autopilot is for you not to have to worry about kubernetes at all, just give them your workload and have it run on whatever resources they think is appropriate?

I do think it's important to recognise though that there are lots of ways to host services, and simpler with less abstractions is often better and more reliable and certainly easier to debug when things go wrong.

Re: Google admits Kubernetes container tech is too complex

#124
Slightly off topic: I use Google Cloud’s built in auto-scaling for instance groups, and I’m very happy with it. It offers a reasonable GUI, and a way for me to scale VM instances up and down based on e.g. CPU usage. It seems to do 80% of what I want at 5% the complexity of Kubernetes.

What I miss the most is having my infrastructure defined as code, instead of via the GUI. But given that I have only four services (out of which two use preemptible VMs and only one needs to scale) it’s not really a problem — it wouldn’t take me many minutes to replicate this setup at another cloud provider.

Re: Google admits Kubernetes container tech is too complex

#125
post #28

What happened to "focus on the business logic / application"? Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes? I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it. I wish more tools and platforms were like this.

Mind blowing to me that "Heroku but with docker images" doesn't seem to exist. Would love to be corrected!

It is coming. Check https://www.qovery.com/ and https://www.hyscale.io/

(Not affiliated with either)

Re: Google admits Kubernetes container tech is too complex

#126
post #46

Not seeing anyone mention it, so I'll just share: https://k8slens.dev/ Lens has been a huge boon for helping us manage our kube cluster and regular devops operations, and even 15 minutes with it helped me grok a number of complex kubernetes concepts that I've struggled with for awhile now. Everyone who works with k8s for a living should at least know of this tool imho its fantastic with prometheus

You should also check https://github.com/kubevious/kubevious

Re: Google admits Kubernetes container tech is too complex

#127
post #9

Earlier quoted context omitted.

They have a quote from the GKE lead directly saying "Despite 6 years of progress, Kubernetes is still incredibly complex." But it is a surprisingly negative headline. Autopilot sounds like a cool tool to simplify container orchestration!

> But it is a surprisingly negative headline. That's the Register's schtick, they're snarky about everything.

They are usually closer to the truth than evangelists telling us how this new tool is going to solve all our problems.

Re: Google admits Kubernetes container tech is too complex

#128

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.

Re: Google admits Kubernetes container tech is too complex

#129
post #20

This was glaringly obvious from day one. Containers add vast complexity, add another layer of complexity on top.

Containers don’t have to be complex. Docker and docker-compose are very simple to use. Docker swarm (rip) and Nomad are similar to kubernetes but orders or magnitude simpler.

I used to be a Docker fanboy. But after writing a few semi-complex Dockerfiles, and seeing more of how complex and FUBAR things like networking is [1], I changed my tune.

This was years ago, so maybe they greatly simplified things. But somehow I doubt it =/

[1] " Docker, by default, punches massive holes through your firewall in non-obvious ways. People don't realize that with a default Docker configuration, containers are ignoring any normal firewall rules you may have setup with iptables or ufw." - https://news.ycombinator.com/item?id=25834444

Re: Google admits Kubernetes container tech is too complex

#130

What happened to "focus on the business logic / application"? Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes? I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it. I wish more tools and platforms were like this.

My background is in embedded, so I admittedly know extremely little about web development, but whenever I'm curious and sit down to read about microservices and containers and orchestration and all that stuff, my mind starts to numb and I can't help but conclude that 99% of companies that use it probably don't need to. And that they're just a complex way for engineers to keep themselves spinning their wheels and not…

I do work in web app development, and what you say is spot on.
Post reply on HN