说到Kubernetes, 看到它发展到今天，有些意料之外，实在意料之中。意料之外在于，相比发展更为久远的Mesos，Kubernetes在人气上已经有后来居上的感觉，尽管两者并不完全在同一个维度上。意料之中在于，Kubernetes有Google这个亲爹，自带光环，从一出生，就得到了社区的强烈关注，另外一个原因还在于Kubernetes更加专注于容器集群本身，解决了Docker用户的痛点。
另外一点，Kubernetes这个名字用作某一项技术或者框架其实是显得过长了，但是我们技术人总是充满智慧的，立刻想出了K8s这个NickName (K8s是把用8代替8个字符“ubernete”而成的缩写), 一下逼格就不一样了。
在这里不得不佩服一下Google的野心，技术积累和对技术发展的洞察力。Kubernetes明面上，由Google在2014年启动，但实际上，在容器技术变成热门之前，Google早就已经运行了Kubernetes十多年了，只是那个时候并不叫Kubernetes，而是一个内部代号Borg的系统，一直用于Google自己的网络服务并提供支持，后来Kubernetes 用Go语言重新实现了一遍Borg而已，然后Google将Kubernetes开源出来，提供给技术社区使用。Google无论是移动战略（Android），AI (Tensorflow)，还是到我们现在讲的云计算，都始终立足于平台化，把用户圈进来，然后建立自己巨大的商业价值。
回到技术本身，简单的说，kubernetes是管理container的工具，正如Openstack是管理VM的工具一样。container可以运行在物理机上，也可以运行在VM上。但是呢，很多云厂商的IaaS都是通过openstack来管理虚拟机的，应用用户又通过这些虚拟机上运行docker，然后使用K8s进行管理。
（来源于Wikipedia）
我个人的感受看，Kubernetes 对应用程序开发人员来说很有吸引力，因为它减轻了容器化后对中间件团队和运维团队的依赖程度，这个痛，只有实战过的人才懂。另外，K8s 的核心优势在于为应用程序开发人员提供了用于编排无状态 Docker 容器的强大工具， 同时它提供了Paas平台需要的一些通用功能，比如部署，扩展，负载均衡，日志，监控等。
最后，总结一点，Kubernetes之所以能发展到今天，除了“先天基因”，因为它比市面上其他容器集群管理更懂技术人员。 真正了解DevOps的价值，重用容器，并在基于容器的应用中驱动更好的架构实践。
下一集讲什么？ Mesos or Swarm? 请大家拭目以待。
扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes
欢迎转载，带上以下二维码即可
