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

311–320 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#311

Post by anchochilis »

vp8989 wrote: post #305
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…

Yeh this list is not surprising and none of these things you mentioned exclusively require Kubernetes or running containers in Prod. Like I mentioned in another comment, it feels like the purpose of Kubernetes is that it's "brand" provides political cover to introduce these practices to the engineering org.

I don't know what to tell you except that with years of experience implementing this infrastructure outside Kubernetes, letting Kubernetes handle it is cheaper. That doesn't mean Kubernetes is a good fit for every organization or workload.

You can roll your own anything with enough time and manpower. Whether it makes sense to do so depends on your circumstances.

Re: Google admits Kubernetes container tech is too complex

#312

Post by seanc »

cmrdporcupine wrote: post #232

I'm scared. From 2000 til 2013 I did exclusively server side development. In 2013 I transferred (@ Google) into doing mobile and embedded work, and missed the whole docker thing & the K8 transition. I've now transferred back over to doing cloud/server/backend work and I'm just a little terrified of what I've gotten myself into. In addition to re-learning Google's Borg stack, learning Golang, and readjusting my headsp…

Those 13 years of doing things the old way will come in really handy when the abstraction leaks and you're the one who actually knows how to troubleshoot firewalld

Re: Google admits Kubernetes container tech is too complex

#313

Post by pyrophane »

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 no longer need to use Terraform to scale out a service.

Are you still using Terraform to specify your deployments? From experience, you need something there to manage all your yamls: deployments, configmaps, secrets. Especially if you have multiple environments.

Re: Google admits Kubernetes container tech is too complex

#314

Post by anthonyskipper »

vp8989 wrote: post #305
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…

Yeh this list is not surprising and none of these things you mentioned exclusively require Kubernetes or running containers in Prod. Like I mentioned in another comment, it feels like the purpose of Kubernetes is that it's "brand" provides political cover to introduce these practices to the engineering org.

It is not a brand, it's when all the capabilities come together in a single package with one general way to do things that you get the benefits. You could do all this stuff with IaaS but there were too many ways and not enough lines in the sand between dev and ops in the IaaS world. IaaS should be considered a legacy approach.

Re: Google admits Kubernetes container tech is too complex

#315

Post by iandanforth »

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…

wrt horizontal scaling. Do recall that the motivation for this strategy by Google was cheap-as-possible servers that failed constantly. Back when they built racks using legos the problem was hardware reliability. They had to 'scale' horizontally for reliability (given cost constraints) as much as load.

People have since bought into the marketing reasons for 'being in the cloud' and having 'infinite scalability' but that largely misses the point (and the pain) that caused many of these technologies and patterns to be developed in the first place.

The best example of how to scale without buying into this pattern I know of is Stack Overflow. At least circa 2016 - https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

Re: Google admits Kubernetes container tech is too complex

#316

Post by michaelcampbell »

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…

> Something about it never fully stuck with me. ... Plopping an entire VM...

There's your first miss.

Re: Google admits Kubernetes container tech is too complex

#317

Post by yellow_lead »

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 guess millions sounded like a lot to a decision maker :)

Re: Google admits Kubernetes container tech is too complex

#319

Post by [deleted] »

justsomeuser wrote: post #138
trinovantes wrote: post #36

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’m leaning towards using Ubuntu/systemd to start all my services, and using a single container per project with SQLite. This way: - I can easily move from dev to prod by using the private container registry - I have apt-get on the server and just use the default Ubuntu - No distributed/network state I used to use Core OS, but all these container OSes are here today and gone tomorrow, and normally have their own conf…

[deleted]

Re: Google admits Kubernetes container tech is too complex

#320

Post by tsimionescu »

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…

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

That depends entirely on your application and the upgrade itself. Assuming we are discussing 10 different containers (e.g. 10 micro-services), k8s will normally update them in parallel but not atomically, it would be up to apication or deployment time logic to ensure they are updated as a single 'transaction'. If they are 10 copies of the same container, then k8s itself has tools for rolling upgrades where you can control the rollout.

Also, depending on application logic, the upgrade could be done in such a way that there is no need to synchronize the services, they could work with the DB as is.

Post reply on HN