# 扩展 Kubernetes

Kubernetes 提供的大多是相对于更底层、更通用的概念对象，在使用的过程中，会有更高层次的对象不断涌现⎡例如，提供一个网站对象，该对象底层依赖 Service、Pod、Deployment 等⎦，我们希望通过部署该高层次的新对象，可以直接实现所需的业务功能，所幸 Kubernetes 具有高度的可扩展性：

1. 用户可以通过 [CRD (CustomResourceDefinitions)](https://yangsijie151104.gitbook.io/k8s-note/kuo-zhan-kubernetes/14.-kuo-zhan-kubernetes/zi-ding-yi-crd-zi-yuan) 资源来自定义 API 对象；
2. 用户可以通过 Kubernetes 提供的 API 聚合特性，通过 [APIService 资源](https://yangsijie151104.gitbook.io/k8s-note/kuo-zhan-kubernetes/14.-kuo-zhan-kubernetes/apiservice-zi-yuan) 自定义 API 服务器，处理用户的自定义请求；

两种方案对比：

| CRD                                                | APIService                                         |
| -------------------------------------------------- | -------------------------------------------------- |
| 更简单                                                | 更灵活                                                |
| 不需要编程，用户可以使用任何语言开发自定义资源的控制器                        | 需要使用 Go 语言编程并构建容器镜像，部署于 Kubernetes 集群中             |
| 无需运行其他 Service，对自定义资源对象的操作交由 API 服务器处理             | 需要单独构建 Service，用户请求上游来自 API 服务器，下游交付至自定义 API 服务器   |
| 创建 CRD 后将不再提供支持，自定义资源对象的更新中的所有错误修复均由 Kubernetes 处理 | 可能需要定期从上游获取错误修复，并重建和更新自定义 API 服务器                  |
| 无需处理您的API的多个版本；例如，当您控制此资源的客户端时，可以与API同步升级。         | 可以自己定义多版本 API，因为自定义 APIService 会提供一个属于自定义资源的特定 URL |