【K8s 精选】使用 CRD 的场景分析
1 CRD 简介
资源（Resource） 是 Kubernetes API 中的一个端点， 其中存储的是某个类别的 API 对象 的一个集合。 例如 Deployment 资源包含一组 Pod 对象。
CRD 本身是一种 Kubernetes 内置的资源类型，即自定义资源的定义，用于描述用户定义的资源是什么样子。CRD 的相关概念：① 从 Kubernetes 的用户角度来看，所有东西都叫资源 Resource，就是 Yaml 里的字段 Kind 的内容，例如 Service、Deployment 等。② 除了常见内置资源之外，Kubernetes 允许用户自定义资源 Custom Resource，而 CRD 表示自定义资源的定义。
2 使用 CRD 的场景分析
关键点：在创建新的 API 时，请考虑是 将你的 API 与 Kubernetes 集群 API 聚合起来 还是让你的 API 独立运行。
| API 聚合的情况 | 独立 API 的情况 |
|---|---|
| 希望可以是使用 kubectl 来读写你的新资源类别 | 不要求 kubectl 支持 |
| 希望在 Kubernetes UI 中和其他内置类别一起查看你的新资源类别 | 不需要 Kubernetes UI 支持 |
| 在开发新的 API | 已经有一个提供 API 服务的程序并且工作良好 |
| 你的资源可以自然地界定为集群作用域或集群中某个名字空间作用域 | 集群作用域或名字空间作用域这种二分法很不合适，需要对资源路径的细节进行控制 |
声明式 API 的特点：
● API 包含相对而言为数不多的、尺寸较小的对象（资源）
● 对象定义了应用或者基础设施的配置信息
● 对象的主要操作是 CRUD 风格的（创建、读取、更新和删除）
命令式 API 的特点：
● 客户端发出“做这个操作”的指令，之后在该操作结束时获得同步/异步响应
● 直接存储大量数据；例如每个对象几 kB，或者存储上千个对象
● 在对象上执行的常规操作并非 CRUD 风格
● API 不太容易用对象来建模
3 案例分析 - 使用 Configmap 还是 CRD
如果满足一下条件之一，应该使用 Configmap：
● 存在一个已有的配置文件，提供 Pod 内的程序运行，例如 flink-conf.yaml、pom.xml 等；
● 把整个配置文件放在 Configmap 的一个主键中；
● Pod 以内部的文件或者环境变量使用文件数据，而不是通过 Kubernetes API；
● 当文件被更新时通过类似 Deployment 之类的资源完成滚动更新操作；
如果满足一下条件之一，应该使用 CRD：
● 使用 Kubernetes 客户端库和 CLI 来创建和更改新的资源；
● 希望 kubectl 能够直接支持你的资源，例如 kubectl get my-object object-name；
● 构造新的自动化机制，监测新对象上的更新事件，并对其他对象执行 CRUD 操作，或者监测后者更新前者；
● 希望对象是对一组受控资源的抽象，或者对其他资源的归纳提炼；
