#CSI Topology

1 messages · Page 1 of 1 (latest)

neon wedge
#

Hi.

We are trying to load balance PVC creation over 4 different SVMs on different clusters. The selected node for the POD will be used to decide where the PVC will be created on.
This looks like a perfect fit for CSI Topology.

The only issue is pod rescheduling in case of worker node failure, if the pod will be rescheduled on node with different label than the original node mount to the exsiting pvc will fail:

`
Events:
Type Reason Age From Message

Warning FailedScheduling 40s default-scheduler 0/6 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 1 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate, 1 node(s) were unschedulable, 3 node(s) had volume node affinity conflict.
`

We don't want to use nodeSelector to schedule pods on specific nodes since there are many (~3000) pods doing the same tasks and we want to remove complexity.

Any suggestion to make sure pods will be re-scheduled on nodes with the same label after the initial scheduling ?

paper kindle
#

Pods being re-scheduled on nodes has nothing to do with the storage driver of kubernetes. It sounds like you are looking for taints and tolerations. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/

Kubernetes
Taints and Tolerations

Node affinity is a property of Pods that attracts them to a set of nodes (either as a preference or a hard requirement). Taints are the opposite -- they allow a node to repel a set of pods.
Tolerations are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee sche...