为什么是 StatefulSet?无状态 Pod 不能使用持久卷吗? [英] Why StatefulSets? Can't a stateless Pod use persistent volumes?

问题描述

我正在尝试了解有状态集.它们的使用与具有持久卷的无状态"Pod 的使用有何不同?也就是说，假设一个正常"的 Pod 可能声称拥有持久存储，那么我缺少什么明显的东西需要这个新构造(具有有序的启动/停止等)?

I am trying to understand Stateful Sets. How does their use differ from the use of "stateless" Pods with Persistent Volumes? That is, assuming that a "normal" Pod may lay claim to persistent storage, what obvious thing am I missing that requires this new construct (with ordered start/stop and so on)?

推荐答案

是的，普通 Pod 可以使用持久卷.但是，有时您有多个 Pod 在逻辑上形成一个组".例如，数据库副本、ZooKeeper 主机、Kafka 节点等.在所有这些情况下，都有一堆服务器，它们一起工作并相互通信.他们的特别之处在于群体中的每个人都有一个身份.例如，对于数据库集群，一个是主节点，两个是跟随节点，每个跟随节点都与主节点通信，让主节点知道它已同步和未同步的内容.所以追随者知道db-x-0"是主，而主知道db-x-2"是追随者，并且拥有到某个点的所有数据，但仍然需要除此之外的数据.

Yes, a regular pod can use a persistent volume. However, sometimes you have multiple pods that logically form a "group". Examples of this would be database replicas, ZooKeeper hosts, Kafka nodes, etc. In all of these cases there's a bunch of servers and they work together and talk to each other. What's special about them is that each individual in the group has an identity. For example, for a database cluster one is the master and two are followers and each of the followers communicates with the master letting it know what it has and has not synced. So the followers know that "db-x-0" is the master and the master knows that "db-x-2" is a follower and has all the data up to a certain point but still needs data beyond that.

在这种情况下，您需要一些无法从常规 Pod 中轻松获得的东西:

In such situations you need a few things you can't easily get from a regular pod:

1. 一个可预测的名字:你想开始你的 Pod，告诉他们在哪里可以找到彼此，这样他们就可以形成一个集群，选举一个领导者等等.但是你需要提前知道他们的名字才能做到这一点.正常的 pod 名称是随机的，因此您无法提前知道.
2. 稳定的地址/DNS 名称:您希望步骤 (1) 中可用的任何名称保持不变.如果一个普通的 pod 在另一台主机上重新启动(你重新部署，它运行的主机挂了，等等)，它会得到一个新的名字和一个新的 IP 地址.
3. 组中的个人与其持久卷之间的持久链接:如果您的一个数据库主服务器运行的主机死机，它将被移动到一个新主机，但应该连接到相同 持久卷，因为只有一个卷包含该个人"的正确数据.因此，例如，如果您重新部署您的 3 个数据库主机组，您希望同一个人(通过 DNS 名称和 IP 地址)获得相同的持久卷，因此主服务器仍然是主服务器并且仍然拥有相同的数据，replica1 获取它的数据等

1. A predictable name: you want to start your pods telling them where to find each other so they can form a cluster, elect a leader, etc. but you need to know their names in advance to do that. Normal pod names are random so you can't know them in advance.
2. A stable address/DNS name: you want whatever names were available in step (1) to stay the same. If a normal pod restarts (you redeploy, the host where it was running dies, etc.) on another host it'll get a new name and a new IP address.
3. A persistent link between an individual in the group and their persistent volume: if the host where one of your database master was running dies it'll get moved to a new host but should connect to the same persistent volume as there's one and only 1 volume that contains the right data for that "individual". So, for example, if you redeploy your group of 3 database hosts you want the same individual (by DNS name and IP address) to get the same persistent volume so the master is still the master and still has the same data, replica1 gets it's data, etc.

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

StatefulSets solve these issues because they provide (quoting from https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/):

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

我并没有真正谈论 (3) 和 (4) 但这对集群也有帮助，因为您可以告诉第一个部署的成为主控，然后下一个找到第一个并将其视为主控，等

I didn't really talk about (3) and (4) but that can also help with clusters as you can tell the first one to deploy to become the master and the next one find the first and treat it as master, etc.

正如一些人所指出的，您确实可以通过使用常规 Pod 和服务来一些获得相同的好处，但需要做更多的工作.例如，如果您需要 3 个数据库实例，您可以手动创建 3 个部署和 3 个服务.请注意，您必须手动创建 3 个部署，因为您不能在部署中拥有指向单个 Pod 的服务点.然后，要扩大规模，您需要手动创建另一个部署和另一个服务.这确实有效，并且在 PetSet/PersistentSet 出现之前是一种常见的做法.请注意，它缺少上面列出的一些好处(例如，持久卷映射和固定启动顺序).

As some have noted, you can indeed can some of the same benefits by using regular pods and services, but its much more work. For example, if you wanted 3 database instances you could manually create 3 deployments and 3 services. Note that you must manually create 3 deployments as you can't have a service point to a single pod in a deployment. Then, to scale up you'd manually create another deployment and another service. This does work and was somewhat common practice before PetSet/PersistentSet came along. Note that it is missing some of the benefits listed above (persistent volume mapping & fixed start order for example).

这篇关于为什么是 StatefulSet?无状态 Pod 不能使用持久卷吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！