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

你可能会有些困惑：Brendan Burns 与 Kubernetes 的关系我是清楚的，但这跟 Operator 又有什么瓜葛吗？

实际上，你可能很难想到， Brendan Burns 和他的团队，才是 TPR （Third Party Resource）这个特性最初的发起人。
所以，几乎在一夜之间， Operator 项目链路上的每一个环节，都与 Google 团队完美的擦肩而过。眼睁睁的看着这个正冉冉升起的开发者工具突然就跟自己完全没了关系，这个中滋味，确实不太好受。

于是，在 2017年初， Google 团队和 RedHat 公司开始主动在社区推广 UAS（User Aggregated APIServer），也就是后来 APIServer Aggregator 的雏形。 APIServer Aggregator 的设计思路是允许用户编写一个自定义的 APIServer ，在这里面添加自定义 API 。然后，这个 APIServer 就可以跟 Kubernetes 原生的 APIServer 绑定部署在一起统一提供服务了。不难看到，这个设计与 Google 团队认为自定义 API 必须在 Kubernetes 现有框架下进行管理的想法还是比较一致的。

紧接着， RedHat 和 Google 联盟开始游说社区使用 UAS 机制取代 TPR ，并且建议直接从 Kubernetes 项目里废弃 TPR 这个功能。一时间，社区里谣言四起，不少已经通过 TPR 实现的项目，也开始转而使用 UAS 来重构以求自保。而 Operator 这个严重依赖于 TPR 的小项目，还没来得及发展壮大，就被推向了关闭的边缘。