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

321–330 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#321

Post by neonological »

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…

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 the complainers have been complaining so long that people get tired of it.

You now get people who are so tired of listening to people complain whose entire job entire job revolves around kubernetes that these people now start complaining about the complainers.

It happened with JavaScript. Javascript was around for so long people started complaining about the complainers. In fact it’s been around so long that a whole generation of people who’ve never used any other language was literally born. These people started off as the complainers against the complainers but now they outnumber the complainers so you rarely see people talk shit about JavaScript anymore.

Actually JavaScript has been around so long that the entire language has changed and part of the terribleness was fixed by making another language (typescript) compile into JavaScript.

Which brings me back to kubernetes. Kubernetes is a bad tool with no alternative precisely because it requires a 3 man dedicated team a year to get things up and running.

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.

I am a complainer and you are a complainer of complainers. What will likely happen some time from now is two possible things. Kube will be so integrated into the infrastructure ecosystem that wrappers will be written on top of kube just like how react and typescript have replaced JavaScript. If that doesn’t happen then a whole new tool will replace it.

I’m sorry to say but the ideal we are shooting for here is a tool that will ultimately make Devops a general thing that all developers can deal with rather then an entire specialist team. Again no such tool exists yet but it certainly can exist, especially when the inventor of the tool has become a complainer.

If the inventor of the tool becomes a complainer, that validates the complainers. And now the complainers of the complainers have nothing left to say.

Re: Google admits Kubernetes container tech is too complex

#322

Post by __jem »

cameronh90 wrote: post #279
cyphar wrote: post #242

Earlier quoted context omitted.

Linux containers and equivalent technologies are virtualisation (specifically OS virtualisation[1]), just not a VM. Hardware virtualisation (VMs) isn't the only kind of virtualisation that exists. [1]: https://en.wikipedia.org/wiki/Operating_system-level_virtual...

By that logic, processes are arguably virtualisation too. They do after all use virtual memory. Threads, processes and containers exist on a continuum.

The key is that "containers" don't actually exist -- they're just processes running under a variety of different namespaces.

Re: Google admits Kubernetes container tech is too complex

#323

Post by nirui »

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

Just want to know, will Google actually make Kubernetes a bit more friendlier for general non-GKE users?

Re: Google admits Kubernetes container tech is too complex

#324

Post by piaste »

AndyMcConachie wrote: post #196
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…

Containers solve the dependency problem by simply pretending it doesn't exist. I used to do UNIX integration work in the late 1990's early 2000's and containers weren't really a thing. So you had to make sure libs from one program didn't crap on another program. And developers had to be conscious of what dependencies they included in their code. Nowadays they don't have to care as much because of containers. Every pr…

I'm very interested in understanding what I'm doing and what I'm bundling into my software.

What I'm not interested in, is this kind of walking uphill in the snow both ways:

> So you had to make sure libs from one program didn't crap on another program. And developers had to be conscious of what dependencies they included in their code.

ie. having to understand what everybody else is doing in order for my software to run properly. No thanks. That's not why I'm here.

I'll put the exact dependencies I want, in the versions which work best for my software, into a Docker image or whatever tool offers a similar level of isolation, and I'll be working on my code while everybody else spends their time fighting over the ABI compatibility of C system libraries.

Re: Google admits Kubernetes container tech is too complex

#325

Post by tylermenezes »

As a small nonprofit with a tech team consisting of mostly volunteers, a few interns, and a small % of our paid staff time, this was a big concern for us.

Things are always fine when you're starting, but if you don't understand the system it's hard to troubleshoot when it breaks. Understanding Kubernetes is hard. Obviously there are ways to outsource cluster management, but we don't have the budget of a VC funded startup.

We ended up choosing Hashicorp's products -- Nomad for orchestration, Consul for service discovery, and Vault for secret management. Each one is just a binary with a <20 line config file, and it takes ~two days to read and understand the docs well enough that we have been able to troubleshoot issues quickly.

Re: Google admits Kubernetes container tech is too complex

#326

Post by jaywalk »

Guest42 wrote: post #268
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…

Yes, the number of proposed db switched I’ve seen is remarkably high. I once interviewed for a role as a database developer and was confused to find out they didn’t have the database that the role pertained to. One of the early questions in the interview was how quickly I could migrate production from ms sql to pg. Needless to say that was a gigantic red flag and I hope they found the right person for that job. I’ve…

I've got relatively modestly-specced SQL Servers handling tables with hundreds of millions and even billions of rows without breaking a sweat. Somebody either just really wanted a new toy to play with, or has no idea what indexes are.

Re: Google admits Kubernetes container tech is too complex

#327

Post by reader_1000 »

specialp wrote: post #278
Ianvdl wrote: post #259

Earlier quoted context omitted.

As someone with limited experience with containers, how does K8s allow you to move away from things like Puppet for configuration management? Does it offer some substitute that alleviates the need for something like Puppet or Ansible?

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…

> So the same thing run locally is run in the cloud

Who is preparing Dockerfiles? Developers and system administrators / security people do not generally prioritize same things. We do not use k8s for now (therefore I know very little about it), so this might not be relevant but how do you prevent shipping insecure containers?

Re: Google admits Kubernetes container tech is too complex

#328

Post by edude03 »

machiaweliczny wrote: post #158
endymi0n wrote: post #71

Earlier quoted context omitted.

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…

IMO fixing BEAM VM to easily work on cluster could be better for distributed systems than k8s.

The BEAM VM is fantastic but the scope of Kubernetes + docker is completely different.

For example you still need a way to get BEAM onto hosts, still need to manage the OS on the host, still need to setup networking, RBAC etc.

Re: Google admits Kubernetes container tech is too complex

#329

Post by edude03 »

iooi wrote: post #293
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 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

Re: Google admits Kubernetes container tech is too complex

#330

Post by otabdeveloper4 »

3131s wrote: post #296
otabdeveloper4 wrote: post #81

Earlier quoted context omitted.

Yes, because I saw that my (not-so-niche, actually) use case wasn't even considered, and "noped" outta there as fast as I could.

What was your use case?

Some ETL logic packaged in Docker containers with a bit of simple scheduling and orchestration.

K8s sounds like a good idea on paper - you get reproducibility and resilence "for free" - but then I found out I have to effectively roll my own everything with k8s anyways and went with Jenkins instead.

Post reply on HN