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

如果说， Docker 镜像的提出，完成了应用静态描述的标准化。那么 Kubernetes Operator 的出现，终于为应用的动态描述提出了一套行之有效的实现规范。更为重要的是，对于 TiDB、Kafka、RocketMQ 等分布式应用的开发者来说，这些应用运行起来之后的动态描述，才是对一个分布式应用真正有意义的信息。

而在此之前，用户如果要想将 TiDB、Kafka 这样的分布式应用很好的使用起来，就不得不去尝试编写一套复杂的管理脚本，甚至为此学习大量与项目本身无关的运维知识。更为麻烦的是，这些脚本、知识、和经验，并没有一个很好的办法能够有效的沉淀下来。而任何一种技术的传授，如果严重依赖于口口相传而不是固化的代码和逻辑的话，那么它的维护成本和使用门槛，就可以说是“灾难级”的。

所以说， Kubernetes Operator 发布之初最大的意义，就在于它将分布式应用的使用门槛直接降到了最低。

那么这个门槛具体有多低呢？

一般来说，无论这个分布式应用项目有多复杂，只要它为用户提供了 Operator ，那么这个项目的使用就只需要两条命令即可搞定，以 Kafka 为例：