为什么要有状态集？无状态Pod不能使用持久卷吗？

我试图理解有状态集合。它们的使用与具有永久卷的“无状态”容器的使用有何不同？也就是说，假设“正常”的Pod可能声称拥有持久性存储，那么我遗漏了哪些明显的东西需要这种新构造（带有有序的启动/停止等）？

是的，常规吊舱可以使用持久卷。但是，有时您具有逻辑上形成“组”的多个Pod。这样的示例包括数据库副本，ZooKeeper主机，Kafka节点等。在所有这些情况下，都有一堆服务器，它们可以协同工作并相互通信。他们的特殊之处在于，小组中的每个人都有一个身份。例如，对于数据库集群，一个是主服务器，两个是从服务器，并且每个从服务器都与主服务器通信，以使其知道其已同步和未同步的内容。因此，追随者知道“ db-x-0”是主服务器，而主服务器知道“ db-x-2”是跟随器，并且具有到某个特定点的所有数据，但仍然需要超出该范围的数据。

在这种情况下，您需要从常规吊舱中轻松获取的一些功能：

1. 可预测的名称：您想启动Pod告诉他们在哪里可以找到对方，以便他们可以组成集群，选举领导者等。但是您需要事先知道他们的名字。普通广告连播名称是随机的，因此您无法提前知道。
2. 稳定的地址/ DNS名称：您希望在步骤（1）中可用的任何名称保持不变。如果普通Pod在另一台主机上重新启动（重新部署，运行它的主机死亡等），它将获得一个新名称和一个新IP地址。
3. 组中某个人与其持久卷之间的持久链接：如果数据库主服务器运行者所在的主机死亡，它将移至新主机，但应连接到只有一个且只有一个卷的相同持久卷包含该“个人”的正确数据。因此，例如，如果您重新部署3个数据库主机的组，则希望同一个人（按DNS名称和IP地址）获得相同的持久卷，从而使主服务器仍然是主服务器，并且仍具有相同的数据，那么copy1会得到数据等

StatefulSets解决了这些问题，因为它们提供了（引自https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/）：

1. 稳定的唯一网络标识符。
2. 稳定，持久的存储。
3. 有序，顺畅的部署和扩展。
4. 有序，优雅地删除和终止。

我并没有真正谈论（3）和（4），但是这对于群集也有帮助，因为您可以告诉第一个部署成为主服务器，而下一个找到第一个并将其视为主服务器，依此类推。

正如某些人所指出的，使用常规的pod和服务确实可以带来一些相同的好处，但是它的工作量更大。例如，如果需要3个数据库实例，则可以手动创建3个部署和3个服务。请注意，您必须手动创建3个部署，因为您无法在部署中拥有指向单个Pod的服务点。然后，要进行扩展，您将手动创建另一个部署和另一个服务。这确实有效，并且在PetSet / PersistentSet出现之前是某种普遍的做法。请注意，它缺少上面列出的某些好处（例如，持久卷映射和固定的启动顺序）。