0. 概述

在第一篇的时候就说过,在 Kubernetes v1.16 版本以及之后,CRD GA 了,这也就意味着 CRD 的版本正式成为了 V1 版本,而不再是 alphiv1 或者 betav1 了。

所以这里第一件事情就是回顾一下 CRD 的一路发展历程:

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

  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