> K8s developers are most definitely not primarily sponsored by Google - more than 60% of K8s devs are NOT Googlers.
The key metric, in my view, is how many of them can approve PRs into master. How many of them are not Googlers?
Moreover, what would happen if a PR arrived that might make K8S incompatible with GCE, but be otherwise better for everyone else? I am certain it would be summarily rejected by Google.
> Overlay networks are definitely not a hack - many partners set them up with great benefit. The fact is networking is hard (tm), and unless you're just looking for a flat network, then you're going to have to use SOMETHING.
I respectfully disagree. The use of multiple IP addresses per node is a hard requirement of K8S, even though it is arguably unnecessary in environments whose servers can be bound to arbitrary ports.
By doing so, K8S made an explicit tradeoff that was better suited to Google's cloud offering than others'. I'm not saying it was the wrong decision; I'm simply saying that it forces complexity on those who operate in single-IP-per-host environments. (In case you think I'm unfairly laying blame, I point the finger equally at AWS and other cloud providers who refuse to make it simple to allocate a useful number of IP addresses per instance.)
I maintain my characterization that overlay networks are a hack: they make tracing more complex (tcpdump doesn't natively understand VXLAN or decapsulate their frames); they are compatible with few (if any) NetFlow analyzers (which are often used by orgs who use them for IDS and other purposes); and they add overhead to packet processing, particularly in virtualized environments that don't support VXLAN hardware offloading.