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

在当时的 Kubernetes 社区里，跟应用开发者打交道并不是一个非常常见的事情。而 Operator 项目的诞生，却把 Kubernetes 项目第一次拉近到了开发者的面前，这让整个社区感觉了不适应。而作为 Kubernetes 项目 API 治理的负责人， Google 团队对这种冲突的感受最为明显。

对于 Google 团队来说， Controller 以及控制器模式，应该是一个隐藏在 Kubernetes 内部实现里的核心机制，并不适合直接开放给开发者来使用。退一步说，即使开放出去，这个 Controller 的设计和用法，也应该按照 Kubernetes 现有的 API 层规范来进行，最好能成为 Kubernetes 内置 Controller Manager 管理下的一部分。可是， Operator 却把直接编写 Controller 代码的自由度完全交给了开发者，成为了一个游离于 Kubernetes Controller Manager 之外的外部组件。

带着这个想法，社区里的很多团队从 Operator 项目诞生一开始，就对它的设计和演进方向提出了质疑，甚至建议将 Operator 的名字修改为 Custom Kubernetes Controller 。而无巧不成书，就在 Google 和 CoreOS 在 Controller 的话语权上争执不下的时候， Kubernetes 项目的发起人之一 Brendan Burns 突然宣布加入了微软，这让 Google 团队和 Operator 项目的关系一下子跌倒了冰点。