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

这两条命令执行完成后，一个 Kafka 集群运行所需的节点，以及它们所依赖的 ZooKeeper 节点，就会以容器的方式自动出现在你的 Kubernetes 集群里了。

不过，简化运维和部署，其实只是 Operator 在用户层面的表象。而在更底层的技术层面， Operator 最大的价值，在于它为“容器究竟能不能管理有状态应用”这个颇具争议话题，画上了一个优雅的句号。

要知道，在2014-2015年的时候，伴随着 Docker 公司和 Docker 项目的走红，整个云计算生态几乎都陷入了名为“容器”的狂热当中。然而，相比于 “容器化”浪潮的如火如荼，这个圈子却始终对“有状态应用”讳莫如深。

事实上，有状态应用（比如，前面提到的Kafka ）跟无状态应用（比如，一个简单的Jave Web网站）的不同之处，就在于前者对某些外部资源有着绑定性的依赖，比如远程存储，或者网络设备，以及，有状态应用的多个示例之间往往有着拓扑关系。这两种设计，在软件工程的世界里可以说再普通不过了，而且我们几乎可以下这样一个结论：所有的分布式应用都是有状态应用。