问题描述

假设你有一个自定义的工作负荷，但没有任何已有的资源（比如，部署、job 或 Statefulset）适合描述这个工作负荷。如何利用代表该工作负荷的新资源扩展 Kubernetes API，且可以像往常一样使用 kubectl？

解决方案

Extending the API Using Custom Resource Definitions (CRDs)

可以使用自定义资源定义（Custom Resource Definition，CRD）

假设需要定义一个 Function 类型的自定义资源。它代表了短期运行的、像 Job 一样的资源，类似于 AWS Lambda 提供的功能，也就是所谓的“功能即服务”（Function–Service，as，它还有个极具误导性的名字“无服务器体系”）
关于在 Kubernetes 上运行适合生产环境的 FaaS 解决方案，请参阅 14.7 节；

首先，在一个名为 functions–crd.yaml 的清单文件中定义该 CRD:

然后，通知 API 服务器这个新的 CRD（注册需要几分钟的时间）:

现在自定义的资源 Function 已经定义好了并且服务器也知道了它的存在，接下来可以使用一个名为 myfaas.yaml 的清单文件实例化这个资源，如下所示:

照例还需创建 Function myfaas 的资源:

现在只需通过访问 API 服务器就可以找到 CRD。例如，使用 kubectl1 proxy 可以从本地访问 API 服务器，还可以查询键空间(比如下例中查询了 example.com/v1)：

这里可以看到资源列表以及允许的操作；

如果想要删除自定义的资源实例 myfaas，那么只需运行删除命令:

正如你所见，创建一个 CRD 很直观。从终端用户的角度看来，CRD 代表一个稳定的 API，几乎与 pod 或 job 等内置的资源没有什么区别。所有常见的命令，比如 kubectl get 和 kubectl delete，也可以照常工作；

然而，创建一个 CRD 其实只是完全扩展该 Kubernetes API 所必需的工作的一小半。CRD 仅仅实现了通过 API 服务在 etcd 中存储数据或获取数据。还需要编写自定义的控制器，用于解释自定义数据表达用户的意图和建立控制循环对比当前的状态和声明的状态，以及调和二者；

在 v1.7 之前，CRD 被称作第三方资源（third-party resources，tprs）如果你手头有一个 TPR，强烈建议现在就移植它；

CRD 主要的局限性在于（因此在某些场合，你可能希望使用用户的 API 服务器）:

# 相关文章

使用 CRD 扩展 crd  kubernetes api
https: kubernetesi. iol docs/tasks/access-(htts:kubernetesioldocs/tasks/access-kubernetes-apilextend-api-custom-resource-definitionsh)

Stefan Schimanski F Michael Hausenblas 的博文“深入 Kubernetes:API 服务器之三 HR&&2=
(https: /blog.openshift. com/kubernetes- part-3a/)

Aaron Levy KubeCon2017 大会上的演讲“编写自定的控制器:扩展集群的功能 HIhRE(
https: //www.youtube.com/watch?v=_BugPMIXfpE).

tu  nguyen 的文章“深入 Kubernetes 控制器”
(htpsengineerng bitnami. com/articlesla-deep-dive-into-kubernetes-controllers. html

Yaron Haviv 的文章“使用自定义资源扩展 Kubernetes1.7”
https: //(https: thenewstack.iolextend-kubernetes-1-7-custom-resources/

相关链接

Extend the Kubernetes API with CustomResourceDefinitions
Building your own kubernetes CRDs