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

131–140 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#131

Post by ForHackernews »

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?

What makes you think Kubernetes "secrets" are appropriate for storing secret information? They're not secure (not without adding a bunch of other nonsense on top of them).

Re: Google admits Kubernetes container tech is too complex

#132

Post by vmception »

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…

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

You are absolutely spot on because this is how not to pass the behavioral interview for Engineering Manager.

Re: Google admits Kubernetes container tech is too complex

#133

Post by collyw »

ogre_codes wrote: post #5

I think the single biggest mistake people make with Kubernetes is implementing it too soon. Last company I worked for spent piles of time fighting K8s when a simple well implemented cluster would have done the job. It makes a lot of sense to build portable infrastructure, but you can scale a long ways with much simpler technologies.

My place has Kubernetes for when we are ready to scale. I am not sure it has gone above the default two pods. It did cause problems with moderately large uploads (5gb), as the memory gets chewed up far faster when using multiple small machines versus one big machine. I am not sure we will ever actually need this level of scaling.

Re: Google admits Kubernetes container tech is too complex

#134

Post by Cthulhu_ »

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.

Definitely; if you as a company want to do Kubernetes or even cloud services (beyond the easy managed service like Beanstalk or GCE), you need to have a dedicated expert on it. Or more abstractly, one full time unit (can be distributed). If it's some guy's part time hobby it will not work.

Re: Google admits Kubernetes container tech is too complex

#135

Post by doteka »

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 not just limited to tech - what you are describing is essentially the Gartner hype cycle.

Re: Google admits Kubernetes container tech is too complex

#136

Post by bouk »

runeks wrote: post #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 (ou…

You should try out Terraform—combined with managed instance groups it basically makes GCP into one big Kubernetes instance without having to manage it yourself.

Re: Google admits Kubernetes container tech is too complex

#137

Post by collyw »

HenryKissinger wrote: post #15
trestenhortz wrote: post #12

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

Can you explain the whole concept of Kubernetes to someone whose knowledge of computers is limited to making simple webpages with HTML and using Excel/VBA?

I might start using that when people suggest adding new tech. If they can't explain it at that level, then it's going to be a difficult sell.

Re: Google admits Kubernetes container tech is too complex

#138

Post by justsomeuser »

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.

I’m leaning towards using Ubuntu/systemd to start all my services, and using a single container per project with SQLite.

This way:

- I can easily move from dev to prod by using the private container registry

- I have apt-get on the server and just use the default Ubuntu

- No distributed/network state

I used to use Core OS, but all these container OSes are here today and gone tomorrow, and normally have their own config standard. At least with Ubuntu they have LTS and a bunch of Google pages for fixing stuff.

Re: Google admits Kubernetes container tech is too complex

#139

Post by yyx »

TobTobXX wrote: post #57
arcturus17 wrote: post #49

Earlier quoted context omitted.

Maybe your starting instances are workhorses, but if you go from something like a t3.medium to two it’s a ~$60 / mth increase... Not something I’d personally optimize for. Also why Docker in the first place? I’m genuinely wondering - in the stacks I run (Express / Python) it doesn’t seem necessary at low scale. Elastic Beanstalk, Heroku, Digital Ocean etc all offer facilities for single-command deploys that work out…

I like Docker for the 'keeping it clean' aspect. Install php, composer and stuff juat because one of the projects you host requires it? Nope. Have to make excessive configuration on a system component just to run another application? Nope. Forgot how you set it up and now you are struggeling at the new machine? Use the Dockerfile.

vagrant and ansible can help.

Re: Google admits Kubernetes container tech is too complex

#140

Post by latch »

syrusakbary wrote: post #21

Kubernetes adds a vast amount of complexity, and in my rationale is because it centers scaling on the wrong unit (the Operating System). Docker introduced a great level of abstraction and reproducibility over platforms. However, Docker (or OS-based containers) are the most atomic unit of computation on Kubernetes. Which causes centering scaling on the Instance, instead of the Application or even the functions. This l…

To me, this essentially defines "the cloud" which exist because they've convinced CTOs that scaling is an infrastructure concern.

The scaling of their primary business (amazon.com, google.com) is at least partially an infrastructure problem - so they had to solve this anyways. Why not try to sell it too?

But it's very rare that you can scale a system by only scaling infrastructure. Ironically, probably the only way this will work is if you scale vertically - which means you don't need K8 and want to avoid the cloud like the plague.

There are all types of application-specific consistency issues that need to be treated as first class parts of the system for horizontal scaling to work.

Post reply on HN