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

你可能已经知道， Kubernetes 里本身就内置了一个叫做 StatefulSet 的功能，是专门用来管理有状态应用的。而 StatefulSet 的核心原理，其实是对分布式应用的两种状态进行了保持：

分布式应用的拓扑状态，或者说，节点之间的启动顺序；
分布式应用的存储状态，或者说，每个节点依赖的持久化数据。

可是，为了能够实现上述两种状态的保持机制， StatefulSet 的设计就给应用开发者带来了额外的束缚。

比如， etcd 集群各节点之间的拓扑关系，并不依赖于节点名字或者角色（比如 Master 或者 Slave）来确定，而是记录在每个 etcd 节点的启动参数当中。这使得 StatefulSet 通过“为节点分配有序的 DNS 名字”的拓扑保持方式，实际上没有了用武之地，反而还得要求开发者在节点的启动命令里添加大量的逻辑来生成正确的启动命令，非常不优雅。类似的，对于存储状态来说， etcd 集群对数据的备份和恢复方法，也跟 StatefulSet 依赖的的远程持久化数据卷方案并没有太大关系。