K8S的架构

k8s 整体采用的是主从架构 master 和 worker node

maser:集群大脑负责管理，调度，控制

worker node: 运行实际业务员容器的节点

maser 又分为以下组件

1. api-service ：所有才做都通过它实现，与etcd 交互 。同时提供watch 监控
2. etcd ：数据库，记录存储所有数据，状态
3. kube-scheduler:负责pod调度，绑定node
4. controller-manage: 控制器循环，维持节点期望状态

总结

apiservice 负责操作etcd ，etcd 负责记录数据变化，sechdule 查询etcd 并负责绑定pod和node，controller-manger 循环监控各个pod的状态，如果与预期不符就删除，重建pod。这个给流程采用的是观察者模式，各个组件之间完全解耦。

疑问

为什么 apiservice 调用etcd 还说 2个是解耦？

因为他们之间没有强依赖，哪天不想用etcd了，换成mysql 一样是不需要动apiservice的 。就像springData 你用mysql或是mongo 都没有影响。

这种是典型的适配器模式。

apiservice 还用到了外观模式：不管scheduler 还是 controller 都只是调用 apiservice， 不用关系api的实现【权限校验，写入etcd】等。

注意

etcd 生产部署的时候一定要和master 分开，至少是隔离开。最好独占SSD 硬盘

watch

k8s 架构的核心 ，http实现的长链接

controller ，scheduler，kubelet 都向apiservice发起 watch请求，建立了长链接

1. scheduler / controller / kubelet
   向 apiserver 发起 WATCH 请求（长连接）

2. apiserver 接收，保持连接不断开

3. apiserver 内部监听 etcd 变化

4. 一旦 etcd 数据变了
   apiserver 立刻把事件通过长连接 推 给监听者

5. 监听者收到事件，做自己的业务逻辑
   （调度、重建Pod、运行容器...）

apiservice 内部监听etcd 变化

etcd 设计的时候就自带watch 而apiservice有etcd的客户端，所以apiservice能够监听etcd的变化。

这个etcd和apiservice的watch 与 apiservice 提供给其他组件的watch 不一样哈

思考

那k8s 就只能用etcd了吗？ 不是 ，还有以下选择

etcd（官方默认）

TiKV（分布式 KV，支持 Watch）

ZooKeeper（支持 Watch）

Consul（支持 Watch）