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

351–360 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#351

Post by stickfigure »

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

Just wait until the developers discover Google App Engine, Heroku, or DigitalOcean App Platform.

Re: Google admits Kubernetes container tech is too complex

#352

Post by sschueller »

edude03 wrote: post #329
iooi wrote: post #293

Earlier quoted context omitted.

> - I can run a root Pod? Lets mount the docker socket and start building images with it. Just in case you haven't figured out the proper way to do this, you should use docker:dind.

kaniko is an even better way

If it didn't have wierd issues when you start stacking in docker file.

Re: Google admits Kubernetes container tech is too complex

#353

Post by dbradstock »

konjin wrote: post #145
collyw wrote: post #127

Earlier quoted context omitted.

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

Reality is too negative for social media.

El Reg's snark is what makes it fun to speak with as they do cut to the heart of it.

GKE Autopilot is still fundamentally Kubernetes and supports the k8s APIs. GKE has simplified a lot of Kubernetes tasks that can be a pain, such as upgrades & scaling, but as many people said on other threads Kubernetes definitely is not for all workloads. For workloads that actually do need to scale then Autopilot removes a lot of the time consuming tasks required to get Kubernetes running and staying running. There are restrictions so check the docs on if it would work for how you use k8s.

Disclosure: I run product for GKE at Google so I'm definitely not a neutral voice on this...

Re: Google admits Kubernetes container tech is too complex

#354

Post by betaby »

dmingod666 wrote: post #206
ant6n wrote: post #193

Earlier quoted context omitted.

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

Netflix in fact 'run on servers' https://papers.freebsd.org/2019/fosdem/looney-netflix_and_fr...

Re: Google admits Kubernetes container tech is too complex

#357

Post by lame88 »

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…

How much of this is specific to Kubernetes and how much is more accurately because you moved from managing your own VM infrastructure to using managed services? Cloud providers have (often long had) ways of saying "run this code" without managing a VM and without involving kubernetes, including with docker support. And they are often very easy to use though not without their faults. An example being Azure app service.

I do agree that kubernetes is a pleasant experience from an application developer perspective with an existing cluster, but in my experience it was not without excessive pain and long hours by those administering the cluster. A year doesn't surprise me in your case, which brings to mind this question.

Re: Google admits Kubernetes container tech is too complex

#358

Post by sontek »

vp8989 wrote: post #305
anchochilis wrote: post #280

Earlier quoted context omitted.

1. Reliable rolling deployments. We didn't have these before. Yes, you can implement them without K8s (I have, at other companies) but to get the full set of features K8s provides, such as deploying N services in parallel, taking no more than X% of your capacity offline at a time, short-circuiting in the event the app is dead on arrival, connection draining with timeouts, you end up with a VERY complicated multi-thre…

Yeh this list is not surprising and none of these things you mentioned exclusively require Kubernetes or running containers in Prod. Like I mentioned in another comment, it feels like the purpose of Kubernetes is that it's "brand" provides political cover to introduce these practices to the engineering org.

None of it requires kubernetes, kubernetes just does it out of the box better than any hand-rolled custom stack that tried to do the same. Its a true joy to work with compared to the cobbled together stuff I've built and/or used in the past.

Re: Google admits Kubernetes container tech is too complex

#359

Post by dbradstock »

yongjik wrote: post #14
ohmywhat wrote: post #6

Sadly, this is a typical Register headline. Google did not say "Kubernetes is too complex" but rather, they are making this new tool - called Autopilot - that is an abstraction layer on top of Kubernetes for certain types of applications / companies. This Autopilot system still uses Kubernetes AFAICT.

I almost replied "who would look at Kubernetes and think it needs more layers?" but it sounds like Autopilot is a new cloud service - the customer (hopefully) doesn't interact with the underlying Kubernetes layer. I guess it kinda makes sense.

View from a Googler: Autopilot stitches together existing GKE functions and is just a cluster creation decision. The layer it adds is automating the different tools together and SRE support magic so that we're monitoring it now.

Re: Google admits Kubernetes container tech is too complex

#360

Post by sontek »

Spivak wrote: post #283
anchochilis wrote: post #280

Earlier quoted context omitted.

1. Reliable rolling deployments. We didn't have these before. Yes, you can implement them without K8s (I have, at other companies) but to get the full set of features K8s provides, such as deploying N services in parallel, taking no more than X% of your capacity offline at a time, short-circuiting in the event the app is dead on arrival, connection draining with timeouts, you end up with a VERY complicated multi-thre…

You’re using hosted k8s! That explains everything! I was so confused how a devops person wasn’t cursing the name. Implementing and managing k8s is where all the complexity and headache lives.

Have you seen kops? rancher? loft? I don't think its that terrible to manage k8s at all using the tools available to you. k8s definitely used to be be difficult to manage but that isn't the case anymore.

But literally every cloud provider out there has a managed solution so at this point you really only need to do it for DC work or if you like to do it.

Amazon - EKS Google - GKE Azure - AKS

anything beyond those 3 is a rounding error but...

Linode - LKE DigitalOcean - DigitalOcean Kubernetes IBM Cloud Kubernetes Service Rackspace - KAAS

Post reply on HN