45 K8S 之系统扩展 CRD/ 自定义 API Server

扩展 Kubernetes API 的常用方式有 3 种：使用 CRD 自定义资源类型、开发自定义的 API Server 并聚合至主 API Server，以及定制扩展 API Server 源码。其中，CRD 最为易用但限制颇多，自定义 API Server 更富于弹性但代码工作量偏大，仅在必须添加新的核心类型才能确保专用的 Kubernetes 集群功能正常，才应该定制系统源码。

CRD 就像是由用户为 Kubernetes 存储系统提供的自定义数据模式，用户可基于这些模式实例化数据项，且从用户的角度来看，它们与内置的数据模式几乎没有区别。CRD 并非用来取代 Kubernetes 的原生资源类型，而是作为一种更为灵活、高级、简单易用的自定义 API 资源的补充方式。

OAS（OpenAPI Specification）规范为 RESTful API 提供了一个语言无关的标准接口，以帮助计算机或人无须阅读源代码即可发现和理解服务的功能。CRD 使用它来明确自定义资源的规范，具体的使用格式请参考 Swagger 站点上的文档，相关主页地址为https://swagger.io/specification/。

自定义 API Server 完全可以独立运行，客户端通过其服务端点即可直接进行访问，但最为方便的方式是将它与主 API Server（kube-apiserver）聚合在一起，这样既能使得构建出的 API 接口更加规范整齐，从而利用 Kubernetes 原生的认证、授权和准入控制机制，集群中的多个 API Server 看起来好像是由单个服务器提供服务，而且无须特殊逻辑来发现不同的 API Server。

APIService 资源类型的最初设计目标是将庞大的主 API Server 分解成多个小型但彼此独立的单元，但它也支持将任何遵循 Kubernetes API 接口设计规范的自定义 APIServer 聚合进主 API Server 中。APIService 是标准的 API 资源类型，它隶属于 apiregistration.k8s.io 资源群组。

Kubernetes 系统内置了许多控制器，例如 NodeController、Deployment、DaemonSet 和 ServiceController 等，它们打包成单个二进制程序 kube-controller-manager 并统一运行在同一个守护进程中。结合 Kubernetes 的声明式 API，这些控制器基本都遵循同一种机制完成资源管理操作，该处理机制通常可由声明式 API、异步处理模式和水平触发 3 种特性进行描述。

声明式 API：用户定义期望的状态而非要执行的特定操作，具体的业务逻辑由控制器通过相应的业务代码完成。

异步处理：客户端的请求在 API Server 存储完成即返回成功信息，而无须等待控制器运行调谐循环。

水平触发（level trigger）：同一对象有多次变动事件待处理时，控制器仅需要处理其最新一次变动，即仅依赖当前状态。

边缘触发（edge trigger）：该触发模式中，系统既依赖资源的当前状态，也依赖过去的状态；若系统错过了某个事件（即“边缘”），则必须重新执行该事件才能恢复系统。

控制器主要包含 Informer/SharedInformer 和 Workqueue 两个重要组件，前者负责注册监视资源对象当前状态的变动，并将相应事件发送至后者，最后由控制器的 worker 从 Workqueue 中取出事件交给控制器中业务逻辑相关的代码进行处理。

自定义控制器实现自定义资源管理行为的最佳方法同样是遵循此类控制器模式进行程序开发，Kubernetes 为此提供了一个专用的开发库 client-go。目前，该开发库中的大部分开发接口都是基于 Go 语言实现，Informer 和 Workqueue 相关代码分别位于客户端库的 client-go/go/tools/cache 和 client-go/util/workqueue 目录中。