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

391–400 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#391

Post by throwaway894345 »

a1369209993 wrote: post #384
throwaway894345 wrote: post #348

Earlier quoted context omitted.

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

I think in your eagerness to 'gotcha' me, you missed my point. :)

Anyway, we're trying to assess Kubernetes' value proposition (i.e., to answer "does it suck?"). If your system for answering that question depends on already knowing the answer, it's not a very useful system.

Re: Google admits Kubernetes container tech is too complex

#392

Post by lallysingh »

soenkeliebau wrote: post #195
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 think Kubernetes in principle gets a lot of things very right - but it has over time grown into this huge amorphous blob of complexity that makes it very easy to shoot yourself in the foot with, as many people said :) That issue is not endemic to Kubernetes, but rather to any larger system past a certain age, you learn stuff as you go along and would do stuff differently if you did it again today - but you can't ea…

The industry and the k8s project are still figuring out the right way to do things that don't require the organization, size, and technical choices Google made.

Re: Google admits Kubernetes container tech is too complex

#393

Post by mbushey »

Ianvdl wrote: post #294
specialp wrote: post #278

Earlier quoted context omitted.

Yes because whatever you used for app specific configuration like libraries and packages is now done in the Dockerfile and containerized. So the same thing run locally is run in the cloud. Then as far as the infrastructure for running code such as load balancers, service discovery, docker.. That is all given to you just by running K8s. So you are more concerned with shipping immutable containers to k8s than provision…

Thanks for the detailed response. It looks like I've still got a lot to learn - I've just lately been playing with LXC to get more familiarised with containers. I've previously looked at Helm apps and they seemed to be very similar to Puppet manifests. From what you said it seems like the approach is to have immutable containers for each application, set up via Dockerfiles, which somehow also simplifies the upgrade p…

Helm is so bad it raises my blood pressure just hearing the name. Helm tries to apply the old way of doing things (like as you said Puppet) and makes it worse than ever. K8s yaml config is simple and elegant, don't try hiding it under templates. Kustomize is the proper way of working with K8s yaml. Helm fights against it.

Re: Google admits Kubernetes container tech is too complex

#394

Post by a1369209993 »

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.

If something as essential as the infrastructure is so complex that you need a dedicated expert on it, it's bad infrastructure. To take a offhand analogy, you don't need a dedicated highway maintainance engineer in order to drive your car.

Re: Google admits Kubernetes container tech is too complex

#395

Post by ryandrake »

quadrifoliate wrote: post #300
ryandrake wrote: post #43

Earlier quoted context omitted.

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…

> And that they're just a complex way for engineers to keep themselves spinning their wheels and not actually working on an application...How did the world get into this situation where you need all this complexity Isn't this just labeling the knowledge that you don't have (and could probably read up on) as potentially unnecessary complexity? I mean, every time I hear about embedded, I keep hearing about byte boundar…

Fair enough--we perceive things we're ignorant about as complex. I buy that.

I guess I was comparing it to how things were (or more precisely, how I perceived things) 20 years ago. You'd rack a server or two, install Linux, stick the application in /usr/local/bin, make sure Apache was set up, and you were off and running. Simple enough. It probably didn't scale to 2020-sized Internet user counts, though.

Re: Google admits Kubernetes container tech is too complex

#396

Post by farisjarrah »

mbushey wrote: post #390
Spivak wrote: post #283

Earlier quoted context omitted.

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…

Its a bit of a pain, but you can definitely switch to CoreDNS on GKE if you need to. Also as someone who has used GKE, EKS, MicroK8s, and Minikube, I would say that the easiest to use implementation of Kubenetes as a Service is GKE. Not saying its easy or the worlds most thought out product, but I gotta give google just a tiny bit of credit for at least being easier to use then the competition.

Re: Google admits Kubernetes container tech is too complex

#397

Post by Spivak »

sontek wrote: post #360
Spivak wrote: post #283

Earlier quoted context omitted.

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…

I've used Rancher and while it is very nice it still punts a lot of the hard bits like interacting with the outside network, vm creation, and storage (especially shared persistent storage) to the ops team to figure out.

Creating a big-ole cluster of app servers was never really the hard ops problem which is what k8s does really well.

Re: Google admits Kubernetes container tech is too complex

#398

Post by anchochilis »

mbushey wrote: post #393
Ianvdl wrote: post #294

Earlier quoted context omitted.

Thanks for the detailed response. It looks like I've still got a lot to learn - I've just lately been playing with LXC to get more familiarised with containers. I've previously looked at Helm apps and they seemed to be very similar to Puppet manifests. From what you said it seems like the approach is to have immutable containers for each application, set up via Dockerfiles, which somehow also simplifies the upgrade p…

Helm is so bad it raises my blood pressure just hearing the name. Helm tries to apply the old way of doing things (like as you said Puppet) and makes it worse than ever. K8s yaml config is simple and elegant, don't try hiding it under templates. Kustomize is the proper way of working with K8s yaml. Helm fights against it.

Helm isn't great (god, Go templates, shudder), but I love being able to bundle all the manifests for an application together with well-documented parameters/values... If you want do something like conditionally switch from a LoadBalancer service to Ingress in a test environment... I have no idea how you'd handle that in Kustomize, but it's straightforward in Helm. Ultimately it seems like you end up with the same complexity, just expressed via 100 layers of Kustomize transforms instead of with a conditional in your template.

Re: Google admits Kubernetes container tech is too complex

#399

Post by wdenniss »

unixhero wrote: post #216

Removing ssh is stupid They should remove the need for CONFIGURING ssh. Now they have removed the entire control plane of the container. Hiw should a developer debug something then?

Hey, I work on this project -- thanks for your feedback.

You can still shell into your own containers to debug workloads, we removed SSH access to the nodes in order to provide management of the nodes (we can't take on the management if people can SSH in and make unsupported changes).

Re: Google admits Kubernetes container tech is too complex

#400

Post by rigrassm »

orthoxerox wrote: post #270
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…

In my opinion, k8s starts to shine when you have to manage hundreds of containers. When you have just dozens of them it's an overkill, but there's no way to smoothly slot in another solution between "docker-compose up -d" and spinning up a k8s cluster: you will (or think you will) hit a maintainability ceiling again and have to migrate to k8s.

There actually is, Hashicorp Nomad fits solidly in between those two options.

Nomad is way simpler to get a cluster up and running, has a great configuration syntax (I'll take HCL over YAML anyday) and had first class Terraform/Consul/Vault integrations.

Onboarding devs is fairly straightforward, if they can write a docker-compose.yml, it's an easy transition to a nomad job specification.

It took me by myself ~4 months to get our current hashistack(Vault/Consul/Nomad) stood up using Terraform+ansible. Two members of my team have been working to replace the hashistack with a self hosted K8's deployment and they just went over the 1 year mark and we still do not have something capable of hosting the workload currently running on the Hashistack.

This got a little long winded but I feel like this "it's docker compose or K8's, take your pick" mentality had led to a bunch of needless time being spent by smaller teams/companies on solutions that just aren't right for them.

Post reply on HN