Live data from Hacker News

Google admits Kubernetes container tech is too complex

theregister.com

71–80 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#71
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 fully agree with your points and would sum them up as "Kubernetes has a steep learning curve, a (quite) large interface and ample opportunities to shoot yourself into the foot with it" (plus, they're very funny).

However playing the devil's advocate here: If you actually took the steps of learning the basic abstractions, then for me it's really hard to see what you could still get rid of.

If you actually go all-in and fit your application to the principles of Kubernetes-native applications (instead of the other way around), then it works nothing short to amazing.

We're running 120 microservices in GKE and the difference to our custom-built setup before is night and day. I let my Infra team go surfing together for two weeks because without changes it flies mostly on autopilot.

Let's not kid ourselves, distributed computing is _hard_ and Kubernetes is a testament to that. I'm not saying it can't be made more accessible by further standardization, but there are fundamental limits to how easy it can be made.

Which by the way is leading to my only pet peeve with it: I feel most of the complexity of K8S comes from the fact that it got hyped as an enterprise product and then lots of features were built that support shoving your non cloud-native workload into Kubernetes even if it was never designed for it.

If you don't do or need all of that, the amount of interface, complexity and footguns shrinks significantly. Maybe it's time to better pull them apart in the documentation.

Re: Google admits Kubernetes container tech is too complex

#72

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.

Looking at the istio-linkerd-traefik-consul-whatever-the-heck mess of cloud-native ecosystem projects, I want to decree that backend engineers are no longer allowed to make fun of Javascript engineers for having too many frameworks anymore.

Re: Google admits Kubernetes container tech is too complex

#73

Earlier quoted context omitted.

That's pretty much Cloud Run, no? https://cloud.google.com/run/

Cloud run is great. I'm using an Nginx image to serve my static website. However, if I remember correctly, you can only respond to HTTP(S). So though it may be enough for most usecases, it is not essentially equal to running any container on the cloud.

gRPC and WebSockets are in preview. Doesn't look like you can use arbitrary ports though.

https://cloud.google.com/run/docs/triggering/grpc

Re: Google admits Kubernetes container tech is too complex

#74

Earlier quoted context omitted.

I'm looking for something like that, but I'm afraid of using any google developer services, such as GCP, for personal projects. What if I breach their TOS somehow and get banned, or what if I didn't breach their TOS and still get banned? Can't afford to test my luck until I've finished migrating all my accounts off my gmail.

Why don't you just create a new Google Account specifically for this?

Associated account bans are a thing in the Android world. I don't know if this extends to other Google platforms.

Re: Google admits Kubernetes container tech is too complex

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

Docker Swarm mode is alive and well and not going anywhere. It's right there, built into the regular Docker CLI.

Re: Google admits Kubernetes container tech is too complex

#76

Earlier quoted context omitted.

That's pretty much Cloud Run, no? https://cloud.google.com/run/

I'm looking for something like that, but I'm afraid of using any google developer services, such as GCP, for personal projects. What if I breach their TOS somehow and get banned, or what if I didn't breach their TOS and still get banned? Can't afford to test my luck until I've finished migrating all my accounts off my gmail.

I'm using my main google account on GCP and just yesterday started to take precautions about this.

I created a new google account with no relation to my main one and added it as an owner to my GCP project, so hopefully in the event of either account being banned I can still access everything.

Re: Google admits Kubernetes container tech is too complex

#77

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.

Yes, k8s is not built for solo outfits and small projects.

In places with 10+ developers and 10+ services on a single cluster it works surprisingly well from the user (developer) side.

Re: Google admits Kubernetes container tech is too complex

#78
post #65

Earlier quoted context omitted.

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

Did you try this?

  networks:
    - host
https://docs.docker.com/network/host/

Re: Google admits Kubernetes container tech is too complex

#79

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…

Docker Swarm is pretty much abandonware/on life support at best, so one should avoid using it for new stuff.

Hashicorp's Nomad is the best choice on the complexity for features scale IMHO, and that's why i'm writing an article how great it is, how easier some things are and what's missing compared to Kubernetes.

Re: Google admits Kubernetes container tech is too complex

#80

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.
Post reply on HN