00:00
好，接着呢，我们去进行第三部分的讲解，也就是我们的主见说明。那整个Co的框架还是非常庞大的，对吧，那我们要对它有一个非常高的了解以后，我们再去安装我们的cos，才会有一个比较好的效果。好，那对于我们的库来说，你可以理解为它的前身是我们的博格系统，对吧，采用购员的编译版。会叫重构版，好，那就意味着如果我们先去了解我们的博格系统，再转而去看我们的cos整个调度系统的话，那可能会帮助我们更加强一部分了解，对吧？好，那我们首先我们看一下我们的博格的架构。那这张图呢，就是显示我们的博格的谷格的博格的这么一个调度器的这么一个架构，那首先你会发现这里有一堆的博格mask和light，对吧，有两部分去组成。
01:02
好，那伯格must呢，就是专门去负责这些所谓的请求的分发的，你可以理解为他是整个集群大脑对吧？那真正工作的节点其实是我们的博light。也就如果有对应的容器要运行的话，比如有一些计算能力对吧？它是通过我们的book light去给他提供的，需要大家注意一下，在这里他给他去提供对吧？好，那为了防止我们的伯格ma的由于单节点故障，所以你会发现这里有很多的副本。并且这个副本数目其实是有讲究的，需要注意一下，你仔细数一下，123455个。那我问大家一个问题，可以是两个吗？可以是四个吗？可以是六个吗？那这里为什么要这样去给大家描述呢？因为对于我们的高可用集群来说，一般我们要满足这么一个需求，就是它最好是13579。听八为什么会叫3579，最好大于一对吧，因为一个节点是不是就产生我们单节点故障了，那为什么要这样选择，防止有一天出现，比如你两票我两票，那咱俩谁是老大呢？那如果有三个人同时过来投票的话，肯定不会出现这种状态。
02:18
能理解我的意思吗？所以对于我们的高可用集群来说，它的调度器或它的高可用节点最好保持在三个以上的基数。也就3579比较合适，好，这个是需要我们特别注意的。那并且你会发现这里有这么几种访问方式，对吧？那第一种是通过我们的浏览器命令行以及我们的一些文件的读取。那在我们的库里呢，也会有这么几种方式进行所谓的整个调度集群的管理。好，那这种三种方式会被接入到我们的伯格马斯，他去理解请求以后再去做分发。
03:02
那分发这个概念很重要对吧，也就请求过来以后，我要把这个任务交给谁去处理。那假设我现在就是一个包工头，对吧，那有些任务过来了，比如哎，把什么钢筋扛到几楼，把什么砖扛到几楼，对吧？那我要去安排一些我的工人去干这件事情。那对于我来说呢，就是这么一个组件了。对吧，盖丢了也就是我们的调度器。那所有的任务在到这里以后被会被分发，分发至不同的节点去运行，当然这里并不是我们的schedule去跟我们后面的light去交互，而是schedule把数据写入至。Pax OS，这是我们谷歌的这么一个限值，对的这么一个数据库。它去存储，并且伯格呢，会实时的在这里PSOS这么一个。
04:00
数据库里进行监听。如果发现诶有我的请求了，那我会把这个请求取出来，有叫消费对吧，去处理这次任务，达到这么一个流程目的。好，那这个呢，就是我们的博格系统的这么一个。示意图了。那也意味着对于我们的K8S，它的更新版或叫精良版对吧？好，那它是不是应该也是跟它类似的，所以接下来我们看这么一张图。这是我们的K8S的这么一个架构图。里面的一些重要组件呢，我也画在这里了，对吧？好，那在这里呢，它会分为。CS结构。一个是我们的ma服务器，一个是我们的node节点。那也就意味着，在这里，他跟我们的伯格马斯一样，他也是我们的一个领导者。对吧，也是我们的领导者头头，那在这里的所有的node呢，就是我们的工人了，执行者。
05:03
好，那我们先看一下对于我们的领导者里面，它有哪些东西。第一个。了。也是，这里依然是一个调度器，任务过来以后，我还需要通过SKY了，去把这些任务分散至不同的node里。但这里需要注意一下。我们刚才给大家说的是在这里对吧？在这里schedule了会写入到我们的pax OS数据库中，那在这里呢，做了一些更改，什么更改呢？就是schedule了，把任务交给我们的IPSOIPSSO，再去负责把这个请求写入到etcd。也就意味着schedule并不会跟我们的ECD直接交互。需要注意一下。好。那在这里呢，还会有一个RC，那我们把它叫做控制器。他们就是维护我们的。副本的数目呢，或叫做我们的期望值的，那举个例子，我想让这个容器运行几个副本对吧，那就是由它去控制的，一旦他的副本数不满足我的期望值了，那这个RC呢，要负责把这个副本数。
06:15
改写到我们的期望值，或叫申请到我们的期望值，也就是创建对应的pod或删除对应的pod。需要注意一下。那IPSSO呢，就是我们的主服务器里面最后一个组件了，对吧，那它呢，讲白来说就是我们一切的服务的访问的入口。你会发现schedule需要跟我们IPSO交互，我们的RC需要跟我IPSO交互库CTM呢，是我们的命令行管理工具，它也需要跟我们的IPSSO进行交互，Web UI呢，也需要跟IPSSO进行交互，包括etcd。所以你会发现这里的IPO非常繁忙的。对吧？那为了减轻它的压力呢？每个组件其实还可以在本地生成一定的缓存，并不需要每一件事情都到IPSO去申请。
07:05
需要注意一下。好，那IPSO在机械来请求以后呢，会去操作etcd，那etcd在我们的cus集群里呢，就比较类似于在这里的pax OS这么一个建职队的系统了。那etcd呢？是cars公司开源的这么一个项目，采用构语言编写。建筑队数据库。那在这里呢，起到了整个库布拉集群的这么一个持久化的方案。并且etcd还有一些东西需要给大家讲一下，我们可以看这么几张图，第一个，Etcd官方将它定位一个可信赖的分布式存储服务。那这里说明一下什么叫可信赖。那为了官方让这个所谓的ET能够持久化的话，不会造成单节故障，所以它天生支持集运化，并不需要其他的组件参与进来，它就能实现自己的集群化方案。
08:07
需要注意一下，它不像我们的MYSQL，对吧？如果你想实现一个读写分离的话，那还需要进入到阿米巴等一些中间键，在这里不需要本身可以完成。好，分布式键值存储服务也就意味着可以扩容缩，非常方便，对吧，键值存储KV结构需要注意一下，好。那。协助我们分布式集群正常运转。这里正常运转的含义就是保存我们的整个分布式集群的需要持久化的配置文件配置信息。那一旦我们集群死亡以后，可以借助到edcd里面的一些信息进行所谓的数据恢复，那这就是edcd在我们的库集群的一个定位。好，那还有需要注意一下，在我们的库的集群中，我们会使用etcd作为持续化方案，但对于etcd来说，它的存储有两个版本，一个是VR版，一个是V3版。
09:05
这两个版本是我们还在用的。VR版会把所有的数据全部写入到我们的内存中，V3版会引入一个本地的券的持久化操作。也就意味着关机以后并不会造成数据损坏，会从我们的本地磁盘进行恢复。那理论上我们是不是应该选择V3版，因为这样不会造成数据丢失对吧？但需要注意一下一点，一一版，包括之前它自带的ETC。是没有V3版的，也就那时候还不支持V3版。需要注意一下，那我们现在安装的已经是1.15.1的最新稳定版了，所以这个问题是不需要我们去思考的了，那万一你的集群是一个非常古老的集群对吧？那还在使用1.11版之前的版本，那你就需要注意一下对etcd进行我们的备份操作了。
10:00
需要注意一下。
我来说两句