问题描述
听说statefulset适合数据库。 但是 StatefulSet 会为 echo pod 创建不同的 pvc。 如果我设置了 replicas=3.then，我会得到 3 个 pod 和 3 个不同数据的不同 pvc。 对于数据库用户，他们只想要一个数据库而不是 3 个数据库。 所以很明显我们不应该在这种情况下使用 statefulset。 但是我们什么时候应该使用 statefulset。
解决方法
状态集对于运行基本上存储状态的应用程序很有用。
状态集数据库运行 POD 和 PVC 的多个副本，但在内部它们都自动同步。跨 Pod 和 PVC 的数据同步。
因此，理想情况下，最好使用具有多个副本的有状态集来获取HA 数据库。
现在取决于你想使用哪个数据库的用例，它支持复制或不集群等。
这是带有复制详细信息的 MySQL 示例：https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/
,StatefulSet 与 Deployment 做了三件大事：
- 它为每个副本创建一个新的 PersistentVolumeClaim；
- 它给出了 Pod 的顺序名称，以
statefulsetname-0开头；和 - 它以特定顺序（数字升序）启动 Pod。
当数据库本身知道如何在自身的不同副本之间复制数据时，这很有用。例如，在 Elasticsearch 中，索引被分解为分片。默认情况下，每个分片有两个副本。如果您有五个运行 Elasticsearch 的 Pod，每个 Pod 将拥有不同部分的数据，但在内部，数据库系统知道如何将请求路由到具有相关数据的特定服务器。
我建议优先使用 StatefulSet，而不是手动创建 PersistentVolumeClaim。对于无法复制的数据库工作负载，无论哪种情况，您都不能将 replicas: 设置为大于 1，但 PVC 管理很有价值。您通常不能让多个数据库指向同一个物理存储、容器或其他地方，而且大多数类型的 Volume 不能在 Pod 之间共享。
我们可以将数据库作为有状态应用程序部署到 Kubernetes。通常，当我们部署 Pod 时，它们有自己的存储空间，但该存储空间是短暂的——如果容器杀死了它的存储空间，它就会消失。
因此，我们将有一个 Kubernetes 对象来处理这种情况：当我们希望数据持久化时，我们会附加一个具有相应持久卷声明的 pod。通过这样做，如果我们的容器杀死了我们的数据，它将在集群中，并且新的 pod 将相应地访问数据。
使用 StatefulSet 的一些限制是：
1.需要使用持久卷供应器来为基于请求存储类的 pod 供应存储。
2.删除或缩减副本不会删除附加到 StatefulSet 的卷。保证了数据的安全。
3.StatefulSets 目前需要一个 Headless Service 来负责 Pod 的网络身份。
4.StatefulSet 不提供任何保证在删除 StatefulSet 时删除所有 pod，不像部署，它会在删除部署时删除与部署关联的所有 Pod。在删除 StatefulSet 之前，您必须将 pod 副本缩减为 0。