阿里云数字新基建系列：云原生操作系统Kubernetes

阿里云数字新基建系列包括5本书，题材涉及Kubernetes、混合云架构、云数据库、CDN原理与流媒体技术、云服务器运维（Windows），囊括了领先的云技术知识与阿里云技术团队独到的实践经验，是国内IT技术图书又一套重磅作品！

《阿里云数字新基建系列：云原生操作系统Kubernetes》是阿里云容器服务产品线上实践的技术沉淀，主要包括理论篇和实践篇两部分内容。理论篇注重理论介绍，核心是Kubernetes on Cloud，即着重介绍Kubernetes和阿里云产品的结合。实践篇是疑难问题的诊断案例，希望通过案例来和读者分享Kubernetes深度问题诊断经验。

我们相信，Kubernetes on Cloud是未来十年云原生应用的底座，在这个底座之上势必会产生无数创新和实践，所以我们希望这本书可以对此技术的发展产生些许推动作用。

阿里云全球技术服务部团队在支持企业架构云原生化方面，积累了丰富的实战经验，服务了数万个国内外企业客户。本书作者均来自该团队。

罗建龙，阿里云互联网行业解决方案架构师，阿里云售后云原生技术领头人。专注于传统操作系统、显卡操作系统、云原生操作系统等领域。

刘中巍，阿里云容器高级技术专家。在加入阿里巴巴之前，曾在微软亚洲研究院做虚拟现实方向研究。现主要负责阿里云容器服务产品的弹性伸缩与监控、大数据的研发，从事容器的持续交付、持续集成方案的设计与实现。在云计算、分布式系统、图像识别与虚拟现实方向有多年的开发实践经验。

张城，阿里云日志服务技术专家。负责阿里巴巴集团、蚂蚁金服、阿里云等的日志采集基础设施，服务数万名内外部客户。同时负责云原生相关的日志解决方案，包括系统组件、负载均衡、审计、安全、Service Mesh、事件、应用等日志方案。目前主要关注可观察...

阿里云全球技术服务部团队在支持企业架构云原生化方面，积累了丰富的实战经验，服务了数万个国内外企业客户。本书作者均来自该团队。

罗建龙，阿里云互联网行业解决方案架构师，阿里云售后云原生技术领头人。专注于传统操作系统、显卡操作系统、云原生操作系统等领域。

刘中巍，阿里云容器高级技术专家。在加入阿里巴巴之前，曾在微软亚洲研究院做虚拟现实方向研究。现主要负责阿里云容器服务产品的弹性伸缩与监控、大数据的研发，从事容器的持续交付、持续集成方案的设计与实现。在云计算、分布式系统、图像识别与虚拟现实方向有多年的开发实践经验。

张城，阿里云日志服务技术专家。负责阿里巴巴集团、蚂蚁金服、阿里云等的日志采集基础设施，服务数万名内外部客户。同时负责云原生相关的日志解决方案，包括系统组件、负载均衡、审计、安全、Service Mesh、事件、应用等日志方案。目前主要关注可观察性、AIOps、大规模分析引擎等方向。

黄珂，阿里巴巴高级研发工程师，主要负责Kubernetes容器存储和网络相关的基础研发工作，参与了阿里集团内部有状态应用的带存储和网络的迁移，以及大规模实施在线业务存储计算分离项目。对Kubernetes中存储相关组件的设计，以及规模化场景的性能优化具有很深的理解和丰富的实践经验。

苏夏，阿里云智能AES专家服务高级技术工程师，现主要负责阿里云大客户售后技术支持以及重点项目的专家服务工作，在云原生kubernetes、服务网格、弹性计算、负载均衡等领域有多年的技术支持经验。

高相林，阿里云原生应用平台高级开发工程师，主要负责阿里云容器服务产品的集群和组件生命周期管理系统研发，以及版本生命周期管理。Kubernetes开源社区成员。

盛训杰，阿里云高级技术支持工程师。在阿里云全球技术服务部，负责阿里云弹性计算产品及容器服务产品的技术支持工作，在企业上云及应用容器化转型方面有着丰富的实施落地经验。

遨游海域的座头鲸、成群结队的角马、群聚飞翔的火烈鸟……构成了一幅幅壮美的生存画面，迁徙是自然界令人叹为观止的景观。

数智时代的“上云”与自然界的“迁徙”何其相似啊！

2021年伊始，我们博文视点的编辑团队联合阿里云技术团队，为广大IT技术人员奉上“阿里云数字新基建系列”。这个系列包括5本书，题材涉及Kubernetes、混合云架构、云数据库、CDN原理与流媒体技术、云服务器运维（Windows），囊括了领先的云技术知识与阿里云技术团队独到的实践经验，是国内IT技术图书中又一套重磅作品！

