【问题标题】:Can I rely on volumeClaimTemplates naming convention?我可以依赖 volumeClaimTemplates 命名约定吗?
【发布时间】:2018-03-08 14:37:02
【问题描述】:

我想在启用 local PV 的裸元 kubernetes 1.7 中设置一个预定义的 PostgreSQL 集群。我有三个工作节点。我在每个节点上创建本地 PV 并成功部署有状态集(使用一些复杂的脚本来设置 Postgres 复制)。

但是我注意到在 volumeClaimTemplates 和 PersistentVolumeClaim 之间存在一种命名约定。 例如

apiVersion: apps/v1beta1 
kind: StatefulSet
  metadata:   
     name: postgres
  volumeClaimTemplates:
  - metadata:
      name: pgvolume

创建的pvc为pgvolume-postgres-0,pgvolume-postgres-1,pgvolume-postgres-2

使用一些tricky,我手动创建PVC并通过选择器绑定到目标PV。我再次测试有状态集。看来有状态集很乐意使用这些 PVC。

我成功完成了我的测试,但我仍然有这个问题。我可以依赖 volumeClaimTemplates 命名约定吗?这是一个未记录的功能吗?

【问题讨论】:

    标签: kubernetes persistent-volumes persistent-volume-claims


    【解决方案1】:

    基于有状态集API reference

    volumeClaimTemplates 是允许 pod 引用的声明列表。 StatefulSet 控制器负责以维护 pod 身份的方式将网络身份映射到声明。此列表中的每个声明必须在模板的一个容器中至少有一个匹配的(按名称)volumeMount。此列表中的声明优先于模板中具有相同名称的任何卷。

    所以我想你可以依赖它。

    此外,您可以定义一个存储类来利用持久卷的动态配置,因此您不必手动创建它们。

      volumeClaimTemplates:
      - metadata:
          name: www
        spec:
          accessModes: [ "ReadWriteOnce" ]
          storageClassName: my-storage-class
          resources:
            requests:
              storage: 1Gi
    

    详情请咨询Dynamic Provisioning and Storage Classes in Kubernetes

    【讨论】:

    • 这对于动态存储配置来说很好,但是当您需要手动配置 PV 并将它们分配给这些 PVC 时会发生什么。这在我的经验中是相当令人不安的。有没有办法顺序定义该 PVC 模板中将使用哪些 PV 名称?否则,手动 PV 配置将成为一项尝试仔细匹配 .spec.volumeName 的任务,因为每个 SatetefulSet 实例都是在前一个实例是 Ready 之后创建的。
    猜你喜欢
    • 2011-01-23
    • 2011-03-11
    • 2013-06-12
    • 1970-01-01
    • 1970-01-01
    • 2012-01-09
    • 2010-12-15
    • 2015-03-15
    • 1970-01-01
    相关资源
    最近更新 更多