A job can be specified with multiple replicas.
Once https://gitlab.wikimedia.org/repos/cloud/toolforge/jobs-api/-/merge_requests/220 is merged with the default rollout strategy of
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdateThere is no good reason why jobs (deployments) should have downtime (bar some major platform problem).
One last shoot-yourself-in-the-face issue is we currently do not apply any constraints to the deployment, depending on resource usages at the time, all your replicas could get scheduled onto one node.
Additionally, as NFS nodes are not un-scheduleable for toolforge.org/mount-storage: none (like non nfs workers are for toolforge.org/mount-storage: all) it's also possible (perhaps likely due to the worker distribution) to get scheduled onto a node which is a little explody (nfs hangs).
To solve the first problem, we can easily apply topologySpreadConstraints to deployments.
For the second problem, today we apply (when mount=all):
nodeSelector: kubernetes.wmcloud.org/nfs-mounted: "true"
We could do the inverse, which would leave nfs workers with /only/ nfs workloads. Personally I think that would be quite nice, a lot less state and potential issues, but it might drastically change capacity planning etc.
A middle ground would be to construct some rules that motivate the scheduler to not use nodes with that selector, but still allow it, providing an incremental path to scale down nfs workers (if this is a goal).