《云原生操作系统Kubernetes》是这套系列书较早出版的一本，本书的特点请见宝贝长图！强烈建议您阅读！

这是一个人们对上云已经有了共识，但是对怎么样上好云还在深入讨论和探索的新阶段。

在上云之后，我们会遇到一些典型的问题，比如怎么样使用云服务器的问题。如果我们把多个业务混合部署在云服务器上，这些业务可能会因为使用了不同版本的库文件出现兼容性问题 ；而如果我们让每个业务实例独享一个云服务器，又会有明显的资源碎片问题。

包括了容器、编排调度、服务网格、持续集成交付（CICD）等在内的云原生技术，是“上好云”这个新阶段的核心技术，也是解决“上好云”这个问题的最佳实践策略和方法论。

作为本书的开篇，我们希望在序章部分交代清楚几件事情：

（1）多角度下的云原生“操作系统”——Kubernetes 的基本理论 ；（2）学习和研究 Kubernetes 的方法 ；（3）本书的成书背景。

什么是 Kubernetes

我们来看一下什么是 Kubernetes。在这一部分，我们会从四个角度和大家 分享我们的看法。

第一个角度，未来是什么样的

图 0-1 是一张未来企业的 IT 基础设施架构图。简单来说，未来基本上所有的企业都会把 IT 基础设施部署在云上，用户会基于 Kubernetes 把底层云资源分割成具体的集群单元，给不同的业务使用。

之后，随着业务微服务化的落地，服务治理会越来越重要。像服务网格这类把服务治理逻辑下沉到基础设施层的思路，势必成为下一个趋势。

目前，阿里巴巴几乎所有的业务都“跑”在云上，其中一大半业务已经迁移到了内部定制版的 Kubernetes 集群上，而且这个比例还在迅速增加中。

对于服务网格技术来说，一些企业（比如蚂蚁集团）其实已经有线上业务在 使用了。大家可以通过蚂蚁集团一些技术专家的公开分享来了解他们的实践过程。

虽然这张图里的观点可能有一些绝对，但是目前这个趋势是非常明显的。 未来几年，Kubernetes 肯定会像 Linux 一样，作为集群的操作系统无处不在。

第二个角度，Kubernetes 与操作系统

图 0-2 是传统操作系统（单机操作系统）和云原生系统（集群操作系统）的比较图。大家知道，像 Linux 或者 Windows 这些传统的操作系统，它们扮演 的角色是底层硬件的抽象层。它们向下管理计算机硬件，如内存和 CPU，然后把底层硬件抽象成易用的接口，向上对应用层提供支持。

而 Kubernetes 技术，我们也可以理解为一个操作系统。这个操作系统也是一个抽象层。它向下管理的硬件，不是内存或者 CPU 这种硬件，而是多台计算机组成的集群。这些计算机本身就是普通的单机系统，有自己的操作系统和硬件。Kubernetes 把这些计算机当成一个资源池统一管理，向上对应用层提供支撑。

Kubernetes 上的应用的特别之处在于，它们都是容器化应用。对容器不太 了解的读者，可以简单地把它们理解成安装包。安装包里包括了所有的依赖库， 如 libc 函数库等，使得这些应用不必依赖底层操作系统库文件就可以直接运行。

第三个角度，Kubernetes 与 Google 运维解密

图 0-3 的左边是 Kubernetes 集群示意图，右边是一本非常有名的书《SRE Google 运维解密》。相信很多人都看过这本书，而且有很多公司正在实践这本 书里的方法，如故障管理、运维排班等。

Kubernetes 和这本书的关系，可以比作剑法和气功的关系。读者看过金庸的《笑傲江湖》的话，可能会记得，《笑傲江湖》里的华山派分为两个派别，剑宗和气宗。

剑宗强调剑法的精妙，而气宗更注重气功修炼。实际上剑宗和气宗的“分 家”，是因为华山派两个弟子偷学了同一本《葵花宝典》，但是两个人各记了一 部分内容，最终因为观点分歧分成了两派。

Kubernetes 实际上源自 Google 的集群自动化管理和调度系统 Borg，也就 是这本书里讲的运维方法所管理的对象。Borg 系统和书里讲的方法论，可以被看作一件事情的两个方面。如果一个公司只学习他们的运维方法（比如设了很多 SRE 职位）而不懂这套方法所管理的对象，其实就是学习《葵花宝典》，但是只学了一部分。

