Helm chart customization to support topology spread constraints

Release notes

Problem to solve

As a user I would like access to a gitlab helm chart to support topology spread constraints, which allow me to guarantee that gitlab pods will be adequately spread across nodes (using the AZ labels).

Intended users

Devon (DevOps Engineer)

User experience goal

Currently, the helm deployment ensures pods aren't scheduled to the same node. This is a step towards resilience, but still allows for scenarios when an AZ may go down. If pods aren't evenly distributed, this could lead to a large performance degradation while new nodes are spun up in the healthy AZs.

Proposal

Enabling https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ across the chart deployment would allows users to configure their deployments to evenly spread across AZs. This would greatly reduce the odds of an AZ failure taking down the majority of the GitLab deployment.

Further details

Our k8s nodes currently have labels like topology.kubernetes.io/zone: us-east-2c If the helm chart supported pod topology spread constraints, we could easily configure the deployment to ensure our workloads are evenly distributed across all 3 AWS AZs in that region. https://kubernetes.io/docs/concepts/services-networking/topology-aware-hints/ may also help improve latency/performance/cross-AZ routing costs by ensuring services in an AZ talk to other services in the same AZ.

Permissions and Security

Documentation

Availability & Testing

Available Tier

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by Alejandro Michell