I think you're very deeply immersed in the Ruby/Heroku world and projecting that onto Kubernetes and everything else. Kubernetes' derives from Google's lengthy experience with Borg, which almost certainly predates Heroku. I doubt very much that Google was steeped in Heroku/Ruby culture. Yes, Heroku dynos are similar to linux containers, but containerization (the idea of binning multiple applications onto a single operating system instance) predates heroku by at least 6 years and the idea of binning multiple applications onto a single hardware instance goes back much further.
Moreover, Kubernetes and Heroku aren't even in the same class of tools. Kubernetes is an orchestrator for containers, which obviously can be used as the foundation for a PaaS, but Kubernetes isn't itself a PaaS even when you consider the various managed Kubernetes offerings which include some higher level abstractions built atop Kubernetes primitives.
Further still, it's not like Google marketed Kubernetes to any significant degree prior to its own adoption of Kubernetes as its official container orchestration offering for its cloud (which was after the writing had been on the wall for a while that Kubernetes would become the de facto container orchestrator).
TL;DR: Just because other tools and technologies predated Kubernetes didn't imply that it was significantly impacted by them.
I haven't written Ruby nor used Heroku in many years. I think it's more relevant to say I'm very deeply immersed in Open Source. I contributed to OpenRuko[1], Deis, Flynn and even wrote my own PaaS, Peas[2] that got on the front page of HN. I've seen first hand the journey that PaaS has taken. Maybe we're getting hung up on the strict definition of PaaS here. Let's just say the thing that lets us easily scale a startup idea, like Uber, Airbnb etc. Sure the dyno/docker is the core component, but we inevitably have to deal with state, Redis, Postgres etc as well. In that sense Kubernetes is very much the Open Source version of Heroku.
I think it's fairer to say that Google _repurposed_ Borg, in order not to be left out of the changing landscape. Borg may be the technical predecessor to Kubernetes, but my point is that Borg is very much not the spiritual ancestor of the new containerised paradigm.
I would be very interested to hear why Heroku and not Borg is the spiritual ancestor of Kubernetes because that claim is contrary to everything I’ve read and listened to on the matter.
I'd hoped that's exactly what comes across in my top-level comment. I've been lucky enough to be at or near the coalface of PaaS for most of its life, both as a basic engineer getting my head around deploying CRUD apps on Heroku and its ilk, and as an architect contemplating the designs of various PaaSs. My little sketch of a story is how I saw things unfold. Don't get me wrong, Kubernetes is amazing, it's everything we hoped for, I use it and recommend it. But the only thing that's innovative about it is that it's backed by a big player, so we can rely on at least a few years of active development and mindshare. But from my perspective, the great innovation, the thing that really changed the game, was The 12 Factor App manifesto. That's what deserves a documentary made about it, because it's just a text document, but it inspired so much.
And arguably borg and global work queue are predated by generic batch queue of VMScluster (and possibly TOPS-20 Galaxy, but I haven't played with those) and those are predated by IBM Job Entry Subsystem 3, which even operated in similar manner to k8s with "master" mainframe, usually a lower power model, scheduling jobs on multiple "worker" mainframes.
Moreover, Kubernetes and Heroku aren't even in the same class of tools. Kubernetes is an orchestrator for containers, which obviously can be used as the foundation for a PaaS, but Kubernetes isn't itself a PaaS even when you consider the various managed Kubernetes offerings which include some higher level abstractions built atop Kubernetes primitives.
Further still, it's not like Google marketed Kubernetes to any significant degree prior to its own adoption of Kubernetes as its official container orchestration offering for its cloud (which was after the writing had been on the wall for a while that Kubernetes would become the de facto container orchestrator).
TL;DR: Just because other tools and technologies predated Kubernetes didn't imply that it was significantly impacted by them.