阿里云数字新基建系列包括5本书,题材涉及Kubernetes、混合云架构、云数据库、CDN原理与流媒体技术、云服务器运维(Windows),囊括了领先的云技术知识与阿里云技术团队独到的实践经验,是国内IT技术图书又一套重磅作品!
本书是阿里云容器服务产品线上实践的技术沉淀,主要包括理论篇和实践篇两部分内容。理论篇注重理论介绍,核心是Kubernetes on Cloud,即着重介绍Kubernetes和阿里云产品的结合。实践篇是疑难问题的诊断案例,希望通过案例来和读者分享Kubernetes深度问题诊断经验。
我们相信,Kubernetes on Cloud是未来十年云原生应用的底座,在这个底座之上势必会产生无数创新和实践,所以我们希望这本书可以对此技术的发展产生些许推动作用。
来自于阿里云核心技术团队的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 是按照控制器模式运行的。
控制器模式在我们的生活中无处不在,这里我拿冰箱举个例子。我们在控制冰箱的时候,并不会直接去控制冰箱里的制冷系统或者照明系统。我们打开冰箱的时候,里边的灯会打开,在我们设置了想要的温度之后,就算我们不在家,制冷系统也会一直保持这个温度。这背后就是因为有控制器模式在起作用。