3

我有一个具有多个节点的 Kubernetes v1.17.0 集群。我创建了访问模式设置为 RWO 的 PVC。来自 Kubernetes 文档：

ReadWriteOnce -- 卷可以被单个节点以读写方式挂载

我正在使用不支持 ReadWriteMany 的 Cinder 卷插件。

当我创建两个挂载相同 PVC 的不同部署时，Kubernetes 有时会将它们部署在两个不同的节点上，这会导致 Pod 失败。

这是期望的行为还是我的配置有问题？

4

3 回答 3

4

正如我从您对评论的回答中收集到的，您不想使用关联规则，但希望调度程序为您执行这项工作。

似乎这个问题至少从 2016 年就已经知道但尚未解决，因为调度被认为按预期工作：https ://github.com/kubernetes/kubernetes/issues/26567

你可以阅读 issue 中的详细信息，但核心问题似乎是在 Kubernetes 的定义中，两个 PodReadWriteOnce永远不能同时访问一个卷。根据定义。需要实现的是一个标志，上面写着“这个 RWO 卷可以同时被两个 Pod 访问，即使它是 RWO”。但是这个功能还没有实现。

在实践中，您通常可以通过使用重新创建部署策略来解决此问题：.spec.strategy.type: Recreate。或者，使用其他答案所述的关联规则。

于 2020-05-14T20:30:51.213 回答
1

PV/PVC 的配置和新 Pod 的部署，在同一个节点上只能通过节点亲和性来实现。但是，如果您希望 Kubernetes 为您做出决定，则必须使用inter-pod affinity。

但是，只是为了验证您是否以正确的方式做所有事情，请参考这个。

于 2020-05-11T18:32:11.383 回答
0

由于底层硬件的原因，Kubernetes 中的持久卷可以绑定到节点或可用区：服务器内的存储驱动器、单个数据中心内的 SAN 不能由存储供应商移动。

现在，存储供应商如何知道他需要在哪个节点或哪个可用区中创建持久卷？这就是持久卷声明具有卷绑定模式的原因，WaitForFirstConsumer在这种情况下设置为。这意味着，配置发生在第一个挂载持久卷的 Pod 已安排好之后。有关更多详细信息，请阅读此处。

当第二个 pod 被调度时，它可能会在另一个节点或另一个可用区上运行，除非您使用inter-pod affinity告诉调度程序在与第一个 pod 相同的节点或相同的可用区中运行该 pod ：

    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          # adjust the labels so that they identify your pod
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - myapp
        # make pod run on the same node
        topologyKey: kubernetes.io/hostname
于 2020-05-14T15:21:38.310 回答