Kubernetes这个名字起源于古希腊，是舵手的意思，所以它的Logo既像一张渔网，又像一个罗盘。谷歌采用这个名字的一层深意就是：既然Docker把自己定位为驮着集装箱在大海上自在遨游的鲸鱼，那么谷歌就要以Kubernetes掌舵大航海时代的话语权，“捕获”和“指引”这条鲸鱼按照“主人”设定的路线巡游，确保谷歌倾力打造的新一代容器世界的宏伟蓝图顺利实现。
虽然Kubernetes自诞生至今才1年多，其第一个正式版本Kubernetes 1.0于2015年7月才发布，完全是个新生事物，但其影响力巨大，已经吸引了众多业界巨头纷纷加入。红帽这个软件虚拟化领域的领导者之一，在容器技术方面已经完全“跟从”谷歌了，不仅把自家的第三代OpenShift产品的架构底层换成了Docker Kubernetes，还直接在其新一代容器操作系统Atomic内原生集成了Kubernetes。
通常我们会把Kubernetes看作Docker的上层架构，就好像Java与J2EE的关系一样：J2EE是以Java为基础的企业级软件架构，而Kubernetes则以Docker为基础打造了一个云计算时代的全新分布式系统架构。但Kubernetes与Docker之间还存在着更为复杂的关系，从表面上看，似乎Kubernetes离不开Docker，但实际上在Kubernetes的架构里，Docker只是其目前支持的两种底层容器技术之一，另一个容器技术则是Rocket，后者来源于CoreOS这个Docker昔日的“恋人”所推出的竞争产品。
Kubernetes同时支持这两种互相竞争的容器技术，这是有深刻的历史原因的。Docker的快速发展打败了谷歌曾经名噪一时的开源容器技术lmctfy，并迅速风靡世界。但是，作为一个已经对全球IT公司产生重要影响的技术，Docker背后的容器标准的制定注定不可能被任何一个公司私有控制，于是就有了后来引发危机的CoreOS与Docker分手事件，其导火索是CoreOS撇开了Docker，推出了与Docker相对抗的开源容器项目——Rocket，并动员一些知名IT公司成立委员会来试图主导容器技术的标准化，该分手事件愈演愈烈，最终导致CoreOS“傍上”谷歌一起宣布“叛逃”Docker阵营，共同发起了基于CoreOS Rocket Kubernetes的新项目Tectonic。这让当时的Docker阵营和Docker粉丝们无比担心Docker的命运，不管最终鹿死谁手，容器技术分裂态势的加剧对所有牵涉其中的人来说都没有好处，于是Linux基金会出面调和矛盾，双方都退让一步，最终的结果是Linux基金会于2015年6月宣布成立开放容器技术项目（Open Container Project），谷歌、CoreOS及Docker都加入了OCP项目。但通过查看OCP项目的成员名单，你会发现Docker在这个名单中只能算一个小角色了。OCP的成立最终结束了这场让无数人揪心的“战争”，Docker公司被迫放弃了自己的独家控制权。作为回报，Docker的容器格式被OCP采纳为新标准的基础，并且由Docker负责起草OCP草案规范的初稿文档，当然这个“标准起草者”的角色也不是那么容易担当的，Docker要提交自己的容器执行引擎的源码作为OCP项目的启动资源。
事到如今，我们再来回顾当初CoreOS与谷歌的叛逃事件，从表面上看，谷歌貌似是被诱拐“出柜”的，但局里人都明白，谷歌才是这一系列事件背后的主谋，不仅为当年失败的lmctfy报了一箭之仇，还重新掌控了容器技术的未来。容器标准之战大捷之后，谷歌进一步扩大了联盟并提高了自身影响力。2015年7月，谷歌正式宣布加入OpenStack阵营，其目标是确保 Linux 容器及关联的容器管理技术Kubernetes能够被OpenStack生态圈所容纳，并且成为OpenStack平台上与KVM虚机一样的一等公民。谷歌加入OpenStack意味着对数据中心控制平面的争夺已经结束，以容器为代表的应用形态与以虚拟化为代表的系统形态将会完美融合于OpenStack之上，并与软件定义网络和软件定义存储一起统治下一代数据中心。
谷歌凭借着几十年大规模容器使用的丰富经验，步步为营，先是祭出Kubernetes这个神器，然后又掌控了容器技术的制定标准，最后又入驻OpenStack阵营全力将Kubernetes扶上位，谷歌这个IT界的领导者和创新者再次王者归来。我们都明白，在IT世界里只有那些被大公司掌控和推广的，同时被业界众多巨头都认可和支持的新技术才能生存和壮大下去。
Kubernetes就是当今IT界里符合要求且为数不多的热门技术之一，它的影响力可能长达十年，所以，我们每个IT人都有理由重视这门新技术。谁能比别人领先一步掌握新技术，谁就在竞争中赢得了先机。
Kubernetes是第一个将“一切以服务（Service）为中心，一切围绕服务运转”作为指导思想的创新型产品，它的功能和架构设计自始至终都遵循了这一指导思想，构建在Kubernetes上的系统不仅可以独立运行在物理机、虚拟机集群或者企业私有云上，也可以被托管在公有云中。Kubernetes方案的另一个亮点是自动化，在Kubernetes的解决方案中，一个服务可以自我扩展、自我诊断，并且容易升级，在收到服务扩容的请求后，Kubernetes会触发调度流程，最终在选定的目标节点上启动相应数量的服务实例副本，这些副本在启动成功后会自动加入负载均衡器中并生效，整个过程无须额外的人工操作。另外，Kubernetes会定时巡查每个服务的所有实例的可用性，确保服务实例的数量始终保持为预期的数量，当它发现某个实例不可用时，会自动重启该实例或者在其他节点重新调度、运行一个新实例，这样，一个复杂的过程无须人工干预即可全部自动化完成。试想一下，如果一个包括几十个节点且运行着几万个容器的复杂系统，其负载均衡、故障检测和故障修复等都需要人工介入进行处理，那将是多么难以想象。
