Aggregated APIServer 构建云原生应用最佳实践

作者

张鹏，腾讯云容器产品工程师，拥有多年云原生项目开发落地经验。目前主要负责腾讯云 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 API 支持特性	你不需要这类特性
你有意愿取接受 Kubernetes 对 REST 资源路径所作的格式限制，例如 API 组和名字空间。（参阅 API 概述）	你需要使用一些特殊的 REST 路径以便与已经定义的 REST API 保持兼容
你的 API 是声明