书名：Kubernetes从入门到实践
ISBN：978-7-115-53471-2
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
编 著 赵 卓
责任编辑 谢晓芳
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书共11章，由浅入深地介绍了Kubernetes的相关技术。主要内容包括容器的发展史，Kubernetes的核心概念，Kubernetes的安装与部署，Kubernetes的基本单位Pod，Kubernetes中的各种控制器，Kubernetes发布服务的方式，Kubernetes中的存储卷与用法，Kubernetes中的几种实用扩展，Kubernetes管理资源的方式与Pod的调度原理，API Server的基本使用方式及身份认证与授权方式等。
本书适合开发人员、运维人员、测试人员阅读，同时也适合对Kubernetes或容器技术感兴趣的读者阅读。
过去，应用程序的部署并没有如今这么简单，要先找到物理机或者虚拟机，而这些机器必须先安装操作系统，再部署基础应用与数据库，最后才部署目标应用程序。作者曾体验过这些复杂的部署过程，也曾编写过长达几十页的部署文档。每次部署一台新机器时，总会面临各种不同的挑战，要解决各式各样的运行环境问题。即使后来引入了自动化部署，也没有从根源上解决运行环境问题。
直到容器技术（如Docker）发展与流行起来，才真正从根源上解决了这些问题。容器技术将应用程序与程序依赖都打包到镜像中，供开发者复制、分发。使用容器技术，不仅提高了打包的速度，还拥有更高的资源利用率。最重要的是，能保持运行环境的一致性，真正做到“一次构建，随处运行”（build once, run anywhere）。这为开发人员、运维人员与测试人员带来了极大的便利，大大提高了效率，降低了运维成本。对于现代互联网企业，更高的效率就意味着能拥有更大的生存空间，更能实时响应竞争环境的变化。
基于基础的容器技术，Kubernetes是一套容器集群管理系统，是一个开源平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能，充分发挥容器技术的潜力，给企业带来真正的便利。Kubernetes拥有自动包装、自我修复、横向缩放、服务发现、负载均衡、自动部署、升级回滚、存储编排等特性，不仅支持Docker，还支持Rocket。Kubernetes与DevOps、微服务等相辅相成，共同推进现代的数字化变革。
作为当下及未来的主要技术方向之一，对于个人职业生涯及公司发展而言，Kubernetes至关重要，但由于它涉及操作系统、网络、存储、调度、分布式原理等方面的综合知识，因此直接导致了初学者面对Kubernetes时，感觉无从下手，摸不着头脑。即使已经熟练运用的用户也可能无法全面掌握Kubernetes的深层原理。因此，作者开始有了写作本书的想法，由浅入深全面剖析Kubernetes的功能与特性，不管是刚刚入门Kubernetes的用户，还是已经熟练运用Kubernetes的用户，都会从中有所收获。
本书适合开发人员、运维人员、测试人员阅读，也可供任何对Kubernetes或容器技术感兴趣的读者参考。
本书共11章，由浅入深介绍Kubernetes的各个方面，即使读者不具备任何开发或运维的功底，也可以阅读。
第一部分（第1章和第2章）主要介绍容器技术的发展史，并对Kubernetes的架构与工作流程及核心概念进行介绍。该部分有助于读者了解容器技术的背景与它所解决的问题，从而对Kubernetes的功能有基本的了解。
第二部分（第3～8章）详细介绍Kubernetes的主要功能与特性。该部分将对各种工作负载对象（Pod与控制器）的使用、应用部署、网络、服务发现、负载均衡、存储、配置、资源管理、资源调度等进行介绍，对于每个知识点都深入分析其原理并配以清晰明了的示例，帮助读者掌握Kubernetes的主要用法。
第三部分（第9章和第10章）介绍如何对Kubernetes进行配置、管理及扩展。该部分主要介绍Kubernetes的API Server、授权与安全、可视化管理，并讨论如何扩展Kubernetes的功能。
第四部分（第11章）使用两种类型的项目作为示例，介绍如何进行部署和运维，并讲述如何使用Helm来部署项目。
读者可以根据需求选择阅读，不过最好按照顺序来阅读，这样不仅可以循序渐进，还可以从整体上对Kubernetes有深入而系统的认识。
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮（见下图）即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线投稿（直接访问www.epubit.com/selfpublish/ submission即可）。
如果您所在学校、培训机构或企业想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接通过邮件发送给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https:// www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
第1章 容器的发展史
第2章 Kubernetes的核心概念
要完全了解容器及Kubernetes，了解它真正解决什么问题，有必要花一定篇幅介绍容器的发展史。容器技术的发展离不开开发过程、应用架构的演变，它们是相辅相成的，在一定程度上说是缺一不可的。
本章会从3个方面来介绍容器的发展史，分别是开发过程的发展、应用架构的发展、部署/打包的发展，介绍容器所扮演的角色，以及它的历史定位，帮助读者真正理解容器的发展史。
开发过程大致经历了3个阶段——瀑布式开发、敏捷式开发和DevOps（在每个阶段发布产品的周期及反馈循环的快慢各不相同）。本节会结合容器技术介绍开发过程的发展。
瀑布模型是一种广泛采用的项目开发过程。瀑布模型由各个阶段组成，从上一个阶段流向下一个阶段，各个阶段都会产生反馈，从系统需求分析阶段开始，然后一直流向产品发布和维护阶段。其核心思想在于，按照一定的工序让问题变得有迹可循，将软件开发过程划分为需求分析、需求定义、概要设计、详细设计、编码、系统测试、验收测试、维护这8个阶段。各个阶段自上而下，互相衔接，就像是瀑布流水一样（见图1-1）。
图1-1 瀑布式开发
瀑布式开发的缺点是显而易见的。
（1）由于阶段的划分比较独立，因此各个阶段的衔接会存在脱节情况，即上一个阶段的成果未必适合下一个阶段。
（2）计划非常死板。任何一个环节出现延误，都会像滚雪球一般影响后续阶段。瀑布式开发通过强制的完成日期来跟踪各个项目阶段，毫无弹性。
（3）交付周期太长，过程风险难以控制且不能及时响应变化。
（4）反馈回路太长，几乎到最后阶段才能发现瀑布式开发是否适用。
容器技术在这一代开发过程中没有发挥太大作用，即使使用，也局限于最后一两个阶段。有容器固然很好，但由于瀑布模型的先天劣势，容器对它帮助不大，收效甚微。
敏捷式开发是一种以用户需求为核心，通过迭代、循序渐进完成软件开发的方法。它的核心在于，整个项目被拆分为多个拥有联系但相对独立的子项目。这些子项目通常在一个迭代周期（通常为2～4周）发布一次，而每次迭代都经历了完备的开发流程，并通过了各项测试，因此这些子项目可以作为单独的产品使用。
这种方法也非常适合一开始没有或不能完整确定需求和范围的项目，或者经常变化的项目。相对于瀑布式开发，敏捷式开发明显更具有弹性，对风险更可控。敏捷式开发的交付周期适中，反馈回路相对较短，可执行原型和部分实现的可运行系统是了解用户需求与反馈的有效媒介。每次迭代完成后，都可以基于用户反馈或总结，持续优化下一次迭代（见图1-2）。
图1-2 敏捷式开发
敏捷式开发的交付周期适中，反馈回路适中，很多开发团队会使用持续集成时间贯穿整个过程。容器技术开始在这一开发过程中显示出一定的作用。有效利用它会带来可见的良性改观，但容器技术并未起决定性作用。
很多人在讨论DevOps的时候，会把Kubernetes等同于DevOps，其实他们并未理解DevOps的精髓。简单地将DevOps理解为自动化部署，其实是很不科学的。
DevOps一词来自Development和Operation的组合，突出了软件开发人员和运维人员的沟通合作，通过自动化流程来使软件构建、测试与发布更加快捷、频繁和可靠。然而，这只是文字上的定义。
前两节已经介绍过瀑布式开发和敏捷式开发，请注意这些过程的关键点。开发过程的发展趋势如下。
（1）越来越快速、越来越频繁的交付，交付周期越来越短。
（2）更迅捷的反馈回路，反馈周期明显变短。
很多业内人士依然使用瀑布模型，一个月甚至更长时间交付一次，然后再对某些小环节实施自动化，并把它当作DevOps。这种对DevOps的理解并未上升到软件工程的高度，这样的自动化也并非DevOps。
作为第3代开发过程，DevOps比敏捷式开发拥有更短的交付周期，更快的反馈回路。从需求分析到发布产品再到生产环境，敏捷式开发大约一个迭代周期中（2～3周）有一次交付，而DevOps呢？最快的DevOps只有几分钟，常见的有一小时、半天等。
DevOps是怎么做到的呢？这里必须要理解一个概念，即“最小原子产品”。每一个“最小原子产品”都是一个单独发布的产品（这个产品也许只是某个特征，甚至有的只需要几分钟就可以完成编码）。伴随着全链路监控，DevOps能够真正做到更快捷的持续交付，并拥有更短的反馈回路。相对于敏捷式开发，DevOps响应变化的速度更快，对风险更可控，如图1-3（a）与（b）所示。发布频率越高，项目中的变化就越小，也越能灵活响应。
图1-3 敏捷式开发与DevOps的风险
对于这种方式，必须理解一个要点，如果敏捷式开发每两周做一次交付，那么DevOps在两周里会有10多次的交付。也就是说，执行从需求到部署这一系列过程（比如，需求测试、回归测试、本地部署、生产环境部署），DevOps会比敏捷式开发多执行10次以上。如果在一个低效、不增效环节较多的组织中实现DevOps，简直就是噩梦。
不增效环节并不是只靠自动化就可以解决的，比如在有些组织中轮转每个过程时，需要填写各种毫无意义的单据，审批增加的等待时间，由于项目粒度太大而导致代码冲突很多，测试人员和部署人员隔墙丢包等。这些并非仅靠自动化就可以解决，要真正实现DevOps，要在公司上下对这些毫无价值的额外环节进行不断优化，然后再讨论自动化。然而，自动化也是必不可少的。
作为自动化部署的一大利器，Kubernetes高效的部署、卓越的集群管理、强大的反馈监控等，能够给DevOps打下坚实的基础（如果测试人员、运维人员需要频繁部署，并且每次都卡在部署环节中的环境问题上或部署低效，则DevOps在两周内可能比敏捷式开发多走几十次流程，简直让人崩溃）。而Kubernetes本身并不是DevOps，而DevOps也不是Kubernetes。它们是相辅相成的，Kubernetes这样的平台会真正在DevOps这种开发过程中尽其所能，大放异彩。另外，Kubernetes也是DevOps中不可或缺的一环。
应用架构大致经历了单体架构、多层架构和微服务架构3个阶段。本节会结合容器技术介绍应用架构的发展。
单体架构是指部署在单台物理机上的应用架构。在软件架构中，还有一些经典的分层架构，如经典的3层架构从上到下依次由用户界面层、业务逻辑层与数据访问层组成。这类架构之所以能够流行有其历史原因。在分层架构的时代，多数企业的系统往往较简单，用户量也不大，而这种分层架构在本质上是单体架构的数据库管理系统（见图1-4）。
图1-4 单体架构
通过集中式管理，这类架构原本非常适合小项目。但随着新功能的增加，原本一个小项目渐渐变成一个庞然大物，臃肿不堪。随着用户量的增加，亦很难实现动态缩容、扩容。
单体架构的缺点非常明显，包括但不限于以下这些。
代码维护难：代码的功能耦合在一起，稍不注意就有分析遗漏或改到不想改的功能。另外，还有各种历史开关与成堆的遗弃代码，这导致分析难度极大，无用功较多。
部署不灵活：构建时间长，有任何小修改就必须重新构建整个项目，这个过程往往很长。部署麻烦，部署后的重启耗时太长。
总体而言，如果应用规模本身非常小（微服务本身也是微小的单体应用），使用容器技术能带来可观的效益。然而，当这类架构的应用当发展到一定规模时，由于本身太过臃肿且同一时间线并发的冲突项目较多，几乎很难应用容器技术，甚至有时会适得其反。有时这类应用使用非容器技术会更高效。通过非容器技术实现部分文件增量更新，或通过Puppet等基于文件的运维工作来进行部署、管理。但这并不是说不用容器是好事一桩，只表明这只是暂时的无奈之举。
单体架构与多层架构也不是绝对一成不变的。随着技术的不断发展，对于应用的各项指标有了更高的要求，很多企业原本就有这类已无法满足需求的庞大的单体架构应用，在升级换代的过程中，会逐渐分解/重构这类大型应用，将其变为扩展性更好、更易于维护和部署的小粒度的分布式应用。而这些应用最先应进行集中治理、统一调度，根据需要逐渐变为自治、去中心化的应用。基于这些过程，渐渐演化出如今的微服务架构。
微服务是指拥有独立业务意义的小型服务。简单地说，微服务就是提交量很微小的服务，可谓麻雀虽小五脏俱全，这种服务一定要区别于系统。微服务是一个或者一组相对较小且独立的功能单元，是用户可以感知的最小功能集。每个服务都有自己的处理机制和轻量级的通信机制，能够部署在一个或者多个服务器上。
因为微服务的粒度很小，它仅限于对单一职责的业务进行封装和处理，在整个生命周期只做好一件事情，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单，没有并行维护冲突。这些服务能够独立部署和运行在某个进程中，使代码能够灵活组织并拥有灵活的发布节奏。单个微服务启动较快，使快速交付和响应变化成为可能。微服务在技术上也不受既有系统的约束，可根据需要对适合的问题选择适合的技术，进行独立演化。各个服务之间使用与服务所用技术和语言无关的通信机制进行交互与集成（见图1-5）。
图1-5 微服务架构
相对于单体架构，微服务架构是更能激发业务创新的一种架构模式，也能让系统更快地响应变化。为了尽快响应变化，如果说DevOps是在软件开发流程和实践方面提出的解决方案，那么微服务架构就是在软件技术和架构层面提出的应对之策。
话虽如此，使用微服务还要解决以下难题。
（1）就像拼图一样，单位越小，就越难拼出完整的图。微服务的粒度较小，相对于整体应用来说，服务的个数就会更多。如果一个系统被拆分成零零散散的微服务，那么要组成完整系统的难度自然要大得多。
（2）微服务并没有自我管理的能力，由谁来控制各个微服务的启动和停止？由谁来控制其版本的升级或降级？
（3）虽然微服务为高效的动态伸缩、容灾等打下了基础，但它本身并无这个能力，由谁来决定什么时候启动更多的微服务？它们的流量应该如何调度和分发？
（4）在注册新服务时，如何让用户能访问？安全策略如何集中管理？如何快速定位系统故障和跟踪到具体服务？整个系统状态如何监控？
由此可见，微服务对部署与监控提出了更高的要求，而能满足这些要求的，正是容器技术。容器技术使开发环境与生产环境完全相同，解决微服务对机器的诉求问题。使用Kubernetes能充分对承载微服务的容器进行管理，对其进行动态扩容和缩容、版本控制、容灾处理、服务注册与发现、监控、动态调节CPU与内存等。对于微服务的应用来说，Kubernetes这样的平台是必需的。
顾名思义，物理机就是由硬件组成的实体计算机，在这台实体机器上安装操作系统，并直接部署应用的运行环境及应用程序。很久以前，在部署一个应用时，往往会将多个应用部署到一台物理机上。这种方式最大的问题就是所有应用都集中在一起部署，没有任何隔离。假设其中有一个应用发生异常或者管理员执行了误操作，可能就会直接导致服务器崩溃，结果殃及池鱼，机器上的所有应用一起失效。这种部署的扩容也相当麻烦。物理机的部署直接与硬件挂钩，有时还会由技术活变为体力活（见图1-6）。
图1-6 物理机的部署
显然，要克服直接使用物理机的各个弊端，就要引入虚拟化技术，将一台计算机虚拟化为多台逻辑计算机。在一台物理机上同时运行多台逻辑计算机，每台逻辑计算机可运行不同的操作系统，并且应用程序可以在相互独立的空间内运行，互不影响，从而显著提高计算机的利用率。
在操作系统和硬件之间加入一个虚拟机监控程序（hypervisor），可以实现虚拟化系统。虚拟机监控程序允许多台虚拟机共享底层硬件，访问服务器上包括磁盘和内存在内的所有物理设备。虚拟机监控程序不但协调这些硬件资源的访问，而且在各台虚拟机之间施加防护，互相隔离。当服务器启动并执行虚拟机监控程序时，它会加载所有虚拟机客户端的操作系统，同时给每台虚拟机分配适量的内存、CPU和磁盘。虚拟机监控程序支持多个操作系统或多个配置不同的相似操作系统。
虚拟机的运行环境相对纯净，便于定期抓取状态、备份、复制、挂起和恢复。虚拟机便于管理，能够最大限度减少物理资源的使用，提高利用率。每个应用程序可以运行在独立的操作系统中，它们之间互不干涉，某个程序的崩溃也不会影响其他任务。只要拥有支持的硬件，虚拟机就可以无缝迁移，因此维护和升级简单。虚拟机的部署也便于控制访问权限，以及检测病毒入侵等（见图1-7）。
图1-7 虚拟机的部署
然而，虚拟机仍不是最佳方式。虚拟机依赖操作系统，每次备份所需硬盘空间过于庞大，整体性能相对于物理机又存在一定损耗，且启动较缓慢。虚拟化技术一直在不断发展，直到容器诞生，才发生了质的变化。
容器是一种新兴的虚拟化方式。在传统虚拟机技术中，首先虚拟出一套硬件，然后运行一个完整的操作系统，最后才运行应用依赖项和应用程序。而容器并不需要这些，它可以让应用程序直接运行于宿主内核，自己本身没有内核，也不需要硬件虚拟。如果不同的容器之间存在相同的底层应用依赖项，这些依赖项可以共用。容器要比传统虚拟机更轻便。容器的部署见图1-8。
图1-8 容器的部署
容器与传统的虚拟化方式相比具有众多的优势。
容器与虚拟机的特性对比如表1-1所示。
表1-1 容器与虚拟机的特性对比
| 对比项 |
容器 |
虚拟机 |
|---|---|---|
| 启动速度 |
秒级 |
分钟级 |
| 空间占用 |
一般以MB为单位 |
一般以GB为单位 |
| 性能 |
接近物理机 |
相对于物理机存在明显损耗 |
| 单台机器支持量 |
可支持上千个容器 |
可支持几十台虚拟机 |
然而，容器技术本身只是单机版的应用，并没有解决容器的编排问题。例如，容器没有Web管理界面，也无法实现任务调度策略、监控报警等。随着越来越多的开发者使用了容器技术，编排平台的重要性日益突出。所有人都翘首以盼能使用优秀的容器平台，直到Kubernetes开源，才圆了开发人员的梦。
Kubernetes项目由Google公司在2014年启动。Kubernetes建立在Google公司超过10多年的运维经验基础之上，Google所有的应用都运行在容器上，然后与社区中最好的想法和实践相结合。Kubernetes是目前最受欢迎的容器平台，如图1-9所示。
图1-9 Kubernetes
Kubernetes是一套容器集群管理系统，是一个开源平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。Kubernetes拥有自动包装、自我修复、横向缩放、服务发现、负载均衡、自动部署、升级回滚、存储编排等特性。Kubernetes与DevOps、微服务等相辅相成，密不可分，三者的关系如图1-10所示。
图1-10 铁三角（DevOps、微服务、容器）
下一章将会详细讲解容器技术，以及Kubernetes的基础概念，介绍其架构、工作流程及核心概念。
