1. Borg 组件说明

1.1. 调度器架构图

高可用集群的主节点一般是奇数个，这样就可以达到一种不公平的状态，可以选出一个领导节点。防止偶数个，出现大家都是一样的票数，这样的情况，没法选出老大。

1.2. 流程解析

来自客户端的请求，抵达 BorgMaster，这个相当于整个 Borg 系统的大脑，负责管理控制。真正干实事的就是下面的 Borglet，但是并不是直接由 BorgMaster 指挥 Borglet 来干活。而是通过调度器 scheduler 来控制，scheduler 通过调度到具体哪个 Borglet 来干活，其将需要的数据写入到 Paxos 键值对数据库中，然后 Borglet 来监听这个数据库中的数据，如果发现了，有数据自己的数据需要处理，那么它就会主动去消费处理。

2. K8S 结构说明

2.1. 调度器架构图

• api server: 所有服务访问统一入口；
• replication controller: 维持副本期望数量；
• scheduler: 负责介绍任务，选择合适的节点进行分配任务；
• etcd: 键值对数据库，存储 K8S 集群所有重要信息（持久化）；
• kubelet: 直接跟容器引擎交互实现容器的生命周期管理；
• kube-proxy: 负责写入规则至 iptables、ipvs 实现服务映射访问的；
• coredns: 可以为集群中的 svc 创建一个域名 IP 的对应关系映射；
• dashboard: 给 K8S 集群提供一个 B/S 结构访问体系；
• ingress controller: 官方只能实现四层代理，ingress 可以实现七层代理；
• federation: 提供一个可以跨集群中心多K8S统一管理中心；
• prometheus: 提供 K8S 集群的监控能力；
• ELK: 提供 K8S 集群日志统一分析介入平台；

2.2. 流程解析

所有的交互都是会通过与 api server 进行交互。无论是 k8s 的客户端、前端 UI、调度器、备份控制器，还是可信赖的分布式键值对数据库 etcd，均通过与其进行交互。但是需要注意的是，scheduler 和 replication controller 其实与 api server 之间是可以加一层缓存的，不需要每次都去 api server 进行交互。从上述可以看出，我们的 api server 太忙了。

ectd 的官方将它定位成一个可信赖的分布式键值存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转。
注意：推荐在 Kubernetes 集群中使用 Etcd v3，v2 版本已在 Kubernetes v1.11 中弃用。

2.3. ETCD 数据库

2.3.1. v2 对比 v3

如下图所示，我们的 ETCD 数据库在 v2 版本的时候，是基于内存设计的，而 v3 版本是基于数据库设计。基于内存的话，如果断电的话，很可能引起数据丢失。但是我们的数据库中保存的话，就能持久化。

2.3.2. ETCD 架构图

如下图所示，ETCD 是通过 HTTP 协议进行数据传输的。
所有的指令都是包含在 Raft 中，通过临时备份 + 快照备份两种方式来进行指令临时日志备份，并且还会持久化保存到 Store 中。

这里临时备份是小备份，等小备份到一定的时间，就会进行一次完整地备份操作。这样做的目的就是为了我们数据还原的时候，不至于那么慢，我们可以快速的回滚。