亲历者说: Kubernetes API 与 Operator, 不为人知的开发者战争(16)_如果我问你

更重要的是，不同于 StatefulSet 等 Kubernetes 原生的编排概念， Operator 依赖的 Kubernetes 能力，只有最核心的声明式 API 与控制器模式；Operator 具体的实现逻辑，则编写在自定义 Controller 的代码中。这种设计给开发者赋予了极高的自由度，这在整个云计算和 PaaS 领域的发展过程中，都是非常罕见的。

此外，相比于 Helm、Docker Compose 等描述应用静态关系的编排工具， Operator 定义的乃是应用运行起来后整个集群的动态逻辑。得益于 Kubernetes 项目良好的声明式 API 的设计和开发者友好的 API 编程范式， Operator 在保证上述自由度的同时，又可以始终如一的展现出清晰的架构和设计逻辑，使得应用的开发者们，可以通过复制粘贴就快速搭建出一个 Operator 的框架，然后专注于填写自己的业务逻辑。

在向来讲究“用脚投票”的开发者生态当中， Operator 这样一个编程友好、架构清晰、方便代码复制粘贴的小工具，本身就已经具备了某些成功的特质。

然而， Operator 的意外走红，并没有让 CoreOS 公司“一夜成名” ，反而差点将这个初出茅庐的项目，扼杀在萌芽状态。