k8s前世今生

导言

那这次给大家带来的更新内容呢是我们的kubernetes，也叫k8s。那为什么叫k8s呢？可能很多人还是有一定疑问的，对吧？好那主要的原因，大家看这个kubernetes单词，k和s之间呢是由8个字母所组成，所以简称为k8s就是这么粗暴。可能大家呢对我们的kubernetes有了一定的了解，或者是还在路上，或者是完全都不知道这是什么，对吧？那我想表达的就是k8s一定会成为以后的企业的技术平台的标准，或者说现在已经标准以来，那我会带大家呢去趟平这条路，随着后面的时间对吧，逐渐的去趟平，那今天呢我们就先去看一看，瞧一瞧，对吧？

那kubernetes到底是怎样来的？以及它到底有哪些优点能够成为我刚才所说的以后标准的交互的这么一个平台，那这是非常重要的。

三个阶段

那今天的内容呢会首先分为三个阶段，第一个是我们的发展经历，对吧？

为什么需要有kubernetes以及kubernetes到底有怎样的特点，以及他到底是怎样过五关斩六将去达到今天的这么一种辉煌的状态，对吧？好，这是第一部分发展经历的部分。

那第二部分呢我会给大家详细讲一下我们的课程体系中间到底要讲哪些东西，对吧？这还是很重要的。

那第三部分呢就是k8s的一些组件的说明，每个组件到底要是干嘛的，对吧？有什么作用？那在心里呢一定要有一个自己的见解。那当然我会先讲我的见解，大家再去吸收至成为自己的见解，这点是很重要的对吧？吸收完了以后必须要有转换

 

 

 

发展经历

 

好，那我们先看第一个部分，也就是发展经历。那对于云计算来说，我们知道它会有这么一些交互标准，比如在这里显示第一个对吧？Iaas也就是我们所谓的基础设施即服务，基础设施及服务那它的典型的代表厂商呢就是我们的阿里云。

当然我说的是国内的对吧？如果是国际上的话，那应该就是iws，那它的数据量包括它的用户量都是世界第一的。那阿里云呢在我们国内做的风生水起，那如果选择的话，究竟选择阿里云的话还是不错的。好，那第二个部分呢是 Paas叫平台及服务。那第三个是我们的SAAS叫软件设施及服务，如果大家有用到做过这个服务的话，你会发现对吧？它是非常的简单。我们如果想用office套件，我不需要再去经过什么一小时的安装去得到，我只需要去访问到他的 BS结构，也就是通过浏览器访问到它的服务器端即可完成这么一个office文件的这么一个创建啊修改啊等等。

 

 

细心的同学呢你应该会发现对吧？

我在PaaS的时候简单的描述一下就跳过了，那现在呢我们主要对他进行讲解，首先在我们国内做的最典型的paas厂商，也就是平台即服务的厂商的典型代表，就是新浪云，那新浪呢有个叫新浪云，对吧？号称免运维的这么一个云平台。那如果是一些比较老的一些开发工程师，可能比较接触过这个新浪的，当时呢可以免费去申请这么一个平台去运行你的一些代码项目，比如Java啊php啊等等。

那其实paas服务是有经历过这么一个更替的，最开始的时候，用户下单，对吧？这里有用户，下单是我们的云厂商，比如是新浪，下载到新浪以后，新浪的后台接收到这个单以后，他要去派一个运维去进行所谓的构建，环境的构建，也就是你的领导数钱数的笑，你在背后忙的嘻哈哈，那这可能就是最开始的paas服务的这么一个典型的状态。那在后面呢我们有了一些所谓的运维工具，对吧？比如unstable啊 pop啊等等，那通过这些运维工具，我们可以让它自动化的帮我们去完成这些所谓的环境的创建，可能是一个Java的环境，可能是一个PHP的运行环境，对吧？都是可以的。

但是有一个问题，虽然我们有这些自动化的运维工具，其实它离自动化还有很远的一部分路，因为每一个环境都不一样，他的要求不一样，你需要进行各种匹配筛选去运行，直至后来有一家公司叫做docker公司，对吧？他开用了一款产品叫做 docker，当然现在改名为docker股份有限公司了，对吧？我们之前也说过这么一个流程。那这个公司主要就是做 Paas平台的，那也就意味着docker在他们公司的地位，就是自动的去构建这些所谓的运营环境的封装体。

