list-watch理解

 

kube-controller-manager（运行在Master），kube-scheduler（运行在 Master），kublete（运行在 Node）在启动后会一直watch APIServer发出来的事件。

kubectl创建rs时，会发送请求到api-server，api-server经过访问控制层、注册表层，将rs信息存储在etcd中。

然后etcd发送“已经创建了rs的事件”到api-server，kube-controller-manager监听到这个事件后，会比较rs的实际状态和想要达到的状态是否一致，不一致就尝试让它一致（compares the actual state with the desired, and attempts to converge the two），因为检查到rs还没有控制的pod，

所以kube-controller-manager发送创建pod的请求到api-server，api-server再次经过访问控制层、注册表层，将pod信息存储在etcd中。

然后etcd发送“已经创建了pod的事件”到api-server，（注意这里kube-controller-manager一直在list etcd中的rs，当发现rs控制的pod数量满足想要的数量后，就不做处理 ）

kube-scheduler监听到了“已经创建了pod的事件”，会比较pod的实际状态和想要达到的状态是否一致，因为检查到pod还未被调度，就发送调度的请求到api-server，api-server再次经过访问控制层、注册表层，将pod更新后信息存储在etcd中。

然后etcd发送“已经更新了pod的事件”到api-server，kubelet此时监听到了这个事件，就开始处理了。

 

PS：

APIServer 的架构从上到下分为四层：

API 层：主要以 REST 方式提供各种 API 接口，针对 Kubernetes 资源对象的 CRUD 和 Watch 等主要 API，还有健康检查、UI、日志、性能指标等运维监控相关的 API。

访问控制层：负责身份鉴权，核准用户对资源的访问权限，设置访问逻辑（Admission Control）。

注册表层：选择要访问的资源对象。PS：Kubernetes 把所有资源对象都保存在注册表（Registry）中，例如：Pod，Service，Deployment 等等。

etcd 数据库：保存创建副本的信息。用来持久化 Kubernetes 资源对象的 Key-Value 数据库。

当 kubectl 用 Create 命令建立 Pod 时，是通过 APIServer 中的 API 层调用对应的 RESTAPI 方法。

之后会进入权限控制层，通过 Authentication 获取调用者身份，Authorization 获取权限信息。

到了 Registry 层会从 CoreRegistry 资源中取出 1 个 Pod 作为要创建的 Kubernetes 资源对象。

然后将 Node，Pod 和 Container 信息保存在 etcd 中去。这里的 etcd 可以是一个集群，由于里面保存集群中各个 Node/Pod/Container 的信息，所以必要时需要备份，或者保证其可靠性。