K8s的前身可以理解为Borg系统:

BorgMaster：负责请求分发，整个集群的大脑，真正工作的节点是Borglet,有对应的容器要运行的话，是Borglet提供的计算；
为了防止单节点故障，BorgMaster有多个副本（高可用节点 >= 3 的奇数）
scheduler：调度器，将请求分发给不同的节点；负责将请求写入Paxos,Borglet会对Paxos进行实时监听，Borglet发现有自己的请求了，就会去处理
如图：K8S架构图中 1 对应 Borg系统的 2，K8S架构图中 3 （node集群）对应 Borg系统的 4（Borglet）
etcd(go语言编写键值对数据库) 相当于 Borg系统的Paxos
详细说下K8S架构图：
replication controller :缩写 RC ，负责维护期望的副本数目
Scheduler：负责把任务交给api server，api server负责把任务写入etcd；选择合适的节点进行分配任务
api server ：所有服务访问统一入口，从K8S架构图可以得出： RC、scheduler、etcd、webUI都需要与 api server交互，其实每个组件都有自己的缓存，为了防止api server工作量太大
kubectl：命令行管理工具
etcd：键值对数据库 ，负责整个K8S集群重要信息的持久化；etcd 的官方将它定位成一个可信赖的分布式键值存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转（如何协助的呢？保存我们集群的需要持久化的配置文件，集群死亡后可以借助这些文件进行数据恢复）
可信赖：etcd天生支持集群化，不需要其他组件就能实现集群化，防止单点故障影响持久化
etcd内部架构图：
与K8S相同都是通过HTTP协议进行CLS的开发，HTTP协议天生支持很多操作方式：put、get、授权认证等等；TCP的话需要额外的开发
Raft:读写信息都在这儿，实时把日志和数据持久化到磁盘（Store）
WAL：预写日志；会有一个大版本日志，有小更改生成子日志，到达一定时间会合并到大版本日志（完整备份消耗太大、定时进行完整备份： 增量备份太多恢复太费时）
kubelet: 会与CRI（container runtime interface）交互，例如与docker交互，操作docker创建对应的容器，会维持容器的生命周期
Kube-proxy：负责写入规则至 IPTABLES、IPVS 实现服务映射访问的

其他插件：
COREDNS：可以为集群中的SVC创建一个域名IP的对应关系解析
DASHBOARD：给 K8S 集群提供一个 B/S 结构访问体系
INGRESS CONTROLLER：官方只能实现四层代理，INGRESS 可以实现七层代理
FEDERATION：提供一个可以跨集群中心多K8S统一管理功能
PROMETHEUS：提供K8S集群的监控能力
ELK：提供 K8S 集群日志统一分析介入平台