Kubernetes权威指南 从Docker到Kubernetes实践全接触（第2版）
我不知道你是如何获得这本书的，可能是在百度头条、网络广告、朋友圈中听说本书
后购买的，也可能是某一天逛书店时，这本书恰好神奇地翻落书架，出现在你面前，让你
想起一千多年前那个意外得到《太公兵法》的传奇少年，你觉得这是冥冥之中上天的恩
赐，于是果断带走。不管怎样，我相信多年以后，这本书仍然值得你回忆。
Kubernetes这个名字起源于古希腊，是舵手的意思，所以它的Logo既像一张渔网，又
像一个罗盘。谷歌采用这个名字的一层深意就是：既然Docker把自己定位为驮着集装箱在
大海上自在遨游的鲸鱼，那么谷歌就要以Kubernetes掌舵大航海时代的话语权，“捕
获”和“指引”这条鲸鱼按照“主人”设定的路线巡游，确保谷歌倾力打造的新一代容器世界的
宏伟蓝图顺利实现。
虽然Kubernetes自诞生至今才1年多，其第一个正式版本Kubernetes 1.0于2015年7月才
发布，完全是个新生事物，但其影响力巨大，已经吸引了包括IBM、惠普、微软、红帽、
Intel、VMware、CoreOS、Docker、Mesosphere、Mirantis等在内的众多业界巨头纷纷加
入。红帽这个软件虚拟化领域的领导者之一，在容器技术方面已经完全“跟从”谷歌了，不
仅把自家的第三代OpenShift产品的架构底层换成了Docker+Kubernetes，还直接在其新一代
容器操作系统Atomic内原生集成了Kubernetes。
Kubernetes是第一个将“一切以服务（Service）为中心，一切围绕服务运转”作为指导思
想的创新型产品，它的功能和架构设计自始至终都遵循了这一指导思想，构建在Kubernetes
上的系统不仅可以独立运行在物理机、虚拟机集群或者企业私有云上，也可以被托管在公
有云中。Kubernetes方案的另一个亮点是自动化，在Kubernetes的解决方案中，一个服务可
以自我扩展、自我诊断，并且容易升级，在收到服务扩容的请求后，Kubernetes会触发调度
流程，最终在选定的目标节点上启动相应数量的服务实例副本，这些副本在启动成功后会
自动加入负载均衡器中并生效，整个过程无须额外的人工操作。另外，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人都有理由重视这门新技术。
谁能比别人领先一步掌握新技术，谁就在竞争中赢得了先机。惠普中国电信解决方案
领域的资深专家团一起分工协作，并行研究，废寝忘食地合力撰写，在短短的5个月内完成
了这部厚达500多页的Kubernetes权威指南。经过一年的高速发展，Kubernetes先后发布了
1.1、1.2和1.3版本，每个版本都带来了大量的新特性，能够处理的应用场景也越来越丰
富。本书遵循从入门到精通的学习路线，全书共分为六大章节，涵盖了入门、实践指南、
架构原理、开发指南、高级案例、运维指南和源码分析等内容，内容详实、图文并茂，几
乎囊括了Kubernetes 1.3版本的方方面面，无论是对于软件工程师、测试工程师、运维工程
师、软件架构师、技术经理，还是对于资深IT人士来说，本书都极具参考价值。