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

291–300 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#291

Post by nnadams »

_untra_ wrote: post #46

Not seeing anyone mention it, so I'll just share: https://k8slens.dev/ Lens has been a huge boon for helping us manage our kube cluster and regular devops operations, and even 15 minutes with it helped me grok a number of complex kubernetes concepts that I've struggled with for awhile now. Everyone who works with k8s for a living should at least know of this tool imho its fantastic with prometheus

Using a client like that helped me get up to speed as well. If anyone wants a terminal based k8s client, I like https://github.com/derailed/k9s

Re: Google admits Kubernetes container tech is too complex

#292

Post by Spivak »

JeremyNT wrote: post #220
MaxBarraclough wrote: post #215

Earlier quoted context omitted.

> 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). At the risk of nitpicking, docker images aren't the equivalent of VM images, as they don't include a kernel.

This isn't nitpicking at all, it's an important distinction! Docker is not virtualization, it's just an abstraction that makes some Linux process isolation features easier to manage. It also allows you to bundle whatever dependencies you have in the same bundle, but that is not the same as having a VM.

OCI “docker” containers are at this point are a description of a process. How it’s realized is up to the implementor. runc realizes the container with kernel namespaceing and runv realizes the container with hardware virtualization.

Both if implemented to spec will be logically equivalent and drop-in replacements for one another.

Re: Google admits Kubernetes container tech is too complex

#293

Post by iooi »

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.

Re: Google admits Kubernetes container tech is too complex

#294

Post by Ianvdl »

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…

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 process? Does that mean you just deploy a new version/container of an application linked to the same underlying database (for example) when you need to run an upgrade?

So if you had a fleet of ten containers running the same application in a load balanced config, I'm guessing you'd need to upgrade all of them at once (with downtime) rather than upgrading them one by one (because then the database would be inconsistent)? I'm assuming that since the containers are immutable the data is stored elsewhere.

Re: Google admits Kubernetes container tech is too complex

#295

Post by slt2021 »

yonixw wrote: post #194
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 in most (not all) applications. Maybe if your app handles < 10k concurrent connections. Otherwise it is the most cost efficient solution and exists because it solves the scaling problem in the best way as of today.

agree with you, when you say cost efficient it means - that we can scale out our poorly written slow software to more servers to handle increased traffic, instead of hiring more expensive engineers and rewriting software properly than could handle increased load from a single instance

Re: Google admits Kubernetes container tech is too complex

#296

Post by 3131s »

otabdeveloper4 wrote: post #81
ec109685 wrote: post #24

Earlier quoted context omitted.

You only played with it an hour and you reached all these conclusions?

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?

Re: Google admits Kubernetes container tech is too complex

#297

Post by pgm8705 »

aroman wrote: post #28
colesantiago wrote: post #10

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.

Mind blowing to me that "Heroku but with docker images" doesn't seem to exist. Would love to be corrected!

Digital Ocean's App Platform can work this way.

Re: Google admits Kubernetes container tech is too complex

#298

Post by jiveturkey »

vp8989 wrote: post #250
z9e wrote: post #233

Earlier quoted context omitted.

... Until they hire you back because entropy exists :P I'm on the DevOps side as well going through the same transition, k8s also allows insane customization, and 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. The k8s scene seems to be filled with constant scope creep and refactoring to get it just…

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

> you are also eating the operational cost of integrating a new technology into the org.

and in short order you will reap the savings of being able to hire people who already know your devops/infra tech stack, and can hit the ground running. not to mention being able to benefit from the constant improvements that come from outside your org.

Re: Google admits Kubernetes container tech is too complex

#299

Post by vp8989 »

jiveturkey wrote: post #298
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…

> you are also eating the operational cost of integrating a new technology into the org. and in short order you will reap the savings of being able to hire people who already know your devops/infra tech stack, and can hit the ground running. not to mention being able to benefit from the constant improvements that come from outside your org.

Maybe. I don't buy that just because people are on Kubernetes they won't still kludge it up with custom in-house scripts or "extensions". Give it time.

Re: Google admits Kubernetes container tech is too complex

#300

Post by quadrifoliate »

ryandrake wrote: post #43
colesantiago wrote: post #10

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.

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 boundaries, RTOSes, compiler chains, musl, JTAG, and a million other things that make my mind numb. But I assume embedded engineers need to know all those things, because of the constraints unique to their field. Some of them could be just "a complex way for engineers to keep themselves spinning their wheels and not actually working on an application", but a lot of them provide value in the real world and solve some specific problem.

Cloud infrastructure management frameworks are the same.

Post reply on HN