You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider the case where in a replicatedJob each job needs to land on a separate topology, for example one per network domain, like a rack.
This can be achieved using a combination of affinity and anti-affinity constraints on the pod template:
affinity:
podAffinity: # ensures the pods of this job land on the same rack
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: job-name
operator: In
values:
- my-job
topologyKey: rack
podAntiAffinity: # ensures only this job lands on the rack
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: job-name
operator: NotIn
values:
- my-job
- key: job-name
operator: Exists
namespaceSelector: {}
topologyKey: rack
The problem is that the affinity terms above require setting the value of the job-name label explicitly, which in a replicatedJob is different for each job replica.
Consider the case where in a replicatedJob each job needs to land on a separate topology, for example one per network domain, like a rack.
This can be achieved using a combination of affinity and anti-affinity constraints on the pod template:
The problem is that the affinity terms above require setting the value of the
job-name
label explicitly, which in a replicatedJob is different for each job replica.The MatchLabelKeys enhancement in upstream k8s should address this problem, but it is not yet available.
Until this is available, we can have this injected by JobSet, triggered by an api we add to ReplicatedJob type that look like :
The text was updated successfully, but these errors were encountered: