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

不过，在 Operator 项目引人瞩目的成长经历背后，你是否考虑过这样一个问题：

Kubernetes 项目一直以来，其实都内置着一个管理有状态应用的能力叫作 StatefulSet 。而如果你稍微了解 Kubernetes 项目的话就不难发现， Operator 和 StatefulSet ，虽然在对应用状态的抽象上有所不同，但它们的设计原理，几乎是完全一致的，即：这两种机制的本质，都是围绕Kubernetes API 对象的“终态”进行调谐的一个控制器（Controller）而已。

可是，为什么在一个开源社区里，会同时存在这样的两个核心原理完全一致、设计目标也几乎相同的有状态应用管理方案呢？作为 CoreOS 公司后来广为人知的“左膀右臂”之一（即：etcd 和 Operator）， Operator 项目能够在 Kubernetes 生态里争取到今天的位置，是不是也是 CoreOS 公司的开源战略使然呢？

事实上， Operator 项目并没有像很多人想象的那样出生就含着金钥匙。只不过，在当时的确没有人能想到，当 CoreOS 的两名工程师带着一个业余项目从一间平淡无奇的公寓走出后不久，一场围绕着 Kubernetes API 生态、以争夺“分布式应用开发者”为核心的的重量级角逐，就徐徐拉开了序幕。