张鹏，腾讯云容器产品工程师，拥有多年云原生项目开发落地经验。目前主要负责腾讯云 TKE 云原生 AI 产品的开发工作。
谢远东，腾讯高级工程师，Kubeflow Member、Fluid（CNCF Sandbox） 核心开发者，负责腾讯云 TKE 在 AI 场景的研发和支持工作。
概述随着 Kubernetes 的日趋成熟，越来越多的公司、企业开始使用 K8s 来构建自己的云原生平台，基于 kubernetes 良好的扩展性以及成熟稳定的架构，你可以快速部署并管理自己的云原生应用。
目前我们也在基于 kubernetes 打造一个云原生 AI 平台（我们称它为：SKAI），该平台具备极致弹性、多云兼容性、高易用、可观测性、可复现性的特点，旨在利用云原生的思想和技术，为 AI 场景的数据处理、模型训练、模型上线推理等需求构建弹性可扩展的系统架构，从而提升资源利用率。
为了使我们的平台更加的云原生，我们没有选择常用的 web 框架来构建 API 服务，而是使用 kubernetes 扩展来构建整个平台，这样使我们的平台能更好的和 kubernetes 融合，可以无缝适配任何基于 k8s 的多云混合云环境。
为什么选择 Aggregated APIServer？ 选择独立 API 还是 Aggregated APIServer ？尽管使用 gin、go-restful 等 go 语言 web 框架可以轻易地构建出一个稳定的 API 接口服务，但以 kubernetes 原生的方式构建 API 接口服务还是有很多优势，例如:
能利用 kubernetes 原生的认证、授权、准入等机制，有更高的开发效率;
能更好的和 K8s 系统融合，借助 K8s 生态更快的推广自己的产品，方便用户上手;
借助于 K8s 成熟的 API 工具及规范，构建出的 API 接口更加规范整齐;
但是在很多场景下，我们还是不能确定到底使用聚合 API（Aggregated APIServer）还是独立 API 来构建我们的服务，官方为我们提供了两种选择的对比；如果你不能确定使用聚合 API 还是独立 API，下面的表格或许对你有帮助:
考虑 API 聚合的情况 优选独立 API 的情况你在开发新的 API 你已经有一个提供 API 服务的程序并且工作良好
你希望可以是使用 kubectl 来读写你的新资源类别 不要求 kubectl 支持
你希望在 Kubernetes UI （如仪表板）中和其他内置类别一起查看你的新资源类别 不需要 Kubernetes UI 支持
你希望复用 你不需要这类特性
你有意愿取接受 Kubernetes 对 REST 资源路径所作的格式限制，例如 API 组和名字空间。（参阅 API 概述） 你需要使用一些特殊的 REST 路径以便与已经定义的 REST API 保持兼容
你的 API 是 你的 API 不符合模型
你的资源可以自然地界定为集群作用域或集群中某个名字空间作用域 集群作用域或名字空间作用域这种二分法很不合适；你需要对资源路径的细节进行控制
首先我们希望我们的 SKAI 平台能更好的和 k8s 结合，并且它是一个声明式的 API，尽可能的复用 Kubernets API 的特性，显然聚合 API 对我们来说更加适合。
选择 CRDs 还是 Aggregated APIServer？除了聚合 API，官方还提供了另一种方式以实现对标准 kubernetes API 接口的扩展：CRD（Custom Resource Definition ），能达到与聚合 API 基本一样的功能，而且更加易用，开发成本更小，但相较而言聚合 API 则更为灵活。针对这两种扩展方式如何选择，官方也提供了相应的参考。
通常，如果存在以下情况，CRD 可能更合适：
定制资源的字段不多；
你在组织内部使用该资源或者在一个小规模的开源项目中使用该资源，而不是在商业产品中使用； 聚合 API 可提供更多的高级 API 特性，也可对其他特性进行定制；例如，对存储层进行定制、对 protobuf 协议支持、对 logs、patch 等操作支持。
两种方式的核心区别是定义 api-resource 的方式不同。在 Aggregated APIServer 方式中，api-resource 是通过代码向 API 注册资源类型，而 Custom Resource 是直接通过 yaml 文件向 API 注册资源类型。
简单来说就是 CRD 是让 kube-apiserver 认识更多的对象类别（Kind），Aggregated APIServer 是构建自己的 APIServer 服务。虽然 CRD 更简单，但是缺少更多的灵活性，更详细的 CRDs 与 Aggregated API 的对比可参考。
对于我们而言，我们希望使用更多的高级 API 特性，例如 "logs" 或 "exec"，而不仅仅局限于 CRUD ，所以我们最终选择了 Aggregated APIServer 。
APIServer 扩展的基本原理