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

问题描述

我试图理解状态集.它们的使用与具有永久卷的无状态"容器的使用有何不同?也就是说，假设正常"的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可以使用持久卷.但是，有时您有多个吊舱，这些吊舱在逻辑上构成一个组".这样的示例包括数据库副本，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.

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

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

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

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.

StatefulSet解决了这些问题，因为它们提供了(引自 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).

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