Webservice: Implement generator pattern to allow traffic splitting across scalable Deployments
What does this MR do?
gitlab/webservice chart into a generator pattern.
Now builds a datamodel under
.deployments, and then populates necessary K8s objects with specific data.
- Non-breaking behavior, preventing need for a major version change
- No changes in Helm supported versions (currently as far back as
- Inheritance from existing properties, but easier maintenance than split-redis pattern (see
- Ability to close #2334 (closed), by allowing splitting of traffic across groups at the ingress level.
- Controlling traffic of internal services to various "fleets" requires setting
- SmartCard will always point to the Service providing
gitlab-webserviceobjects will now always have a suffix. When no
deploymentsare provided, this results in
- NOTICE This will result in a "blip", because all existing resources are replaced!
.deploymentsis a key based map, where the key denotes the "name" (such as
- Resources are generated for each "deployment": Deployment, PodDiruptionBudget, HorizontalPodAutoScaler, Service, Ingress
- Ingress is separated to allow different annotations, such as those for
- Introduction of
gitlab.merge.overwriteEmptytemplate (currently located within this chart), in order to address the need for "empty wins" merging.
See Definition of done.
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 on GitLab.com
Expected (please provide an explanation if not completing)
- Test plan indicating conditions for success has been posted and passes
- Documentation created/updated
- Tests added
[ ] Integration tests added to GitLab QA [ ] Equivalent MR/issue for omnibus-gitlab opened
Closes #2334 (closed)
Revisit reference architecture descriptions, considering to populate the splitting of load between Web, API, and internal API, as with production. It may be feasible to reduce the resources for API alone, but have the larger resources & lower count for Web traffic.
gitlab: webservice: deployments: default: ingress: path: / hpa: minReplicas: 8 minReplicas: 12 puma: workerMaxMemory: 1334 threads: min: 4 max: 4 workerProcesses: 2 resources: requests: cpu: 2 memory: 2.75G api: ingress: path: /api hpa: minReplicas: 12 minReplicas: 16 puma: threads: min: 10 max: 10 workerProcesses: 1 resources: requests: cpu: 1 memory: 1.5G