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

381–390 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#381

Post by AtlasBarfed »

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…

Performance is not the only reason to scale. Redundancy / failure tolerance.

Cassandra is a big PITA, but it hasn't gone down (knock on wood) in the 6 years I've been using it. PARTS of it have...

How many distinct services do you have in your monorepo? A monorepo is fine...

until it isn't.

Re: Google admits Kubernetes container tech is too complex

#382

Post by speedgoose »

rbanffy wrote: post #212
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…

> Horizonal scalability is simply a band-aid for poor engineering And don't even get me started on having instances labeled "large" that have less memory and CPU capacity than my personal backup laptop (currently on loan to my 8yo for COVID reasons)...

Don't forget the ridiculously low and restricted IOs unless you pay a lot.

But you can use other cloud providers with better value.

Re: Google admits Kubernetes container tech is too complex

#383

Post by dbradstock »

nirui wrote: post #323

So based on the article, Autopilot is designed for GKE??? ( https://cloud.google.com/blog/products/containers-kubernetes... ) I'm learning Kubernetes and is deploying my own test cluster on my ARM-based board at this very moment, and I already spend 3 days on K3s and have to give up due to a problem ( https://github.com/k3s-io/k3s/issues/2509#issuecomment-78657... ). I must say, this is way way harder than Docker Swa…

Disclosure: I am a Googler on GKE

Google actually works a huge amount with the community to simplify Kubernetes across a number of SIGs. Its always a trade of increased flexibility and options as people use it for more workloads, versus simplicity.

Autopilot is just for GKE. You can use GKE on other clouds and also onprem (bare metal or VMs with Anthos)

Re: Google admits Kubernetes container tech is too complex

#384

Post by a1369209993 »

throwaway894345 wrote: post #348
vp8989 wrote: post #250

Earlier quoted context omitted.

"I have some colleagues that are delaying our rollout unintentionally so they can play around with developing more tooling for deployments which is really frustrating." My impression is that the primary purpose of Kubernetes is to give SRE teams political air cover to rewrite a lot of their existing processes. Whether Kubernetes is actually required for that, or even net superior seems questionable. This unsexy work…

> So what happens is people convince themselves that the existing tech sucks and use that to rationalize doing the rewrite. That certainly is a thing that happens, but you could use that to dismiss any technology at all. In the case of Kubernetes, it makes operations a lot easier to the (important) effect that the development teams can do a lot of their own operations work. This is important since they're the ones wh…

> but you could use that to dismiss any technology at all

No, you can't; you need three (-ish) factors:

1. The technology is sufficiently incompatible with what you're currently using that you need a rewrite to use it (eg, this generally doesn't happen with gcc -> llvm, for example).

2. The technology is sufficiently (faux-)popular that it's possible to convince a pointy-haired boss that you need to switch to it (eg, this won't work with COBOL anymore, though unfortunately it successor Java is still going).

3. The technology sucks.

And really, if you want to dismiss a technology, point 3 ought to be enough all on its own (particularly since that's presumably the reason you want to dismiss that technology).

Re: Google admits Kubernetes container tech is too complex

#385

Post by neonological »

dntrkv wrote: post #366
neonological wrote: post #321

Earlier quoted context omitted.

I’m tired of the complainers of the complainers. First a technology seems cool, then after engineers become experienced with the tool the warts rear itself and you get a vocal group of complainers. It doesn’t end there... after complaining for a really long time two things happen. First off so much time has passed that you get these domain experts (Devops people) whose entire job is to mess with kubernetes. Second th…

> A good tool would be something like allows me to to get it up and running in a week just by reading some docs. Even better an hour. Could such a tool exist and replace Kubernetes? Yes. Does such a tool exist? No. Instead of complaining, why don't you build this tool? That's the problem I have with complainers.

You're complaining about me complaining.

Instead of complaining why don't you build me the tool to stop me from complaining? It's the same reason why I'm not building the tool.

That's the problem I have with complainers complaining about other complainers. Why don't you guys do something about my complaining rather then complain about it?

Re: Google admits Kubernetes container tech is too complex

#386

Post by anchochilis »

stickfigure wrote: post #351
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.

Oh man, I can't believe we didn't think of migrating our mature 20-service stack with complex hardware, security, and compliance requirements to App Engine. Dang it. I should've known to consult HN first!

Re: Google admits Kubernetes container tech is too complex

#387

Post by mbushey »

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.

I agree that ArgoCD is amazing. What's so beautiful is how well it integrates into K8s. Every element of ArgoCD is a CRD (custom resource definition). It's less of a piece of software (other than the interface) and more of an extension to K8s to provide Continuous Delivery. Saying ArgoCD does not require K8s is like saying you don't need Photoshop to run a Photoshop plugin.

I've used Puppet, Chef, and Ansible in production over the last decade. For me, Ansible replaced Puppet and Chef five or six years ago. For the last two years the only thing I have used Ansible for is to manage desktops and Android boxes AT HOME. Configuration Management systems like Ansible are fun and cool, but have been mostly obsoleted by the combo of Terraform and K8s. If you're on AWS, Kops can replace a lot of what Terraform does.

Kubernetes makes running services easier and more reliable. I've spent more time learning Istio that K8s itself. The learning curve of K8s is minimal compared to Drupal.

Re: Google admits Kubernetes container tech is too complex

#388

Post by cies »

bavell wrote: post #255
FridgeSeal wrote: post #207

Earlier quoted context omitted.

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 wha…

Agreed. I'm a solo technical founder and have been using k8s for all my hosting for 3+ years. It's so easy (for me) that I'm fine paying a premium for the managed service (GCP) since it saves me lots of time, my most valuable resource. I've already climbed most of the learning curve so YMMV, but as a team of one and dozens of WordPress, MySQL, and bespoke app servers, kuberenetes makes ops manageable so I can spend t…

Curious: do you have a single workload (like a WP site) that requires more than one physical computer in resources?

I think that's the first thing with k8s: it all starts with an app that requires several physical nodes.

Re: Google admits Kubernetes container tech is too complex

#389

Post by bebop »

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…

What I think K8S (EKS, GKE, DO hosted environments at least) provide is a nice way to integrate things like Gitlab. This gives you a really easy to use CI/CD pipeline for very little work and configuration. This allows you to deploy production from your main branch and spin up feature branches that can be tested by the people that requested the feature very easily. This does not require an additional effort once the system is setup.

Also you can get red/green deployments and rolling deployments with little to no effort, which can be very nice, nice to have.

Re: Google admits Kubernetes container tech is too complex

#390

Post by mbushey »

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.

I previously managed my companies Kubernetes clusters using Kops on AWS. My company switched to Google, so I had to move everything to GKE. I miss Kops, it gave me more control and made life easier. I don't want to use the old crappy deprecated DNS server, but with GKE that's what you get. I don't get to control what goes on the masters on my clusters because they're not mine anymore. Having GKE do the masters means more headaches and complexity because I no longer have control. I love K8s, but GKE does a pretty poor job implementing it. It boggles my mind that the main company behind K8s is so incompetent in implementing it.
Post reply on HN