如何轻松学习 Kubernetes？

时间 2020-08-18

标签如何轻松学习 kubernetes 繁體版

原文原文链接

做者 | 声东阿里巴巴技术专家数据库

<关注阿里巴巴云原生公众号，回复排查便可下载电子书>后端

导读：《深刻浅出 Kubernetes》一书共聚集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操做！

什么是 Kubernetes？安全

咱们来看一下什么是 Kubernetes。这部份内容我会从四个角度来跟你们分享一下个人见解。服务器

1. 将来什么样网络

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

目前，阿里基本上全部的业务都跑在云上。而其中大约有一半的业务已经迁移到了本身定制 Kubernetes 集群上。另外据我了解，阿里计划今年完成 100% 的基于 Kubernetes 集群的业务部署。负载均衡

而服务网格这块，在阿里的一些部门，像蚂蚁金服，其实已经有线上业务在用了。你们能够经过蚂蚁一些同窗的分享来了解他们的实践过程。less

虽然这张图里的观点可能有点绝对，可是目前这个趋势是很是明显的。因此将来几年， Kubernetes 确定会变成像 Linux 同样的，做为集群的操做系统无处不在。运维

2. Kubernetes 与操做系统机器学习

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

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

这里的应用比较特别，就是这些应用都是容器化的应用。若是对容器不太了解的同窗，能够简单把这些应用，理解为一个应用安装文件。安装文件打包了全部的依赖库，好比 libc 这些。这些应用不会依赖底层操做系统的库文件来运行。

3. Kubernetes 与 Google 运维解密

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

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

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

Borg 由于是 Google 内部的系统，因此咱们通常人是看不到的，而 Kubernetes 基本上继承了 Borg 在集群自动化管理方面很是核心的一些理念。因此若是你们看了这本书，以为很厉害，或者在实践这本书里的方法，那你们必定要深刻理解下 Kubernetes。

4. 技术演进史

早期的时候，咱们作一个网站后端，可能只须要把全部的模块放在一个可执行文件里，就像上图同样，咱们有 UI、数据和业务三个模块，这三个模块被编译成一个可执行文件，跑在一台服务器上。

可是随着业务量的大幅增加，咱们没有办法，经过升级服务器配置的方式来扩容。这时候咱们就必须去作微服务化了。

微服务化会把单体应用拆分红低耦合的小应用。这些应用各自负责一块业务，而后每一个应用的实例独占一台服务器，它们之间经过网络互相调用。

这里最关键的是，咱们能够经过增长实例个数，来对小应用作横向扩容。这就解决了单台服务器没法扩容的问题。

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

可是混部会引入两个新问题，一个是依赖库兼容性问题。这些应用依赖的库文件版本可能彻底不同，安装到一个操做系统里，必然会出问题。另外一个问题就是应用调度和集群资源管理的问题。

好比一个新的应用被建立出来，咱们须要考虑这个应用被调度到哪台服务器，调度上去以后资源够不够用这些问题。

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

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

怎么学习 Kubernetes？

1. Kubernetes 学习难点

整体来讲，Kubernetes 之因此门槛比较高，比较难学习，一个是由于它的技术栈很是深，包括了内核，虚拟化，容器，软件定义网络 SDN，存储，安全，甚至可信计算等，绝对能够称得上全栈技术。

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

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

2. 了解、动手、思考

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

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

咱们须要知道各类技术的演进历史，好比容器技术是怎么从 chroot 这个命令发展而来的，以及技术演进背后要解决的问题是什么，只有知道技术的演进史和发展的动力，咱们才能对将来技术方向有本身的判断。

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

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

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

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

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

3. 用冰箱来理解集群控制器

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

咱们怎么来理解 Kubernetes 的控制器呢？上面这张图是一个经典的 Kubernetes 架构图，这张图里有集群管控节点和工做节点，管控节点上有中心数据库，API Server，调度器及一些控制器。

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

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

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

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

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

4. 为何删除不掉命名空间

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

命名空间是 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 就必须和扩展通讯。

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

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

咱们经过在 VPC 的路由表里，增长容器网段的路由项，可让容器使用 VPC 网络进行通讯。

在右下角这张图，咱们有两个集群节点，他们的地址是 172 网段，那咱们给路由表里增长 192 网段的路由项，就可让 VPC 把发给容器的数据转发到正确的节点上，再由节点发给具体的容器。

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

添加路由项这个操做，实际上是对 VPC 的一次操做。这个操做是须要使用必定的受权的，这是由于这个操做跟线下一台机器访问云上资源是差很少的，确定须要受权。

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

最后，咱们经过检查，发现用户修改了受权规则，因此致使了这个问题。

<关注阿里巴巴云原生公众号，回复排查便可下载电子书>

课程推荐

为了更多开发者可以享受到 Serverless 带来的红利，这一次，咱们集结了 10+ 位阿里巴巴 Serverless 领域技术专家，打造出最适合开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云计算的新范式——Serverless。

点击便可免费观看课程：https://developer.aliyun.com/learning/roadmap/serverless

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”