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

281–290 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#281

Post by eloff »

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 also seen a switch from rdbms to Hadoop because a company had “millions” of rows. Luckily on this one I only had to rewrite a handful of queries.

Wat. That's gross. It probably costs them more per query now than the rdbms did.

Re: Google admits Kubernetes container tech is too complex

#282

Post by skinnyarms »

yowlingcat wrote: post #266
vp8989 wrote: post #247

Earlier quoted context omitted.

"Kubernetes is the biggest quality-of-life improvement I've experienced in my career." Can you elaborate? What exactly about Kubernetes improved the developers life?

Can only speak for myself personally, but having gone through a similar moment, it was 50% docker QoL improvements and 50% k8s QoL improvements -- most significantly around prod/dev parity. Every engineer in my org really did gain a significant amount of confidence around being able to spin up and deploy new services (when necessary) without being nervous about something going wrong in prod that wasn't configured pro…

I'm really happy with the local development story too. We use skaffold to pick and choose which resources we run locally, and then we use the same definition to generate our artifacts which keeps things in line.

It reminds me of docker-compose file, except I can publish it too.

Re: Google admits Kubernetes container tech is too complex

#283

Post by Spivak »

anchochilis wrote: post #280
vp8989 wrote: post #247

Earlier quoted context omitted.

"Kubernetes is the biggest quality-of-life improvement I've experienced in my career." Can you elaborate? What exactly about Kubernetes improved the developers life?

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.

Re: Google admits Kubernetes container tech is too complex

#284

Post by Spivak »

zdw wrote: post #271
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?

You still need something to provision the base OS and all the stuff under K8s (docker daemon, ntp, storage, networking, etc.) that it relies on, unless you go with a fully hosted solution. Ansible or Puppet still excel at that kind of work.

And it looks like the parent went with a hosted solution which explains everything. Having to manage all the underlying services that k8s glues together is a huge PITA.

Re: Google admits Kubernetes container tech is too complex

#285

Post by anchochilis »

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.

Updated original comment to clarify :)

Although, to be fair, the article is about GKE.

Re: Google admits Kubernetes container tech is too complex

#286

Post by TeeWEE »

I really went deep into k8s. But as an engineer building services and features. I mostly dont care about the lower level platform. I just want to deploy code and services. The whole sysops / devops part should "just work".

I really like "Google Cloud Run" in this sense. Just deploy your Dockerfile.. And you're done.

A single yaml file. Limited configuration. Scaling just works. No cluster management.

I just want to build a great product.

Re: Google admits Kubernetes container tech is too complex

#287

Post by [deleted] »

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…

[deleted]

Re: Google admits Kubernetes container tech is too complex

#288

Post by Spivak »

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

But that doesn’t make any sense. We’re not talking about physical hardware we’re talking about tiny tiny slices of it. When VMs are the logical isolation boundary in your infra they get really small — 512 MB is a lot of memory for a single purpose server.

Re: Google admits Kubernetes container tech is too complex

#289

Post by isbvhodnvemrwvn »

2sk21 wrote: post #252
dilyevsky wrote: post #90

Earlier quoted context omitted.

Long time ago I worked on HA setups for telecom (Wimax/LTE) equipment. Kubernetes is complicated but has nothing on those systems. Just to give you some idea - https://www.metaswitch.com/hs-fs/hubfs/Blogs/3gpp-ts-23-228-... (doesn’t even cover everything)

The very term "HA" still gives me nightmares. It can be very hard to get HA to work correctly. Many years ago, I worked in a startup and one of our main offerings was an HA network device. It was unbelievably finicky to get it to work in the first place and even harder to update the software on an HA cluster.

It's HA by intimidation. The cluster is complex enough that nobody even wants to touch it, and since human errors are the most common type of error out there, it breaks much less often.

Re: Google admits Kubernetes container tech is too complex

#290

Post by otabdeveloper4 »

fctorial wrote: post #214
fendy3002 wrote: post #205

Earlier quoted context omitted.

I suppose your apps ran on windows. It isn't a problem (or at least it's a smaller problem) with windows ecosystem, especially enterprise one, since usually you're using same version and installation steps handled by infra with AD. Even without AD usually the installer and windows version is same, and Microsoft usually great at backwards compatibility. But it's not the case in linux, or at least non-enterprise / ldap…

Nixos fixes this issue (and then some). I wish it had won instead of docker. Maybe it took too long to become stable.

Nix and Docker are complementary, not enemies.

We use both together, since Nix is the only sane way to package Docker images, in my opinion.

Post reply on HN