local-path-provisioner icon indicating copy to clipboard operation
local-path-provisioner copied to clipboard

PV nodeAffinity.required.nodeSelectorTerms matchFields does not result in the kube scheduler placing pods on the same node as the PV

Open kmurray01 opened this issue 1 year ago • 5 comments

Observing this on the latest v0.0.29 release and master-head local-path-provisoner on K3s v1.30.4+k3s1.

PVs created with the new local-path-provisoner image have an updated nodeAffinity.required.nodeSelectorTerms as depicted below

nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchFields:
        - key: metadata.name
          operator: In
          values:
          - my-agent-host.example.com

This change originated from PR https://github.com/rancher/local-path-provisioner/pull/414, that was subsequently included into the latest v0.0.29 release and master-head.

Deploying a pod specifying a persistentVolumeClaim to an associated pvc, the pod is scheduled on a different node, not my-agent-host.example.com. That pod then fails to initialize as it's unable to mount the PV volume path on my-agent-host.example.com.

Previously on v0.0.28, the PV nodeAffinity.required.nodeSelectorTerms is as below and this works. The kube scheduler places the pod on the same node on which the PV local path volume is created, i.e. my-agent-host.example.com in this example.

nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - my-agent-host.example.com

It would seem switching the nodeAffinity.required.nodeSelectorTerms to matchFields for node field metadata.name does not work or the kube scheduler does not comply with that nodeAffinity.

Also it's important to highlight on the K3s node, the value of metadata.name matches my-agent-host.example.com.

kmurray01 avatar Sep 04 '24 16:09 kmurray01