Borg 因为是 Google 内部的系统，所以一般人是看不到的，而 Kubernetes 基本上继承了Borg 在集群自动化管理方面非常核心的一些理念。所以大家如 果看了这本书，觉得非常有参考价值，或者已经在实践这本书里的方法，就一定要深入理解 Kubernetes。

第四个角度，技术演进史

在早期，我们做一个网站后端，可能只需要把所有的模块放在一个可执行文件里，就如同图 0-4 中第一个架构图一样。网站后端包括界面、数据和业务三个模块，这三个模块被编译成一个可执行文件，“跑”在一台服务器上。

但是随着业务的大幅增长，我们没有办法通过升级服务器配置的方式来使 后端扩容，这时候我们就必须做微服务了。

微服务会把单体应用拆分成低耦合的小应用。这些应用各自负责一块相对 独立的业务，每个小应用实例独占一台服务器，它们之间通过网络互相调用。 这就是图 0-4 中第二个架构图的模式。

这里最关键的是，我们可以通过增加实例个数，来对小应用做横向扩容。这就解决了单台服务器无法扩容的问题。

微服务之后会出现一个问题，就是一个实例独占一台服务器的问题，这种部署方式的资源浪费其实是比较严重的。这时我们自然会想到，把这些实例混合部署到底层服务器上。

但是混合部署会引出两个新问题。一个是依赖库兼容性问题，这些应用依赖的库文件版本可能完全不一样，安装到一个操作系统里，就会有兼容性问题；另一个问题是应用调度和集群资源管理的问题，比如一个新的应用被 创建出来，我们需要考虑这个应用被调度到哪台服务器，以及调度之后资源 够不够用的问题。

依赖库兼容性问题，实际上是靠容器化来解决的，也就是每个应用自带依赖库，只跟其他应用共享内核，而调度和资源管理问题就是 Kubernetes 所要解决的问题。

所以整个架构最终会演变成图 0-4 中第三个架构图的模式。

如何学习 Kubernetes

我们会从三个方面总结我们的经验 ：一是为什么 Kubernetes 学习起来比较难，二是一些方法和建议，三是一个实际例子。

如图 0-5 所示，总体来说，之所以 Kubernetes 门槛比较高，学习起来比较困难，一个原因是它的技术栈非常深，包括内核和系统，以及虚拟化、容器技 术、网络、存储、安全，甚至可信计算等，绝对可以称得上全栈技术。

同时，Kubernetes 在云环境中的实现，肯定会涉及非常多的云产品，比如在阿里云上，Kubernetes 集群的实现用到了云服务器、虚拟网络、负载均衡、安全组、日志服务、云监控、ahas 和 arms 等中间件产品、服务网格、弹性伸缩等。

最后，因为 Kubernetes 是一个通用的计算平台，所以它会被用到各种业务 场景中去，比如数据库、边缘计算、机器学习、流计算等。

基于我们的经验，学习 Kubernetes 需要从了解、动手、思考三个方面去把 握，如图 0-6 所示。

首先，了解其实很重要，特别是了解技术的演进史，以及技术的全景图。

一方面，我们需要知道各种技术的演进历史，比如容器技术是怎么从 chroot 这个命令发展而来的，以及技术演进背后要解决的问题是什么，只有知道技术的演进史和发展的动力，我们才能对未来技术方向有自己的判断。

另一方面，我们需要了解技术全景图。对 Kubernetes 来说，我们需要了解 整个云原生技术栈，包括容器、CICD、微服务、服务网格等，知道 Kubernetes 在整个技术栈里所处的位置。

其次，除了这些基本的背景知识以外，学习 Kubernetes 技术，动手实践是 非常关键的。

从我们和大量工程师一起解决问题的经验来说，很多人其实不会去深入研 究技术细节。我们经常开玩笑说工程师有两种，一种是 search engineer，就是 搜索工程师，一种是 research engineer，就是研究工程师。很多工程师遇到问题，就用搜索引擎搜索一下，如果找不到答案，就直接请别人帮忙了。这样是很难深入理解一个技术的。

最后，就是怎么去思考，怎么去总结了。我们需要在理解技术细节之后，不断地问自己，细节的背后有没有什么更本质的东西。也就是我们要把复杂的细节看简单，然后找出普遍的模式来。

下面用一个例子来具体解释上面的方法。

这个例子是关于集群控制器的，如图 0-7 所示。我们在学习 Kubernetes 的 时候会听到几个概念，像声明式 API、Operator、面向终态设计等。这些概念本质上都是在讲一件事情，就是控制器模式。

我们怎么来理解 Kubernetes 的控制器呢？请大家先看一下第一张图。这张 图是一个经典的 Kubernetes 架构图，这张图里有集群 Master（管控）节点和 Worker（工作）节点，Master 节点上有中心数据库（Database）、集群接口（API Server）、调度器（Scheduler）以及各类控制器（Controller）。

