0. 概述
在第一篇的时候就说过，在 Kubernetes v1.16 版本以及之后，CRD GA 了，这也就意味着 CRD 的版本正式成为了 V1 版本，而不再是 alphiv1 或者 betav1 了。
所以这里第一件事情就是回顾一下 CRD 的一路发展历程：
- Kubernetes 1.6以前：CRD 的前身叫 ThirdPartyResources
- Kubernetes 1.7：CRD 资源被加入 api-server
- Kubernetes 1.8
- 加入了 CustomResourceValidation，可以用 CRD 种的 json schema 来校验 CRD
- 添加了 generate-groups.sh 用于生成 CRD 的结构
- Kubernetes 1.9
- 有了 Sample Controller
- Kubernetes 1.10
- 支持 category
- Kubernetes 1.13
- 支持了多版本的 CRD
- 支持了 CRD conversion webhook
- Kubernetes 1.15
- CustomResourceDefinition OpenAPI Publishing
- Kubernetes 1.16
- CRD GA
从这整个的发展历程上来看，有几个事情是比较重要的：
- CRD 资源被加入 api-server，这个开启了 Kubernetes 的CRD 之路
- CRD 支持多版本，这让 CRD 开始进入到一个真正比较方便使用的时期
- CRD 支持 Json Schema 来校验，这让 CRD 的结构性得到了保证
1. 多版本
在 CRD 一开始的时候，虽然也可以定义多个版本的 CRD，但是，如果想要多个版本在 Kubernetes 中同时运行，那么就需要业务代码手动处理这个问题。
在 1.13 中，Kubernetes 加入了 webhook conversion 作为一个 alpha 特性，这使得不同版本的 CRD 之间可以通过外接 webhook 的方式进行转换，从而将版本变换的工作抽离出来，让 Controller 可以更加专注于业务处理。
2. CRD 校验
在第一篇中也描述过，在 1.16 中，CRD 的 validation 更换了未知，其实从 CRD 发布以来，社区一致在致力于让 CRD 更好用，从最初的 “无结构” 到 “有结构”，以及现在更好的“结构”，这都离不开 Json Schema 的帮助。
Kubernetes 不仅仅是使用 OpenAPI V3 的 schema，因为 V3 的 Schema 冗长复杂，所以 Kubernetes 结合了 V2 的 API，产生出最终的 CRD Validation。
同时，用户也可以通过访问 Kubernetes 的 API Server 的获取到 CRD 的结构定义，这对于自动化工具生成 SDK 有很多的帮助。