Change Details

{T355883} introduced a new type of workers. As the number of them is relatively low, and as most of our infrastructure components do not have NFS access, the risk of all of the pods in a given deployment ending up on the same node is higher than I'd like. For that reason(*) we should tell the Kubernetes scheduler to spread them to different nodes if possible. [[ https://stackoverflow.com/a/64958458/6314988 | Since Kubernetes 1.19 ]] the best way to do this is with `topologySpreadConstraints` on the `kubernetes.io/hostname` field: https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/. * [ ] api-gateway - https://gitlab.wikimedia.org/repos/cloud/toolforge/api-gateway/-/merge_requests/35 * [ ] builds-admission * [ ] builds-api - https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-api/-/merge_requests/82 * [ ] envvars-admission - https://gitlab.wikimedia.org/repos/cloud/toolforge/envvars-admission/-/merge_requests/10 * [ ] envvars-api - https://gitlab.wikimedia.org/repos/cloud/toolforge/envvars-api/-/merge_requests/46 * [ ] ingress-admission * [ ] jobs-api - https://gitlab.wikimedia.org/repos/cloud/toolforge/jobs-api/-/merge_requests/117 * [ ] jobs-emailer * [ ] registry-admission * [ ] volume-admission - https://gitlab.wikimedia.org/repos/cloud/toolforge/volume-admission/-/merge_requests/15 (*): It'd always been a good idea, but now the risk of this causing issues is much higher.