一枝芦苇

比如如果要实现一个ai-operator项目，其中可能包含模型训练相关的控制器trainjob-controller和推理服务相关的控制器atom-controller。这行配置会告诉Operator后面新增的API不要放到api/目录下，而是放到 apis/目录下;这个命令的能力其实非常有限，它只是在Dockerfile文件中将api目录变成了 apis/目录，然后在 PROJECT文件 中加了一行multigroup:true。这时旧版的API就被挪动到合适的目录了。

一般情况下，开发一个新项目，它的API是会经常变更的,不管一开始考虑得多么详细，都避免不了迭代的过程中去修改API定义。过了一段时间后，API会趋于稳定，在达到稳定版本之后，可能才正式发布V1.0版本。当然，这个稳定版的API就不应该再变化了，到了下一个版本想增强一下这个API，可能需要发布V2.0版本，这时V1.0版本还是要能够继续正常工作。我们来看看Operator中是如何支持多版本API的。

我们知道访问Kubernetes API有好几种方式，比如使用kubectl命令、使用client-go之类的开发库、直接通过REST请求等。不管是一个使用kubectl的真人用户，还是一个Service Account，都可以通过API访问认证，这个过程官网有一张图描述得很直观当一个访问请求发送到API Server的时候，会依次经过认证、鉴权、准入控制三个主要的过程。Admission Webhook就是这里提到的“准入控制”的范畴.

在之前文章中我们创建了operator项目以及自定义了API，并且将主要的调谐逻辑也编写好了。我们接下来开始编写调谐deployment与service主要流程。

我们打开api/v1/atom_types可以看到以下代码Operator的核心逻辑就是不断调谐资源对象的实际状态和期望状态 (Spec) 保持一致。这里的Status当然不是严格对应“实际状态”，而是观察并记录下来的当前对象最新“状态”。大多数资源对象都有Spec和Status两个部分，但是也有部分资源对象不符合这种模式，比如ConfigMap之类的静态资源对象就不存在着“期望的状态”这一说法。

Kubernetes（K8s）的自定义资源（Custom Resource Definitions，简称CRD）是一种扩展Kubernetes API的方式。Kubernetes本身已经有很多内建的API资源，如Pod、Service、Volume等。但在一些特定场景下，这些内建资源可能无法满足所有需求。此时，可以使用自定义资源来定义新的资源类型。自定义资源是API的扩展，可以将其视为数据库的模式，它说明了一种新的对象类型的名称、结构、行为。