Kubernetes API Server解析

概述

Kubernetes API Server的核心功能是提供Kubernetes各类资源对象（如Pod、 RC、 Service等） 的增、 删、 改、 查及Watch等HTTP Rest接口， 成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。 除此之外它还是：集群管理的API入口 、资源配额控制的入口 、为集群提供了完备的集群安全机制 。

架构

img

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

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

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

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

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

List-Watch机制

img

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

资源对象的internal版本

API Server针对每种资源对象都引入了一个相对不变的internal版本， 每个版本只要支持转换为internal版本， 就能够与其他版本进行间接转换。

img

Kubernetes Proxy API接口

Kubernetes Proxy API接口， 这类接口的作用是代理REST请求， 即Kubernetes API Server把收到的REST请求转发到某个Node上的kubelet守护进程的REST端口， 由该kubelet进程负责响应。可以提供节点上Pod与Service的相关信息 。

需要说明的是： 这里获取的Pod的信息数据来自Node而非etcd数据库， 所以两者可能在某些时间点有所偏差。