听出来什么概念了？也就是docker成了 Paas运行的下一代的标准，这是没有问题的，但是也会带来一个更大的问题。我们想一下，在我们传统的服务中，传统的服务中，比如唉我在我的物理物理机上，我去进行一个iOS运行一些项目，比如tomcat，后面跟上我们的阿米吧加数据库等等，组成一个大的集群，这是没有问题的。那现在我一旦容器化以后就会出现对应的问题了。好，假设那我现在呢有6台物理机，我想让这6台物理机呢去组建成1个集群。

如果在我们纯物理环境下，或者叫虚拟化环境下，传统的虚拟化环境下，我去构建一个集群并不难。比如这个是我们的Linux，四个tomcat，2个mysql。对吧？那他们之间的联通呢通过标准的TCP访问到对应主机IP的加端口即可，那这样就组成了联通。那一旦里面我被容器化以后，你会发现他们之间的映射关系就比较困难了。比如我这里面运行了一个nginx的这么一个 docker，我需要把本机的80和容器里的80进行一个映射关系，tomcat也一致，8080映射到主机8080,他也一致，对吧？

那这里其实还会有一定问题存在，我们之前学过docker，你知道他在这里的转换标准是通过一个低钠的转换，也就是需要借助到我们的防火墙，去实现这里所谓的数据包转发，效率比较低下，并且难道我的物理机上就只运行了一个tomcat吗？那这样消耗的资源能用满吗？对吧？也就意味着我需要有很多的一些容器啊在这里进行转换关系，那它的端口都是乱七八糟的，访问起来太不困难了，太困难了。那怎么做呢？或者是容器的集群化，有没有什么很好的方案？

对吧？这是我们现在衍生出来的一个问题。有需求，它就有产品，这个产品叫什么？资源管理器。好，那我们去看一看资源管理器到底又经过了哪些的过程，对吧？首先第一个映入我们眼帘呢就是阿帕奇的mesos，它是我们比较古老的这么一个资源管理器了，当最开始的时候并不是为所谓的容器化诞生的，而是就做一个基础的资源管理平台去产生的。那 mesos呢是阿帕旗下的开源的分布式的资源管理的框架，它被称为我们分布式系统的这么一个内核。

 

 

 

最开始是由我们加州大学的伯克利分校开发出来的，那后来呢被推特所选中作为它的基础平台，大规模的盛行，但是好景不长，对吧？英雄总有迟暮的那一天。那在2019年的大概是二号左右，推特公司呢在旧金山总部发布了一个技术发布会，在上面他的产品技术负责人宣布了，唉推特以后不用mesos了，全部改为我们的kubernetes，也就意味着,又有一个大巨头导向了我们的kubernetes的这么一方，也就是我们要学的这么一个组件。

那这次以后呢 mesos就是逐渐逐渐走下历史舞台，当然mesos呢也觉得这样的话，唉可能我会迟早有一天被淘汰，那怎么办呢？mesos的最新版官方公布怎么个公布结果？他说唉在我的平台上去管理kubernetes。我有这么一个设施，大家要不要用？对吧？那也就意味着他借助k8s的这么一个影响力去实现自我软件的分发，但暂时呢效果未知，因为还没有什么大型的企业要宣布采用这种框架去实现，因为kubernetes跟我们的底层物理化或虚拟化的相容已经非常简单了，为什么要再加一层mesos？

软件的添加也就意味着会诞生一个新的故障节点，得不偿失。好，这是我们的第一款软件mesos，一键三连加关注上硅谷带你上高速。

 

第二款。docker swarm。swarm这个软件呢是docker的总部，对吧？母公司去诞生了这么一个资源管理器，它也是主要实现的是我们的docker的集群化方案。那在我们的新版呢已经swarm跟我们的docker融合在一起，也就swarm已经成为了一个docker内部的这么一个组件功能。如果大家想用的话，你可以去发现安装一个docker以后你去docker swarm in need，就可以去声明出来一个 doc集群，在老版本中需要去附加一些组件，比如etcd才能实现的。

 

 

 

 

那这个东西好不好？首先它很轻量，非常轻量，本机消耗的额外资源基本上只有几十兆币而已。你要知道对于一个集群化的管理企业来说，几十兆币的资源消耗就等于没有，我们现在服务器是不是动辄就几十GB，那几十照比轻飘飘拿去玩，对吧？就这么一种状态，那为什么？我们选择的是kubernetes，而不是swarm，主要的原因就是它的功能相对于企业版，相对于我们现在主流的kubernetes来说还是太少太少。比如我想实现一个所谓的滚动更新回滚等操作，在我们的swarm里它的实现是非常非常难的，我们需要手工的去定义这个流程，太费事，那除了这些功能以外，它的本身实现好不好，我可以说非常好，非常负责任的告诉大家，这个实验的架构非常好，并且它在大环境中也能支撑，大家可以去谷歌一下，百度应该没有谷歌一下，swarm集群的实现化或叫大规模化，就这么几个单词就可以搜得到。

