Kubernetes CRD 系列（八）：Controller 的发展变化

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

从这整个的发展历程上来看，有几个事情是比较重要的：

1. CRD 资源被加入 api-server，这个开启了 Kubernetes 的CRD 之路
2. CRD 支持多版本，这让 CRD 开始进入到一个真正比较方便使用的时期
3. 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 有很多的帮助。

3. Ref

• Kubernetes Chagelog
• Future of CRDs: Structural Schemas
• 全面进化：Kubernetes CRD 1.16 GA前瞻