在阿里云开发者社区的帮助下，这一年多写的《K8S从懵圈到熟练》系列做成了一本电子书。以下是对外发布的大纲和逐字稿。

大家好，我是阿里云的声东，我目前在阿里云全球技术服务部。

我们团队负责整个阿里云产品售后技术兜底的工作。用户在使用阿里云云产品的时候，比如云服务器，负载均衡，中间件等，如果遇到技术疑难类问题，最终都会收敛到我们团队。

这次分享的目的，主要是想给大家推荐一下我们最近做的这本电子书，名字叫《深入浅出Kubernetes》。这本书电子书实际上是我们处理阿里云海量线上真实问题的技术沉淀，所以书的内容和视角可能和大家在市面上看到的都不一样。

在介绍电子书之前，我会跟大家分享一下我理解的Kubernetes，以及 我在Kubernetes集群之上的问题排查经验。

目录

首先，我们来看一下这次分享的内容。

这次分享有三部分内容，第一部分我跟大家介绍一下什么是Kubernetes，相信很多人或多或少都听过这个东西，这部分内容我会分享下我的一些观点和理解。

第二部分我会分享一下怎么学习和理解Kubernetes技术。这部分内容我会通过两个具体实例，来详细介绍下我的经验。

最后呢，我会介绍下我们做的这本电子书。

什么是Kubernetes？

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

未来什么样

第一个角度，未来什么样。

这是一张未来大部分公司后端IT基础设施可能的架构图，简单来说，以后基本上所有公司的IT基础设施都会部署在云上。然后用户会基于Kubernetes 把底层云资源拆分成具体的集群单元，给不同的业务使用。而随着业务微服务化的深入，服务网格这样的服务治理逻辑会变得跟下边这两层一样，成为基础设施的范畴。

目前，阿里内部基本上所有的业务都跑在云上。而其中大约有一半的业务已经迁移到了自己定制Kubernetes集群上。另外据我了解，阿里会在今年完成100%的基于Kubernetes集群的业务部署。

而服务网格这块，在阿里的一些部门，像蚂蚁金服，其实已经有线上业务在用了。大家可以通过 蚂蚁一些同学的分享来了解他们的实践过程。

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

Kubernetes与操作系统

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

这是一张传统的操作系统 和Kubernetes的比较。大家都知道，作为一个传统的操作系统，像Linux或者Windows，它们扮演的角色，就是底层硬件的 一个抽象层。它们向下管理计算机的硬件，像内存或CPU，然后把底层硬件 抽象成一些易用的接口，用这些接口，向上对应用层提供支持。

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

这里的应用比较特别。这些应用都是容器化的应用。如果对容器不太了解的同学，可以简单把这些应用，理解为一个应用安装文件，打包了所有的依赖库，比如libc这些。这些应用不会依赖底层操作系统的库文件。

Kubernetes与Google运维解密

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

这页左边是一个Kubernetes集群，右边是一本非常有名的书，就是Google的运维解密这本书。相信很多人都看过这本书，而且有很多公司目前也在实践这本书里的方法。包括故障管理，运维排班等等。

Kubernetes和这本书的关系呢，我们可以把他们比作剑法和气功的关系。不知道这里有多少人看过笑傲江湖。笑傲江湖里的华山派分两个派别，气宗和剑宗。气宗注重气功修炼，而剑宗更强调剑法的精妙。实际上气宗和剑宗的分家，是因为华山派两个弟子偷学一本葵花宝典，两个人各记了一部分，最终因为观点分歧分成了两派。

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

Borg因为是Google内部的系统，所以我们一般人是看不到的，而Kubernetes基本上继承了Borg在集群自动化管理方面非常核心的一些技术。所以如果大家看了这本书，觉得很厉害，或者在实践这本书里的方法，那大家一定要深入理解下Kubernetes。

技术演进史

最后一个角度：技术演进史。

早期的时候，我们做一个网站后端，可能只需要把所有的模块放在一个可执行文件里，就想最左边这张图一样，我们有UI、数据和业务三个模块，这三个模块被编译成一个可自行文件，跑在一台服务器上。

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

