Live data from Hacker News

Google admits Kubernetes container tech is too complex

theregister.com

61–70 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#61
post #52

99.9 percent uptime for pods? That's 10 minutes downtime per week. We use simple VMs (on Google Cloud) at work and deploy services to them using Nix, and they have much less downtime than this. Does Kubernetes make it so difficult to do better than 99.9?

It's for the same people that make web apps that only works on 95% of browsers. They just don't care.

Re: Google admits Kubernetes container tech is too complex

#62
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

This looks awesome, I wish someone told me about this tool earlier.

Re: Google admits Kubernetes container tech is too complex

#63

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 used Docker for embedded.

Running a cluster across your IOT fleet (1k+ devices; 5-10 apps each) gives a nice interface for pushing out tasks, choosing applications for a device, configuring supervisor-device relationships, etc. It turns out from scratch Docker containers on ARM are very portable.

I think you’re being dramatic — embedded is notorious for crazy builds of weird config flags to even get “hello world” to compile, and you’re waving your arms pretending that concepts from Erlang abstracted away from the language are too much.

Docker is just cgroups and namespaces, with a zip file of code. More or less literally.

Orchestration is the same mess it’s always been — back to at least the telephone days, when Erlang used the same concepts.

Re: Google admits Kubernetes container tech is too complex

#64
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!

Think thats AWS Fargate, but admittedly i don't do a lot with Heroku.

Re: Google admits Kubernetes container tech is too complex

#65

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.

I’d recommend giving Docker Swarm + Traefik a shot. It’s dead simple to set up manually and has very little “magic” in how things work under the hood. Plus much of your existing Docker Compose config will work out of the box. It vastly simplified the deployment process too. I previously avoided Docker Swarm for ages since I assumed it involved the same level of complexity as k8s. I also initially figured that managed…

I use Swarm at home (only on a single node, because it turns out 3 are overkill for my needs) and it's been running great for 6 months so far. Before that I tried various incarnations of k8s and eventually they'd just destroy themselves up and require a rebuild (the main issue was persistent storage).

My only complaint with Swarm is there isn't an easy way to expose containers directly on the network (like host networking). I have a few containers (wireguard and minidlna) which need this, so those are running through docker-compose. I've tried macvlan but wasn't able to get that working in Swarm mode.

Re: Google admits Kubernetes container tech is too complex

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

You have a lot of tech companies digging up gold, and a whole lot more selling shovels to the rest of the crowd.

Most of the software tech world is bullshit. Most best practices are bullshit. And, if I were feeling a bit conspiratorial, I'd say the large tech companies do this on purpose. They promote fads that overburden any smaller company with more modest budgets, thus keeping competitors at an arm's length. Resume-driven-development plays a role in this as well.

A lot of companies following the FAANG cargo cult are digging their own grave and don't even know it. They don't realize they don't have the manpower for microservices. Or the calendar time to make it work and still get product out the door before their competitor that doesn't even unit test eats their entire lunch.

Re: Google admits Kubernetes container tech is too complex

#67
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 services sometimes even one reliable server is an acceptable trade-off.

Do most companies really need kubernetes given the complexity and difficulty it introduces?

Re: Google admits Kubernetes container tech is too complex

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

These are some delightfully specific hypotheticals.

Re: Google admits Kubernetes container tech is too complex

#69
I thought I read somewhere that the creator of WebSphere expressed similar opinions about his creation, and others have even called it mentally abusive.

Perhaps the enterprise class stuff is always just for large division of labor efforts. Like the "Liberty" stuff from WebSphere perhaps this really just saying if smaller groups and less people want to mess with it, it should have some new thought around more consolidated abstractions.

Re: Google admits Kubernetes container tech is too complex

#70
As Docker provided a simplified model with sensible defaults and a decent toolset for packaging and virtualizing single-node app environments into containers; so people went out and looked for a solution to virtualize multi-app workloads.

Honestly, I'm not sure Kubernetes is it. K8s seems like a leaky implementation detail when what people want is just to virtualize a workload (with similar simplicity to Docker) and have it work wherever the standard 'workload virtualiser' runs.

Post reply on HN