那有一个人呢在github上去请求大家去帮他捐助一些云主机，去实现超大型的swarm集群。那这个人现在的节点呢已经达到了上千台节点，也就上千台的swarm节点去实现它的集群化，就是想证明swarm在大型环境下也是可以用的。但是还是那句话，对于公司来说，你不仅要支撑的节点多，我还有你的功能多，对吧？比如就像我们刚才所说的这么一个滚动更新啊回滚，这在我们的日常操作中还是非常常见的。你没有那我只能说不好意思对吧？

那我不能我不能够选择你，原因是什么呢？

唉别人家有，我为什么要选择你？没有的我自己去开发，这样会消耗大量的人力以及财力。对，他没有必要。那所以至此啊他俩退出历史舞台，最起码到今天为止，他呢已经快销声匿迹了，对吧？那随之而来的就是kubernetes，那这个呢就是kubernetes这么一个logo。那谷歌定义为这个 Logo定义的含义就是，我们都知道对吧？docker它的logo是一个鲨鱼，对于kubernetes来说，就是一个舵盘对吧？舵盘那代表的含义，就是唉我是这个这群鲨鱼的领航者，他们都要听我的跟我混，这可能就是kubernetes这么一个logo的含义了。

 

 

 

好，那为此呢因为它的功能比较全面，对吧？非常稳定，非常适合企业运行，所以呢它已经成为当前的最终选择了。为此他还非常骄傲的转了一下，对吧？那这个呢就是我们的kubernetes。大家可能会有一些疑问，为什么这么个东西就突然蹦出来了，然后呢就成为我们所谓的主要的选择方案了。docker的官方的swarm不好使，伯克利亚大学 miss又是不好使，这是原因是什么？原因是他的靠山非常之大。那他的靠山是谁呢？

谷歌。那过来我们要给大家简单的说一说了，对吧？首先我们先对刚才的一些重要点进行总结，对于missus来说，大家只要去简单的了解一下即可，那它采用的是我们的阿帕奇的开源协议，对吧？在阿帕奇的基金会基金会下，阿帕奇的开源协议，然后呢它是一个开源的分布式的资源管理框架。好在2019年的5月份，最大的它的使用者推特已经退出历史舞台，全部转向为kubernetes，对吧？这个信息还是非常重要的。

那对于docker swarm来说呢，他是docker的老东家，做出来这么一个东西，那他们也是一个分布式资源的管理框架，但是它主要是对我们的容器化实现的做操作的，也就是再具体一点就是对docker 专门做的。因为它是跟docker 绑定的，如果是其他的一些容器化组件的话，可能就不支持了。需要注意一下。那在2019年的7月份，也就在不久之前，其实这里还有一个事情，就是我们国内的阿里云宣布 docker swarm的集群框架从阿里云的选择列表里剔除，也就意味着以后阿里云不给你厂不给你选择让你去安装swarm，还是kubernetes啊，默认kubernetes并且swarm没有这个选项了。

好，那我们现在要讲的kubernetes。我们刚才说他的靠山非常之巨大，那是谁？是谷歌对吧？那谷歌做了一件什么事情呢？首先我们要知道第一点就是谷歌在10年前就已经通过容器化作为它的技术架构了，10年的运行环境，你想一下它的技术是不是非常成熟，对吧？好，那他有一个主见呢叫borg，博格系统，它呢就是谷歌内部的管理这些所谓的容器的这么一个框架或叫资源管理器，很多公司都对他非常非常非常想要他，对吧？但不好意思，唉谷歌说我不差钱，我不卖，对吧？

只能我自己用。

那这个是不是大家就是看着流口水，反正也用不到。并且从谷歌跳槽出来的这一些员工，由于签了保密协议，这个架构是不不能被公告的。但是随着现代，对吧docker的大规模运行，那谷歌发现唉大家都开始研究这个所谓的资源管理器了，我需要站出来说点话了，万一以后的趋势不是我的borg系统或是不是由我领导的，那是不是还挺尴尬的对吧？所以呢他派了几名工程师，采用go语言对博格的系统进行翻写，你可以这样去理解，也就采用了博格的这么一些设计思路，去开发出了新的组件，也就是我们的kubernetes。