微服务架构会把单体应用拆分成低耦合的小应用。这些应用各自负责一个功能，然后每个应用实例独占一台服务器，它们之间通过网络互相调用。

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

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

但是混部会引入两个新问题，一个是依赖库兼容性问题。这些应用 底层依赖的库文件版本可能完全不一样，安装到一个操作系统里，肯定会出问题。另一个问题是应用的调度和集群资源管理的问题。

比如一个新的应用被创建出来，我们需要考虑这个应用被调度到哪个服务器，调度上去之后资源够不够用这些问题。

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

顺便提一句，我们可能会因为，集群里混部的应用太多，这些应用关系错综复杂，而没有办法去排查一些像请求响应慢这样的问题。所以类似服务网格这类服务治理的技术，肯定会成为下一个趋势。

怎么学习Kubernetes

分享第二部分内容，我们来看一下怎么学习Kubernetes。我会从三个方面总结一下我的经验。一个是为什么Kubernetes学习起来比较难，一个是我个人的一些方法建议，最后是两个实际例子。

难点

总体来说，Kubernetes之所以门槛比较高，比较难学习，一个是因为它的技术栈非常深，包括了内核，虚拟化，容器，软件定义网络SDN，存储，安全，甚至可信计算等，绝对可以称得上全栈技术。

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

最后，因为Kubernetes是一个通用的计算平台，所以它会被用到各种业务场景中去，比如数据库。据我所知，像我们的PolarDB Box一体机就是计划基于Kubernetes搭建。另外还有边缘计算，机器学习，流计算等等。

方法

基于我个人的经验，学习Kubernetes，我们需要从了解、动手、以及思考三个方面去把握。

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

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

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

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

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

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

下边我会用 电子书中的两个例子 来具体解释一下上边的方法。

举例一

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

我们怎么来理解 Kubernetes的控制器呢。请大家先看一下最左边这张图。这张图是一个经典的Kubernetes架构图，这张图里有集群管控节点和工作节点，管控节点上有 中心数据库，API Server，调度器及一些控制器。

中心数据库是集群的核心存储系统，API Server是集群的管控入口，调度器负责把应用调度到资源充沛的节点上。而控制器是我们这里要说的重点。控制器的作用，我们用一句话概括，就是“让梦想照进现实”。从这个意义上来讲，我自己也经常扮演控制器的角色，我女儿如果说，爸爸我要吃冰激凌，那我女儿就是集群的用户，我就是负责把她这个愿望实现的人，就是控制器。

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

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

从控制器的角度观察Kubernetes的时候，我们其实得到了Kubernetes最根本的一个原理了。就是控制器模式。

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

举例二

第二个例子呢，我们来看一个 真实问题的 排查过程。这个问题是 一个命名空间 不能被删除的问题。问题稍微有点复杂，我们一步一步来看。

命名空间是 Kubernetes集群的 一个收纳盒机制，我们可以使用命名空间 对集群里的资源 做分类。就像这里的 第一张图片一样。这个盒子 就是命名空间，它里边收纳了 橡皮和铅笔。

命名空间 可以被创建 或者删除。我们经常会遇到 一些集群 不能删除命名空间的问题。遇到这个问题，我们如果 完全不知道 怎么排查。第一步 我们可能会想到，研究一下API Server 是怎么处理 这个删除操作的，因为API Server 就是集群的 管理入口。

API Server本身 是一个应用，我们可以通过 提升这个应用的 日志级别，来深入理解它的操作流程。在这个问题里，我们会发现，API Server收到删除命令，但是就没有其他信息了。

这里我们需要 稍微理解下命名空间 的删除过程，用户在删除 命名空间的时候，其实命名空间 并不会 被直接删除掉，而会被改成删除中的状态。这个时候 命名空间控制器 就会看到这个状态。

为了理解 命名空间控制器 的行为，我们同样可以 把控制器的日志级别提高 来查看详细的日志。这个时候呢，我们会发现，控制器正在尝试去获取 所有的API组。

到这里呢，我们需要去理解两个事情。一个是为什么命名空间，控制器会去获取API组。第二个是API组到底是什么。

