我有以下PersistentVolumeClaim：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nginx-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 256Mi
storageClassName: fask和部署：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
volumeMounts:
- name: data
mountPath: "/var/www/html"
volumes:
- name: data
persistentVolumeClaim:
claimName: nginx-pvc如果我使用 * 单个 * 复制副本部署运行，我的PV将由vsphereStorageClass动态创建
但是，如果我有超过 2 个副本，它将无法创建第二个PV：
AttachVolume.Attach failed for volume "pvc-8facf319-6b1a-11e8-935b-00505680b1b8" : Failed to add disk 'scsi0:1'.
Unable to mount volumes for pod "nginx-deployment-7886f48dcd-lzms8_default(b0e38764-6b1a-11e8-935b-00505680b1b8)": timeout expired waiting for volumes to attach or mount for pod "default"/"nginx-deployment-7886f48dcd-lzms8". list of unmounted volumes=[data]. list of unattached volumes=[data default-token-5q7kr]
3条答案
按热度按时间sqougxex1#
但是，如果我有2个以上的副本，它将无法创建第二个PV
然后，您可能应该在其中使用
StatefulSet和volumeClaimTemplates，而不是Deployment和PersistentVolumeClaim。在您的情况下，每个部署都具有相同的
PersistentVolumeClaim（即ReadWriteOnly，并且不能在第二个请求时挂载），而对于volumeClaimTemplates，您可以为每个副本提供不同的配置。jdgnovmf2#
我知道我来晚了，但我不同意这个被认可的答案。这取决于你想实现什么（就像编码生活中的大多数事情一样）。
当您需要具有完全独立的副本时，带volumeClaimTemplates的StatefulSets非常有用，这些副本将通过某种应用程序级实现的机制相互通信，同时仍然作为单独的身份存在。我正在考虑分布式数据库，例如Cassandra：不同的db节点，每个节点一个pod，具有不同的持久化存储，每个节点一个PV。Cassandra中的gossip机制将使数据在卷之间保持同步。
在我看来，如果你主要将Kubernetes用于微服务和复制应用程序，这是一种可以避免的情况。当您需要进行滚动更新或升级Kubernetes版本时，StatefulSet是一个麻烦，因为它们不太容易扩展。
无论复制副本的数量如何，部署都会装载单个持久卷：同一部署的10个pod将尝试装载同一卷进行读和写操作。您遇到的问题是，大多数卷提供程序不允许多个节点挂载卷。这是你需要经验的时候。
如果你只需要，就像你的模板一样，通过与多个pod共享相同的源来暴露一个冗余的网站，以便在不停机的情况下实现滚动更新，你可以使用deploy和volumeClaim（不是volumeClaimTemplates）：如果您可以使用一个部署在多个pod上挂载相同的卷，您只需要确保所有部署都将被分配到同一个节点。PodAffinity将为您完成这项工作。
gzszwxb43#
ReadWriteOnce PV声明所有Pod必须在同一个节点上运行。您需要将NodeSelector添加到Deployment。