那至此呢我们的kubernetes诞生出来，并且开源给了我们的容器基金会对吧？成为了当前的标准，难道就是因为由于谷歌开发出来的，我们就必须去选择它吗？他一定有自己的一些特点，有哪些嘛对吧？好，特点之一，轻量级，它不同于现在现存的一些资源管理系，有的采用对吧？Java语言，有的采用一些Ruby语言，这些开发语言都有一些特性，就是它是一个解释性语，效率会稍微低下一点。

那作为我们的管理器来说，它的日常工作是非常繁忙的，并且这些语言都会消耗大量的内存，所以运营起来以后它并不轻量。那谷歌呢？库kubernetes它采用的是这个go，go语言大家应该有一些耳闻了，对吧？被誉为现代的c语言。首先它是一个解释英语效率跟c看齐，但是比c好的一处，就是它在我们的语言级别支持我们的进程管理，不需要我们人为的去控制，对吧？所以由他开发来的kubernetes对于我们的系统资源的占用是非常小的，这里的轻量级并不是说它的功能比较少，而是它的消耗的资源上。

 

好，那第二个呢是开源，这个很重要对吧？好我现在给你搞了一款软件非常非常非常好用，比如唉我数据库，对吧？结果非常贵，贵到离谱，我们按核心收费，按你的访问量收费，那这可能就是屏蔽了很多的一些企业选择它的大门，对吧？那对于kubernetes来说，这么好这么稳定还开源，那为什么不用呢？好，这是它的第二个特点，也是最重要的特点之一，对吧？好，第三个，弹性伸缩，对于互联网企业它的最大的一个属性，就是可能我们公司运行个几年就上市了，可能我们公司今天访问量是多少多少多少，明天翻倍了，后天又翻了一倍，这都是我们在互联网公司比较常见的一种状态。

那对于传统企业来说，可能做到这件事情是非常之难的，对吧？好，那就意味着对我们的kubernetes这么一个资源管理器，它的平台框架最大的一个属性要为它赋予一个弹性伸缩，弹性伸缩的概念。就是有一天我资源不够用了，从5台生成10台，并且这个过程一定要是平缓的升级，你不能我升级一下，加了一些新的节点，你又让我重起，你又让我改配置又怎么怎么怎么一堆，那这可能就不叫弹性伸缩了，对吧？这只能叫伸缩。好，那有伸缩，我们刚才是伸，那有没有缩？

也可以说我们在主节点只要通过一条命令，就可以把一些节点给它剥离出我们的集群调度里去，那这样的话可能有8台缩减为5台甚至更低。如果我们的访问量不需要这些节点的话，我是不是可以释放这些机器的资源，去减轻我的所谓的企业的资金的消耗，这就是我们kubernetes的弹性伸缩。好，下一个负载均衡，那kubernetes结构内部呢已经实现了我们的模块之间的负载均衡，也就完全不需要我们自己去搭一个什么调度器去实现，由我们的kubernetes本机去实现，并且它的负载均衡的框架，最新版本中采用了IPVS的框架，ipvs大家都不陌生了对吧？

 

毕竟这是一个国人的骄傲。张文雄博士开发的对吧？好，那它的负载能力在软件里面老大哥的地位，所以它的负载量我们是完全不需要担心的，也就是很多一些我们工程师需要解决的问题，对于我们kubernetes平台来说，他都早已经帮我们完善完了，这也是为什么kubernetes能火，这是有原因的，他的实力确实强大，这也是我们为什么要学习他的原因。你想一下这是以后的未来的对吧？我们的基础平台啊基础架构的平台，你不学能行吗？一定一定需要去好好的把它给学习一下，对吧？

甚至我们刚才已经说过未来以来那到底哪些人可能需要去掌握我们的这么一个kubernetes的这么一个资源管理器，来学习我们这套视频。

 

比如软件工程师，那比如我们的测试工程师，运维工程师，对吧？那还有我们的软件架构师，项目经理啊对吧？那只要是这些类似于我们需要去接触到我们的底层框架的，都是需要去学习的，很重要，那这呢就是我们的第一节的内容。

带大家去学习了一下我们的kubernetes的来历，对吧？包括现在所处于的领域以及它的一些特点。好，我们下节课再见