中心数据库是集群的核心存储系统，API Server 是集群的管控入口，调度 器负责把应用调度到资源充沛的节点上，而控制器是我们这里要说的重点。

控制器的作用，我们用一句话概括，就是“让梦想照进现实”。从这个意义上来讲，我自己（罗建龙）也经常扮演控制器的角色，我女儿如果说，“爸爸， 我要吃冰激凌”，那我女儿就是集群的用户，我就是负责把她这个愿望实现的人， 也就是控制器。

除了 Master 节点以外，Kubernetes 集群有很多 Worker 节点，这些节点都 部署了 Kubelet 和 Proxy 这两个代理。Kubelet 负责管理 Worker 节点，包括应用在节点上启动和停止之类的工作。Proxy 负责把服务的定义落实成具体的 iptables 或者 ipvs 规则。其实这里服务的概念，简单来说就是利用 iptables 或者 ipvs 来实现负载均衡。

如果从控制器的角度来看第一张图的话，我们就会得到第二张图，也就是 说，集群实际上就包括一个数据库、一个集群入口，以及很多个控制器。这些组件，包括调度器、Kubelet 和 Proxy 在内，实际上都是在不断地观察集群里各种资源的定义，然后把这些定义落实成具体的配置，比如容器启动或 iptables 配置。

从控制器的角度观察 Kubernetes，我们其实得到了 Kubernetes 最根本的一条原理，就是 Kubernetes 是按照控制器模式运行的。

控制器模式在我们的生活中无处不在，这里我拿冰箱举个例子。我们在控制冰箱的时候，并不会直接去控制冰箱里的制冷系统或者照明系统。我们打开冰箱的时候，里边的灯会打开，在我们设置了想要的温度之后，就算我们不在家，制冷系统也会一直保持这个温度。这背后就是因为有控制器模式在起作用。

上篇　理论篇（技术进阶）

第1章　鸟瞰云上Kubernetes

1.1　内容概要 002

1.2　云资源层

1.2.1　专有版

1.2.2　托管版

1.2.3　Serverless版

1.3　单机系统层

1.4　集群系统层

1.4.1　专有版

1.4.2　托管版

1.4.3　Serverless版

1.5　功能扩展层

1.5.1　监控

1.5.2　日志

1.5.3　DNS

1.6　总结

第2章　认识集群的大脑

2.1　从控制器视角看集群

2.2　控制器的产生与演进

2.2.1　设计一台冰箱

2.2.2　统一操作入口

2.2.3　引入控制器

2.2.4　统一管理控制器

2.2.5　Shared Informer

2.2.6　List Watcher

2.3　控制器示例

2.3.1　服务控制器

2.3.2　路由控制器

2.4　总结

第3章　网络与通信原理

3.1　背景

3.2　阿里云Kubernetes集群网络大图

3.3　集群网络搭建

3.3.1　初始阶段

3.3.2　集群阶段

3.3.3　节点阶段

3.3.4　Pod阶段

3.4　通信原理

3.5　总结

第4章　节点伸缩的实现

4.1　节点增加原理

4.1.1　手动添加已有节点

4.1.2　自动添加已有节点

4.1.3　集群扩容

4.1.4　自动伸缩

4.2　节点减少原理

4.3　节点池原理

4.4　总结

第5章　认证与调度系统

5.1　“关在笼子里”的程序

5.1.1　代码

5.1.2　“笼子”

5.1.3　地址

5.2　得其门而入

5.2.1　入口

5.2.2　双向数字证书验证

5.2.3　KubeConfig文件

5.2.4　访问

5.3　择优而居

5.3.1　两种节点，一种任务

5.3.2　择优而居

5.3.3　Pod配置

5.3.4　日志级别

5.3.5　创建Pod

5.3.6　预选

5.3.7　优选

5.3.8　得分

5.4　总结

第6章　简洁的服务模型

6.1　服务的本质是什么

6.2　自带通信员

6.3　让服务照进现实

6.4　基于Netfilter的实现

6.4.1　过滤器框架

6.4.2　节点网络大图

6.4.3　升级过滤器框架

6.4.4　用自定义链实现服务的反向代理

6.5　总结

第7章　监控与弹性能力

7.1　阿里云容器服务Kubernetes的监控总览

7.1.1　云服务集成

7.1.2　开源集成方案

7.2　阿里云容器服务Kubernetes的弹性总览

7.2.1　调度层弹性组件

7.2.2　资源层弹性组件

7.3　总结

第8章　镜像下载自动化

