This is not true. It throws out the Google-specific parts of Borg (like integration with Google's service discovery, load balancing, and monitoring systems) and improves a number of things compared to Borg. For a good reference on the evolution of Borg into Kubernetes, I recommend the recent Kubernetes Podcast interview with Brian Grant: https://kubernetespodcast.com/episode/043-borg-omega-kuberne...
> Google themselves don't use it
This is not true, and the reasons why it hasn't replaced Borg are related to the integrations I mentioned above (which will take time to integrate or replace) and the zillions of lines of borg config that have built up over the years, rather than concerns that people outside of Google would have (production-worthiness, reliability, etc.)
(Disclaimer: I worked on Borg at Google, and now work on Kubernetes at Google.)
What's good for the bottom 90% of tech companies probably isn't for the top 10%.
https://adamdrake.com/command-line-tools-can-be-235x-faster-...
When all you have is a hammer everything starts to look like a nail.
Implementing the whole "DevOps" idea just becomes a whole lot easier when developers don't even have the concept of their snowflake server anymore. And yes - k8s has a ton of overhead and is pretty complex to get into at first, but it all makes sense. There are many points that could be criticised about it, it's far from perfect, but having a standardised way of deploying whatever application has been a massive game changer in the development environments I've been thrown in.
Source/disclaimer: I'm a consultant that has seen quite a few k8s/openshift fuckups and success stories, both on large and small scale.
Exactly. Instead of having something so simple that scales for 90% of everyone's needs. We have solution that Most enterprise wants and filter down from top to bottom. And it is true in almost all Tech things related.
Google open sourced dataflow as Beam - https://beam.apache.org
Think of Autopilot as an automation that tweaks a pod's request/limits according to what it actually needs in order to reduce waste and thus improve cluster utilization.
(I _think_ this no longer qualifies as secret after https://github.com/kubernetes/kubernetes/issues/44095)
That said, k8s is quite extensible and it would definitely be possible to add such a component as a controller.
Without Google using, validating and releasing those design, we might be stuck with MPI and NFS for a lot longer.
Sure, MPI might blow MR out of the water in term of number-crunching, but it is also way harder to use.