你好,我是张磊。今天我和你分享的主题是:深入解析声明式 API 之 API 对象的奥秘。
在上一篇文章中,我为你详细讲解了 Kubernetes 声明式 API 的设计、特点,以及使用方式。
而在今天这篇文章中,我就来为你讲解一下 Kubernetes 声明式 API 的工作原理,以及如何利用这套 API 机制,在 Kubernetes 里添加自定义的 API 对象。
你可能一直就很好奇:当我把一个 YAML 文件提交给 Kubernetes 之后,它究竟是如何创建出一个 API 对象的呢?
这得从声明式 API 的设计谈起了。
在 Kubernetes 项目中,一个 API 对象在 Etcd 里的完整资源路径,是由:Group(API 组)、Version(API 版本)和 Resource(API 资源类型)三个部分组成的。
通过这样的结构,整个 Kubernetes 里的所有 API 对象,实际上就可以用如下的树形结构表示出来:
在这幅图中,你可以很清楚地看到 Kubernetes 里 API 对象的组织方式,其实是层层递进的。
比如,现在我要声明要创建一个 CronJob 对象,那么我的 YAML 文件的开始部分会这么写:
apiVersion: batch/v2alpha1
kind: CronJob
...
在这个 YAML 文件中,“CronJob”就是这个 API 对象的资源类型(Resource),“batch”就是它的组(Group),v2alpha1 就是它的版本(Version)。