我是kubernetes的新手，这个话题对我来说很困惑。我了解到有状态集不共享PV，每个副本都有自己的PV。另一方面，我看到的例子是，当一个人使用一个pvc有状态集与许多副本。我的问题是到时候会发生什么?由于PVC到PV的绑定是1:1，所以一个PVC只能绑定一个PV，但是每个副本应该有自己的PV，所以在这种情况下如何可能有一个PVC处于有状态集?
您通常应该使用带有StatefulSet的卷声明模板。正如您在问题中注意到的，这将为每个副本创建一个新的persistentvolumecclaim(和一个新的PersistentVolume)。数据是不共享的，除非容器进程知道如何在其副本之间复制数据。如果删除并重新创建StatefulSet Pod，它将返回相同的底层PVC和相同的数据，即使它在不同的节点上重新创建。
spec:
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 1Gi
template:
spec:
containers:
- name: name
volumeMounts:
- name: data
mountPath: /data
您可以手动创建一个PVC并将其附加到statfulset Pods
# not recommended -- one PVC shared across all replicas
spec:
template:
spec:
volumes:
- name: data
persistentVolumeClaim:
claimName: manually-created-pvc
containers:
- name: name
volumeMounts:
- name: data
mountPath: /data
，但在这种情况下，单个PVC/PV将被所有副本共享。这通常不能很好地工作:像数据库容器这样的东西有显式检查它们的存储是否被共享，并且这样做可能会产生一系列并发问题。这也可以防止pod启动，因为直接获得的卷类型通常只支持ReadWriteOnce访问模式;要获得readwritmany，您需要在集群外额外配置NFS服务器之类的东西。
我不确定您遵循的是哪个例子并检查了该场景，但是PV和PVC是1:1映射。
通常，PVC以访问模式连接到PODReadWriteOnly这意味着只有一个pod可以做读写.
您可能会看到的场景可能是类似于有一个PVC和一个PV附加到多个副本，这可能是由于ReadWriteMany.
persistentvolumecclaim (PVC)是用户对存储的请求。它类似于豆荚。pod消耗节点资源，pvc消耗PV资源。pod可以请求特定级别的资源(CPU和内存)内存)。权利要求可以请求特定的大小和访问模式(例如，它们可以挂载ReadWriteOnce, ReadOnlyMany或ReadWriteMany，看到了吗AccessModes)。
阅读更多关于访问模式的信息:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
NFS、EFS和其他类型的存储支持ReadWriteMany访问模式。
When I deploy e.g. nginx as SS and I use one PVC only one PV is created and storage is shared between all replicas.
你的实验是正确的，这是可能的，因为调度程序已经分配了同一节点上的所有pod，由于依赖于PV。如果节点的资源耗尽，导致一个pod在另一个节点上得到调度，那么该pod将进入pending状态。