1.Kubernetes API Server概述

    从整体上来看的话，Kubernetes API Server的核心功能就是提供Kubernetes各类资源对象（pod， RC，Deployment等）的增删改查以及watch等HTTP REST接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。除此之外，它还是集群管理的API入口，是资源配额控制的入口，提供了完备的集群安全机制。

    kubernetes API Server通过一个名为kube-apiserver的进程提供服务，该进程运行在master节点上。默认情况下，kube-apiserver进程在本机的8080端口（对应参数--insecure-port）提供REST服务，我们也可以同时启动HTTPS安全端口（--secure-port=6443）来启动安全机制，加强REST API访问的安全性。

2.API Server架构解析

    API Server架构从上到下可以分为以下几层：

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

        2.访问控制层：放客户端访问API接口时，访问控制层负责对用户身份鉴权，验明用户身份，核准用户对Kubernetes资源对象的访问权限，然后根据配置的各种资源访问许可逻辑（Admission Control），判断是否允许访问

        3.注册表层：Kubernetes把所有资源对象都保存在注册表（Registry）中，针对注册表中的各种资源对象都定义了资源对象的类型、如何创建资源对象、如何转换资源的不同版本，以及如何将资源编码和解码为JSON或ProtoBuf格式进行存储

        4.etcd数据库：用于持久化存储Kubernetes资源对象的KV数据库。etcd的Watch API接口对于API Server来说至关重要，因为通过这个接口，API Server创新性的设计了List-Watch这种高性能的资源对象实时同步机制，使Kubernetes可以管理超大规模的集群，及时响应和快速处理集群中的各种事件

下面我们在来看看pod调度过程中的List-Watch机制：

        首先，借助etcd提供的Watch API接口，API Server可以监听（Watch）在etcd上发生的数据操作事件，比如Pod创建事件、更新事件、删除事件等，在这些事件发生后，etcd会及时通知API Server。在图中红框框1，表示这个过程：当一个ReplicaSet对象被创建并保存到etcd中后，etcd会立即发送一个create事件给API Server，后续pod的创建都一样

      然后，为了让Kubernetes中的其他组件在不访问底层etcd数据库的情况下，也能及时获取资源对象的变化事件，API Server模仿etcd的Watch API接口提供了自己的Watch接口，这样一来，这些组件就能近乎实时地获取自己感兴趣的任意资源对象的相关事件通知。同种红框框2中3个List-Watch表明了这个过程。

        最后，Kubernetes List-Watch用于实现数据同步的代码逻辑 。客户端首先调用API Server的 List接口获取相关资源对象的全量数据并将其缓存到内存中，然后启动对应资源对象的Watch协程，在接收到watch事件后，再根据事件的类型（比如新增、修改或删除）对内存中的全量资源对象列表做出相应的同步修改 。 从实现上来看 ，这是一种全益结合增最的、高性能的 、 近乎实时的数据同步方式。

3.集群功能模块之间的通信

        从上面这个kubernetes结构图中，我们可以看到Kubernetes API Server 作为集群的核心， 负责集群各功能模块之间的通信 。 集群内的各个功能模块通过 API Server 将信息存入 etcd 中 ，当需要获取和操作这些数据时，则通过 API Server 提供的 REST 接口 （用 GET 、 LIST 或 WATCH 方法 ）来实现，从而实现各模块之间的信息交互 。

        常见的一个交互场景是 kubelet 进程与 API Server 的交互 。每个 Node 上的 kubelet 每隔一个时间周期就会调用一次 API Server 的 REST 接口报告自 身状态， API Server 在接收到这些信息后，会将节点状态信息更新到 etcd 中 。 此外， kubelet 也通过 API Server 的 Watch接口监听 Pod 信息，如果监听到新的 Pod 副本被调度绑定到本节点，则执行 Pod 对应的容器创建和启动逻辑 ；如果监听到 Pod 对象被删除，则删除本节点上相应的 Pod 容骈；如果监听到修改 Pod 的信息， kubelet 就会相应地修改本节点的 Po d 容器 。

        另 一个交互场景是 kube-controller-manager 进程与 API Server 的交互 。 kube-controllermanager 中的 Node Controller 模块通过 AP! Server 提供的 Watch 接口 实时监控 No de 的 信息，并做相应的处理。

        还有一个比较重要的交互场景是 kube-scheduler 与 API Server 的交互 。 Scheduler 在通过 API Server 的 Watch 接口监听到新建 Pod 副本的信息后，会检索所有符合该 Pod 要求的Node 列表，开始执行 Pod 调度逻辑，在调度成功后将 Pod 绑定到目标节点上 。

        为了缓解集群各模块对 API Server 的访问压力，各功能模块都采用了缓存机制来缓存数据 。 各功能模块定时从 API Server 上获取指定的资源对象信息（通过 List-Watch 方法），然后将这些信息保存到本地缓存中，功能模块在某些情况下不直接访问 API Server, 而是通过访问缓存数据来间接访问 API Server 。