Kubernetes API Aggregation在 Master 的 API Server 中启用 API 聚合功能注册自定义 APIService 资源实现和部署自定义的 API Serv

如需转载请标注内容地址为: https://wiki.shileizcc.com/confluence/display/KUB/Kube

• Kubernetes API Extension

Kubernetes API Extension

从 Kubernetes 1.7 版本开始，Kubernetes 引入扩展 API 资源的能力，使得开发人员在不修改 Kubernetes 核心代码的前提下可以对 Kubernetes API 进行扩展，仍然使用 Kubernetes 的语法对新增的 API 进行操作，这非常适用于在 Kubernetes 上通过其 API 实现其他功能（例如第三方性能指标采集器服务）或者测试实验性新特性（例如外部设备驱动）。

在 Kubernetes 中，所有对象都被抽象自定义某种资源对象，同时系统会为其设置一个 API 入口（API Endpoint），对资源对象的操作（如新增、删除、修改、查看等）都需要有通过 Master 的核心组件 API Server 调用资源对象的 API 来完成。与 API Server 的交互可以通过 kubectl 命令行工具或访问其 RESTful API 进行。每个 API 都可以设置多个版本，在不同的 API URL 路径下区分，例如 "/api/v1" 或 "/apis/extensions/v1neta1" 等。使用这种机制后，用户可以很方便地定义这些 API 资源对象（YAML 配置），并将其提交给 Kubernetes（调用 RESTful API），来完成对容器应用的各种管理工作。

Kubernetes 系统内置的 Pod、RC、Service、Config、Volume 等资源对象以及能够满足常见的容器应用管理要求，但如果用户希望将其自行开发的第三方系统纳入 Kubernetes，并使用 Kubernetes 的 API 对其自定义的功能或配置进行管理，就需要对 API 进行扩展了。目前 Kubernetes 提供了以下两种机制提供用户扩展 API。

（1）使用 CRD 机制：复用 Kubernetes 的 API Server，无需编写额外的 API Server。用户只需要定义 CRD，并且提供一个 CRD 控制器，就能通过 Kubernetes 的 API 管理自定义资源对象了，同时要求用户的 CRD 对象符合 API Server 的管理规范。

（2）使用 API 聚合机制：用户需要编写额外的 API Server，可以对资源进行更细粒度的控制（例如，如何在各 API 版本之间切换），要求用户自行处理对多个  API 版本的支持。

Kubernetes CRD

Kubernetes API Aggregation