导言
好，接着呢我们去进行第三部分的讲解，也就是我们的组件说明，那整个k8s的框架还是非常庞大的，对吧？那我们要对它有一个非常高的了解以后，我们再去安装我们的k8s才会有一个比较好的效果。好，那对于我们的k8s来说，你可以理解为它的前身是我们的博格系统，对吧？采用go语言的编译版或叫重构版。好，那就意味着如果我们先去了解我们的博格系统，再转而去看我们的 k8s，整个调度系统的话，那可能会帮助我们更加强一部分了解，对吧？
博格的架构
好，那我们首先我们看一下我们的博格的架构，那这张图呢就是显示我们的博格的谷歌的博格的这么一个调度器的这么一个架构，那首先你会发现这里有一堆的borgmaster和borglet对吧？由两部分去组成。
好，那borgmaster就是专门去负责这些所谓的请求的分发的，你可以理解为它是整个集群大脑对吧？那真正工作的节点其实是我们的borglet，也就如果有对应的容器要运行的话，比如有一些计算能力对吧？它是通过我们的borglet去给他提供的，需要大家注意一下，在这里他给他去提供对吧？
好，那为了防止我们的borgmaster由于单节点故障，所以你会发现这里有很多的副本，并且这个副本数目其实是有讲究的，需要注意一下。
你仔细数一下12345,5个，那我问大家一个问题，可以是两个吗？可以是4个，嘛可以是6个。那这里为什么要这样去给大家描述？因为对于我们的高可用集群来说，一般我们要满足这么一个需求，就是它最好是13579，听明白我意思吗？会叫3579，最好大于一对，因为一个节点是不是就产生我们单节点故障了？那为什么要这样选择？防止有一天出现，比如你两票我两票，那咱俩谁是老大呢？那如果有三个人同时过来投票的话，肯定不会出现这种状态。
能理解我有意思吗？所以对于我们的高可用集群来说，它的调度器或它的高可用节点最好保持在三个以上，基数也就3579比较合适。好，这个是需要我们特别注意的。
集中访问方式
并且你会发现这里有这么集中访问方式对吧？那第一种是通过我们的浏览器，命令行，以及我们的一些文件的读取，那在我们的k8s里呢也会有这么几种方式进行所谓的整个调度集群的管理。好，那这种三种方式会被接入到我们的borgmaster，他去请求以后再去做分发，那分发这个概念很重要对吧？
也就请求过来以后，我要把这个任务交给谁去处理。
scheduler
那假设我现在就是一个包工头，对吧？那有一些任务过来了，比如唉把什么钢筋扛到几楼，把什么砖扛到几楼对吧？那我要去安排一些我的工人去干这件事情，那对于我来说呢就是这么一个组件。scheduler？scheduler，也就是我们的调度器，那所有的任务在到这里以后被会被分发分发至不同的节点去运行。当然这里并不是我们的 schedule去跟我们后面的borglet交互，而是schedule把数据写入至paxos，这是我们谷歌的这么一个键值对的这么一个数据库，他去存储，并且borglet呢会实时的在这里paxos这么一个数据库里进行监听，如果发现，唉有我的请求了，那我会把这个请求取出来，又叫消费对吧？
去处理这些任务，达到这么一个流程目的。
好，那这个呢就是我们的博格系统的这么一个示意图了，那也意味着对于我们的k8s它的更新版或叫精良版，对吧？好，那它是不是应该也是跟它类似的
k8s
所以接下来我们看这么一张图，这是我们的k8s的这么一个架构图，里面的一些重要组件，我也画在这里了，对吧？那在这里呢它会分为 CS结构，一个是我们的 master服务器，
一个是我们的 node的节点
那也就意味着在这里它跟我们的 borgmaster一样，它也是我们的一个领导者，对吧？
也是我们的领导者头头。
那在这里的所有的note呢就是我们的工人了，执行者。那我们先看一下对于我们的领导者里面他有哪些东西。
schedule
第一个schedule，虽然是一个调度器，任务过来以后，我还需要通过schedule把这些任务分散至不同的note里，但这里需要注意一下，我们刚才给大家说的是在博格系统，在这里schedule会写入到我们的pasos数据库中，那在这里呢做了一些更改，什么更改呢就是schedule把任务交给我们的api server，api server再去负责把这个请求写入到etcd，也就意味着schedule，并不会跟我们的etcd直接交互，需要注意一下。
RC
那在这里呢还会有一个RC（replication controller）那我们把它叫做控制器，他们就是维护我们的副本的数目呢或叫做我们的期望值的。那举个例子，我想让这个容器运行几个副本对吧？那就是由他去控制的，一旦他的副本数不满足我的期望值了，那这个 RC呢要负责把这个副本数改写到我们的期望值，或叫申请到我们的期望值，也就是创建对应的pod的或删除对应的pod.需要注意一下。
api server
好，那 api server就是我们的主服务器里面最后一个组建了对吧？那它呢讲白来说就是我们一切的服务的访问的入口，你会发现schedule，需要跟我们api server交互交互，我们的RC需要跟api server交互，kubectl呢是我们的命令行管理工具，它也需要跟我们的api server会进行交互，web UI呢也需要跟api server进行交互，包括etcd所以你会发现这里的api server是非常繁忙的，对吧？
那为了减轻他的压力，每个组件其实还可以在本地生成一定的缓存，并不需要每件事情都到api server去申请，需要注意一下。
etcd
api server我在进行了请求以后呢会去操作 etcd。 EtCT在我们的k8s集群里呢就比较类似于在这里的paxos这么一个键值对系统了。那 Etcd呢是Carlos公司开源的这么一个项目，采用go语言编写，键值对数据库，那在这里呢起到了整个k8s集群的这么一个持久化的方案。并且etcd还有一些东西需要给大家讲一下，我们可以看这么几张图，第一个 epc官方将它定位一个可信赖的分布式键值对存储服务。
那这里说说明一下什么叫可信赖。那为了官方让这个所谓的etct能够持久化的话，不会造成单节点故障，所以它天生支持集群化，并不需要其他的组件参与进来，它就能实现自己的集群化方案。需要注意一下，它不像我们mysql对吧？如果你想实现一个读写分离的话，那还需要介入到阿米巴等一些中间件，在这里不需要，本身可以完成。分布式键值存储服务也就意味着可以扩容说非常方便对吧？键值存储，kv结构需要注意一下，好。协助我们分布式集群正常运转，这里的正常运转的含义就是保存我们的整个分布式集群的需要持久化的配置文件配置信息，那一旦我们集群死亡以后，可以借助到etcd里面的一些信息进行所谓的数据恢复，那这就是edcd在我们的k8s集群的一个定位。
还有需要注意一下，在我们的k8s的集群中，我们会使用etcd作为持续化方案，但对于etcd来说，它的存储有两个版本，一个是VR版，一个是v三版，这两个版本是我们还在用的，VR版会把所有的数据全部写入到我们的内存中，v三版会引入一个本地的券的持久化操作，也就意味着关机以后并不会造成数据损坏，会从我们的本地磁盘进行恢复。那理论上我们是不是应该选择v三版，因为这样不会造成数据丢失对吧？但需要注意一下
1.11版包括之前他自带的etcd是没有 v三版的，也就那时候还不支持v三版，需要注意一下，那我们现在安装的已经是1.15.1的最新稳定版了，所以这个问题是不需要我们去思考的了。
那万一你的集群是一个非常古老的集群，对吧？那还在使用1.11版之前的版本，那你就需要注意一下对etcd进行我们的备份操作，需要注意一下。
标签：server,说明,api,集群,etcd,组件,硅谷,k8s,我们 From： https://www.cnblogs.com/cj8357475/p/17097710.html