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

从上述叙述中，你就应该能够明白， Operator 其实就是一段代码，这段代码 Watch 了 etcd 里一个描述分布式应用集群的API 对象，然后这段代码通过实现 Kubernetes 的控制器模式，来保证这个集群始终跟用户的定义完全相同。而在这个过程中， Operator 也有能力利用 Kubernetes 的存储、网络插件等外部资源，协同的为应用状态的保持提供帮助。

所以说， Operator 本身在实现上，其实是在 Kubernetes 声明式 API 基础上的一种“微创新” 。它合理的利用了 Kubernetes API 可以添加自定义 API 类型的能力，然后又巧妙的通过 Kubernetes 原生的“控制器模式” ，完成了一个面向分布式应用终态的调谐过程。

而 Operator 本身在用法上，则是一个需要用户大量编写代码的的开发者工具。不过，这个编写代码的过程，并没有像很多人当初料想的那样导致 Operator 项目走向小众，反而在短短三年的时间里， Operator 就迅速成为了容器化分布式应用管理的事实标准。时至今日， Operator 项目的生态地位已经毋庸置疑。就在刚刚结束的2018年 KubeCon 北美峰会上， Operator 项目和大量的用户案例一次又一次出现在聚光灯前，不断的印证着这个小小的“微创新”对整个云计算社区所产生的深远影响。