我知道我可以提示调度程序选择正确的节点
为 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 引用 PVC、PVC 然后引用 StorageClass、StorageClass 引用应该使用的 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 定义中选择的节点上。