Document Zero Downtime upgrade process for Helm charts
What does this MR do?
This merge request adds comprehensive documentation for performing zero-downtime upgrades of GitLab installations using Helm charts. The changes introduce a new section explaining how to upgrade GitLab without service interruptions by configuring rolling update strategies that ensure at least one service instance remains available during upgrades.
The documentation includes specific configuration settings for different GitLab components (webservice, sidekiq, registry, etc.) that control how pods are replaced during upgrades - bringing up new instances before terminating old ones. It also provides a detailed step-by-step upgrade process that involves pausing deployments, running database migrations in stages, and then gradually rolling out the new version.
The changes also reorganize the existing upgrade documentation by moving the previous note about zero-downtime only being available through GitLab Operator, and instead providing native Helm chart support for this capability. Additional sections cover requirements (like having multiple replicas and high-availability external services), considerations (such as Gitaly not supporting zero-downtime), and post-upgrade steps.
Related issues
Relates to:
Author checklist
For general guidance, please follow our Contributing guide.
Required
For anything in this list which will not be completed, please provide a reason in the MR discussion.
- Merge Request Title and Description are up to date, accurate, and descriptive.
- MR targeting the appropriate branch.
- MR has a green pipeline.
- Documentation created/updated.
- Tests added/updated, and test plan for scenarios not covered by automated tests.
- Equivalent MR/issue for omnibus-gitlab opened.
Reviewers checklist
- MR has a green pipeline on https://gitlab.com/gitlab-org/charts/gitlab.
- Consider downstream impact to the Operator, as per evaluating impact from changes to GitLab chart.