I am writing this for folks who are reading this thread and wondering what's of said here is true and what's not true.
* Google conspiracy theories - (Google is doing it to lock everyone in).
Not true. Kubernetes was created as a best-practices fully open source Borg, the very reason it's using Docker and Etcd is the desire of Googlers to work with OSS community and it paid back by Red Hat and later CoreOs and others joining the project.
Kubernetes is complex, yes, but so is Mesos and OpenStack, and pretty much any other production grade orchestration system I've seen, so I would disregard this argument as well.
* Google is not even using Kubernetes.
Google is a big company, they can't switch to Kubernetes overnight or even in 5 years. I don't have this info, but I'm pretty sure many teams are using GKE and the internal adoption grows.
* What if Google goes away? Everyone will get locked in!
Google is not the only major contributor to Kubernetes core these days. Red Hat is another one,
and many others, so this lock in point is not valid.
Google is not even BDFL - the project is governed by CNCF (OSS foundation similar to Linux foundation) and the project was donated by Google several years ago.
Kubernetes development process is organized in the most fascinating open process I have ever seen - SIGs (special interest groups) are fully open and anyone can participate and help develop the project. I have learned a lot about openness just looking at the organisation of the dev process.
* You don't need Kubernetes if you have one service.
Not true. You can benefit from Kubernetes even if you have just one container. It solves many problems you would have to solve otherwise - service discovery, configuration management, load balancing, secrets management, fail-over, routing, publishing new releases and packaging and many others.
You probably don't want to self-host Kubernetes, because it is complex unless you have experience and desire to do so, that point is valid. But thankfully, you can use GKE, AKS or EKS nowadays.
Disclaimer:
Our company works with Kubernetes so I am biased, but we have no affiliation with Red Hat or Google.
> Google conspiracy theories - (Google is doing it to lock everyone in).
My own conspiracy theory is slightly different: Google's aim is to scorch the earth so that AWS cannot form a locked-in position.
I don't think they immediately saw this possibility, but that they moved swiftly and energetically to support the growth of Kubernetes once they did see it.
The alternatives for Google were all strategically painful. ECS might have become successful, meaning a loss for Google. Mesos or Docker Swarm might have taken off, leading to snap acquisitions of the relevant companies by Microsoft or AWS, again a downside for Google.
As the plurality contributor to the commoditising winner, Google is able to prevent the other two cloud giants from pulling ahead on container orchestration.
Disclosure: I work for Pivotal, we have a Kubernetes-based product (PKS) we co-develop with Google and VMWare.
Those are all good points, I've been surprised reading this thread at the number of people that conflate Kubernetes with Google given the CNCF stewardship of the project.
One point though on complexity is that Docker swarm is substantially less complex that Kubernetes and for many use cases could do the job.
* Google conspiracy theories - (Google is doing it to lock everyone in).
Not true. Kubernetes was created as a best-practices fully open source Borg, the very reason it's using Docker and Etcd is the desire of Googlers to work with OSS community and it paid back by Red Hat and later CoreOs and others joining the project.
Kubernetes is complex, yes, but so is Mesos and OpenStack, and pretty much any other production grade orchestration system I've seen, so I would disregard this argument as well.
* Google is not even using Kubernetes.
Google is a big company, they can't switch to Kubernetes overnight or even in 5 years. I don't have this info, but I'm pretty sure many teams are using GKE and the internal adoption grows.
* What if Google goes away? Everyone will get locked in!
Google is not the only major contributor to Kubernetes core these days. Red Hat is another one, and many others, so this lock in point is not valid.
Google is not even BDFL - the project is governed by CNCF (OSS foundation similar to Linux foundation) and the project was donated by Google several years ago.
Kubernetes development process is organized in the most fascinating open process I have ever seen - SIGs (special interest groups) are fully open and anyone can participate and help develop the project. I have learned a lot about openness just looking at the organisation of the dev process.
* You don't need Kubernetes if you have one service.
Not true. You can benefit from Kubernetes even if you have just one container. It solves many problems you would have to solve otherwise - service discovery, configuration management, load balancing, secrets management, fail-over, routing, publishing new releases and packaging and many others.
You probably don't want to self-host Kubernetes, because it is complex unless you have experience and desire to do so, that point is valid. But thankfully, you can use GKE, AKS or EKS nowadays.
Disclaimer:
Our company works with Kubernetes so I am biased, but we have no affiliation with Red Hat or Google.