One of CloudFoundry’s competitive advantages is that it has a mature deployment engine, BOSH, which enables features like scaling, resurrection and monitoring of core CF components. BOSH also supports many IaaS layers with a pluggable cloud provider abstraction. Unfortunately, BOSH’s learning curve and deployment configuration management are nightmarish. (As a BOSH committer, I think I can say this with accuracy.)
Kubernetes’ deployment abstraction is still in its infancy. Multiple target environments are available in the core repo, but they’re not all working, well tested, or supported by the primary developers. This is mostly a maturity thing. One might expect this to improve over time and increase in abstraction. For example, Kubernetes on DCOS allows deploying Kubernetes to an existing DCOS cluster with a single command.
This is consistent with everything that I have seen, heard, read, and what the numbers and actions of the players say, and what makes sense in the scheme of Google being a quite busy company with Kubernetes far from being its core focus, unlike PCF is for Pivotal.
The point being is that (1) Cloud Foundry enables aligning an entire enterprise under the cloud foundry umbrella that is an entirely big thing in terms of corporate uniformity, the lack thereof has been a major issue, (2) Cloud Foundry is more efficient, simple as that, and (3) Kubernetes has attributes that are superior in some things, but these superior attributes (and superior is subjective, but is superior in the opinion of a good many people) come at the cost of giving up ground on uniformity, simplicity, and efficiency. There is a trade off.
And finally, unless Google spins off Kubernetes as a separate business, there is no way in heck the issue of being well-supported by the vendor is every going to come close to how Pivotal supports you.
But yes, overtime, Kubernetes will improve, and so will Pivotal.
Whether or not Kubernetes can ever get to “good enough” so no one will ever want to go to Pivotal is a common long-term threat (that rarely, but occasionally, comes to pass) in the technology landscape. Microsoft certainly did that to Apple on the PC. Windows was “good enough” even though it mostly sucked.
I do not think that customers come to Pivotal simply to help them with their Kubernetes issues, but rather based upon a holistic list of concerns and issues, and Kubernetes support is just one of those elements that needs to be checked off.
By the same token, someone who does not want the holistic solution provided by Pivotal, and wants to retain their way of doing things, and adopts Kubernetes as their solution, is not going to be looking at Pivotal anyways.
Companies look at Pivotal because they are in pain and scared, and Pivotal creates not just a better way to improve app production but the entire developer culture to make it happen. Either a company wants and needs this, or a company can keep doing things in their own way and make Kubernetes part of their siloed developmental infrastructure. A choice some departments make and others do not. Perhaps Docker becomes part of the infrastructure as well. No reason a company cannot have some departments Kubernetes and some using Docker.