8.1　镜像下载这件小事

8.2　理解OAuth 2.0协议

8.3　Docker扮演的角色

8.3.1　整体结构

8.3.2　理解docker login

8.3.3　拉取镜像是怎么回事

8.4　Kubernetes实现的私有镜像自动拉取

8.4.1　基本功能

8.4.2　进阶方式

8.5　阿里云实现的ACR credential helper

8.6　总结

第9章　日志服务的集成

9.1　日志服务介绍

9.2　采集方案介绍

9.2.1　方案简介

9.2.2　运行流程

9.2.3　配置方式

9.3　核心技术介绍

9.3.1　背景

9.3.2　实现方式

9.3.3　alibaba-log-controller内部实现

9.4　总结

第10章　集群与存储系统

10.1　从应用的状态谈起

10.1.1　无状态的应用

10.1.2　有状态的应用

10.2　基本单元：Pod Volume

10.3　核心设计：PVC与PV体系

10.4　与特定存储系统解耦

10.4.1　Volume Plugin

10.4.2　in-tree（内置） Volume Plugin

10.4.3　out-of-tree（外置） Volume Plugin

10.5　Kubernetes CSI管控组件容器化部署

10.6　基于Kubernetes的存储

10.7　总结

第11章　流量路由Ingress

11.1　基本原理

11.1.1　解决的问题

11.1.2　基础用法

11.1.3　配置安全路由

11.1.4　全局配置和局部配置

11.1.5　实现原理

11.2　场景化需求

11.2.1　多入口访问Ingress

11.2.2　部署多套Ingress Controller

11.3　获取客户端真实IP地址

11.3.1　理解客户端真实IP地址的传递过程

11.3.2　ExternalTrafficPolicy的影响

11.3.3　如何获取客户端真实IP地址

11.4　白名单功能

11.5　总结

第12章　升级设计与实现

12.1　升级预检

12.1.1　核心组件检查项

12.1.2　前置检查增项

12.2　原地升级与替代升级

12.2.1　原地升级

12.2.2　替代升级

12.3　升级三部曲

12.3.1　升级Master节点

12.3.2　升级Worker节点

12.3.3　核心组件升级

12.4　总结

下篇　实践篇（诊断之美）

第13章　节点就绪状态异常（一）

13.1　问题介绍

13.1.1　就绪状态异常

13.1.2　背景知识

13.1.3　关于PLEG机制

13.2　Docker 栈

13.2.1　docker daemon调用栈分析

13.2.2　Containerd调用栈分析

13.3　什么是D-Bus

13.3.1　runC请求D-Bus

13.3.2　原因并不在D-Bus

13.4　Systemd是硬骨头

13.4.1　“没用”的core dump

13.4.2　零散的信息

13.4.3　代码分析

13.4.4　Live Debugging

13.4.5　怎么判断集群节点NotReady是这个问题导致的

13.5　问题的解决

13.6　总结

第14章　节点就绪状态异常（二）

14.1　问题介绍

14.2　节点状态机

14.3　就绪三分钟

14.4　止步不前的PLEG

14.5　无响应的Terwayd

14.6　原因

14.7　修复

14.8　总结

第15章　命名空间回收机制失效

15.1　问题背景介绍

15.2　集群管控入口

15.3　命名空间控制器的行为

15.3.1　删除收纳盒里的资源

15.3.2　API、Group、Version

15.3.3　控制器不能删除命名空间里的资源

15.4　回到集群管控入口

15.5　节点与Pod的通信

15.6　集群节点访问云资源

15.7　问题回顾

15.8　总结

第16章　网络安全组加固对与错

16.1　安全组扮演的角色

16.2　安全组与集群网络

16.3　怎么管理安全组规则

16.3.1　限制集群访问外网

16.3.2　IDC与集群互访

16.3.3　使用新的安全组管理节点

16.4　典型问题与解决方案

16.4.1　使用多个安全组管理集群节点

16.4.2　限制集群访问公网或运营商级NAT保留地址

16.4.3　容器组跨节点通信异常

16.5　总结

第17章　网格应用存活状态异常

17.1　在线一半的微服务

17.2　认识服务网格

17.3　代理与代理的生命周期管理

17.4　就绪检查的实现

17.5　控制面和数据面

17.6　简单的原因

17.7　阿里云服务网格（ASM）介绍

17.8　总结

第18章　网格自签名根证书过期

18.1　连续重启的Citadel

18.2　一般意义上的证书验证

18.3　自签名证书验证失败

18.4　大神定理

18.5　Citadel证书体系

18.6　经验

18.7　总结

附录A　本书插图索引

附录B　本书部分缩略语 P210