我们先看第二个问题，API组到底是什么。简单来说，API组就是集群API的分类机制，比如网络相关的API就在networking这个组里。而通过网络API组 创建出来的资源 就属于这个组。

那为什么命名空间，控制器会去获取API组呢，是因为在删除命名空间的时候，控制器需要删除命名空间里的所有资源。这个操作呢，不能像我们删除文件夹一样，会把里边的文件都一起删掉。

命名空间收纳了资源，实际上是这些资源 用类似索引的机制，指向了这个命名空间。集群只有遍历所有的API组，找出指向这个命名空间的资源，才能逐个把它们删除掉。

而遍历API组这个操作呢，会使得集群的API Server和它的扩展进行通信。这是因为，API Server的扩展，也可以实现一部分API组。所以想知道 命名空间里 是不是有包括这个扩展 定义的资源，就必须和它通信。

到这一步之后，问题实际上变成API Server和他的扩展之间通信的问题。也就是删除资源的问题就变成了网络问题。

阿里云的Kubernetes集群，是在VPC网络，也就是虚拟局域网上创建的。默认情况下，VPC的只认识VPC网段的地址，而集群里边的容器，一般会使用和VPC不同的网段。比如VPC使用172网段，那容器可能就使用192网段。

我们通过在VPC的路由表里，增加容器网段的路由，可以让容器使用VPC网络进行通信。

比如右下角我们有两个集群节点，他们的地址是172网段，那我们给路由表里增加192网段的路由，就可以让VPC把发给容器的数据转发到正确的节点上，再由节点发给容器。

而这里的路由，是在节点加入集群的时候，由路由控制器来添加的。路由控制器在发现有新节点加入集群之后，会立刻反应，给路由表里增加一条路由项。

添加路由项这个操作，其实是对VPC的一次操作。这个操作是需要使用一定的授权的，因为这本质上跟我们线下一台机器访问云上资源是差不多的，肯定需要授权。

这里路由控制器使用的授权，是以RAM角色的方式绑定到路由控制器所在的集群节点上的。而这个RAM角色，正常会有一系列的授权规则。

最后，我们通过检查，发现用户修改了授权规则，所以导致了这个问题。

这个问题比较典型，其中用到的排查方法和研究方法，我在这本电子书里有详细的介绍，如果大家需要了解细节，可以下载电子书来看。

《深入浅出Kubernetes》

这次分享的第三部分内容，我跟大家推荐一下我们做的这本电子书。书名叫《深入浅出Kubernetes》。

大家可以扫描页面中的二维码下载电子书。

或者通过以下链接：

https://developer.aliyun.com/article/753196

这本电子书是 最近一年多，我在Kubernetes和服务网格领域的 部分技术沉淀。其中一些内容已经在Infoq，阿里技术、阿里巴巴云原生等 公众号上发表过了。

这次在阿里云 开发者社区 和我们团队同事的帮助下做成一本电子书。我们希望能借助这本书来分享阿里云线上问题诊断经验。

因为我们团队每天都会处理大量的线上问题，所以肯定有很多新的案例出来，这本书我们就当做是1.0版本，后续新的案例，我们会通过2.0，3.0的方式分享给大家。

这本书总结起来有三个特点：第一个是简单易懂地分析了Kubernetes集群的一些核心原理；第二个是阿里云真实线上问题的诊断集锦；第三个是难得一见的Kubernetes集群诊断方法和调试方法。

首先，因为我们是阿里云售后技术服务团队，我们的一项重要的工作就是服务。我们经常需要用易懂的方式，甚至比较有创新的方法，把一些很生涩难懂的技术解释给用户听。所以这本电子书的很多原理的解释是比较形象也比较易懂的。

其次，因为我们是阿里云售后技术兜底团队，我们要解决大量疑难、曲折的问题。部分问题因为复现概率极低，可能需要几个月才会有一个客户遇到。这样的问题也只有在阿里云这样的大平台上才有机会复现和诊断出结果。这本书里就包括了一些这样的案例。

最后，这本书里的案例分析，一般都会关联多个Kubernetes组件。针对这些组件的调试方法，大家一般是不会在其他地方看得到的。

以上就是我今天分享的全部内容，感谢大家的时间。