【问题标题】:kubernetes storage class node selectorKubernetes 存储类节点选择器
【发布时间】:2020-10-15 09:41:15
【问题描述】:

我正在尝试利用 k8s 的本地卷动态配置器,Rancher 的一个,具有多个实例,每个实例都有自己的存储类,以便我可以根据它们的性能提供多种类型的本地卷(例如 ssd、hdd、等)。

底层基础设施不是对称的;有的节点只有ssd,有的只有hdd,有的两个都有。

我知道我可以通过为 pod 提供节点亲和性规则来提示调度程序选择合适的节点。

但是,有没有更好的方法仅在配置器/存储类级别解决这个问题?例如,使存储类仅可用于集群节点的子集。

【问题讨论】:

    标签: kubernetes rancher kubernetes-pvc


    【解决方案1】:

    我知道我可以提示调度程序选择正确的节点 为 pod 提供节点亲和性规则。

    使用local 持久卷时,无需在Pod 级别上定义节点关联规则。节点亲和性可以在PersistentVolume定义中指定。

    但是,有没有更好的方法来解决这个问题? 仅供应商/存储类?例如,只创建一个存储类 可用于集群节点的子集。

    不,它不能在StorageClass 级别上指定。也不能让StorageClass 仅可用于部分节点。

    但是对于配置器,我会说是的,它应该是可行的,因为主要的存储配置器任务之一是创建匹配的 PersistentVolume 对象以响应用户创建的 PersistentVolumeClaim。你可以阅读它here

    动态卷配置允许创建存储卷 一经请求。如果没有动态配置,集群管理员可以 手动调用他们的云或存储提供商来创建 新的存储卷,然后创建 PersistentVolume 对象以 在 Kubernetes 中代表它们。动态配置功能 无需集群管理员预先配置 贮存。相反,它会在存储时自动配置存储 用户请求。

    因此,从一开始就查看整个卷提供过程如下所示:

    用户仅创建PersistenVolumeClaim 对象,并在其中指定StorageClass

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: myclaim
    spec:
      accessModes:
        - ReadWriteOnce
      volumeMode: Filesystem
      resources:
        requests:
          storage: 10Gi
      storageClassName: local-storage ### ?
    

    它可以用在Pod 定义中:

    apiVersion: v1
    kind: Pod
    metadata:
      name: mypod
    spec:
      containers:
        - name: myfrontend
          image: nginx
          volumeMounts:
          - mountPath: "/var/www/html"
            name: mypd
      volumes:
        - name: mypd
          persistentVolumeClaim:
            claimName: myclaim ### ?
    

    所以在实践中,在Pod 定义中,您只需指定正确的PVC无需在此处定义任何节点关联规则

    Pod 引用 PVCPVC 然后引用 StorageClassStorageClass 引用应该使用的 provisioner

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: local-storage
    provisioner: kubernetes.io/my-fancy-provisioner ### ?
    volumeBindingMode: WaitForFirstConsumer
    

    所以最终provisioner 的任务是创建匹配的PersistentVolume 对象。它可以如下所示:

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: example-pv
    spec:
      capacity:
        storage: 10Gi
      volumeMode: Filesystem
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      storageClassName: local-storage
      local:
        path: /var/tmp/test
      nodeAffinity: ### ?
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ssd-node ### ?
    

    所以 Pod 使用 myclaim PVC -> 引用 local-storage StorageClass -> 选择适当的存储 provisioner 将自动安排在此配置器创建的PV 定义中选择的节点上。

    【讨论】:

    • 我理解(我希望),本地持久卷特性引入的 PV 级别节点亲和性。但是,只有预先静态创建 PV 才能帮助调度程序知道在哪个节点上调度 POD。在重新安排 pod 时,它也有助于 PV 定义已经可用。但是,对于动态供应商 WaitForFirstConsumer 的情况,Pod 不是在 PV 之前安排的吗?如果是,则该节点已被选中。如果该存储类无法在该节点上进行配置,那么它就是死路一条。我在这里做错了什么?
    猜你喜欢
    • 1970-01-01
    • 2020-12-16
    • 1970-01-01
    • 1970-01-01
    • 2017-04-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多