Skip to content

GitLab.com services mapped to pods for cloud native

Summary

Updated 2020-07-23

Based on the meeting to discuss how GitLab.com services will map to GitLab cloud-native https://docs.google.com/document/d/1ISa0lS0_jordPtalZjN_ycgtJrzr-8ozAZD8eLSBDf4/edit

The first charts iteration will allow for multiple services to be defined with different loadbalancers, so that we can route traffic using HAProxy like we do now for GitLab.com.

Background

Currently GitLab.com has the following high level services with distinct SLOs

  • API: all traffic to /api
  • Web: all https traffic that is not /api
  • Git: all git ssh and git https traffic

As we move these services to cloud native for GitLab.com and use the GitLab Helm chart we have pods for:

  • webservice: all https rails traffic
  • gitlab-shell: git ssh traffic

Some questions that we should start thinking about soon as this will likely require charts updates:

  • Should we keep the api/web split at the infrastructure layer? To do this we would need to create sub deployments like we do for sidekiq, as well as routing logic in nginx or if we leave haproxy in front.
  • Should we also aim to split internal api traffic so it can potentially run on its own node-pool?
  • Should we split out git https traffic from the webservice pod? The workload is much different than web traffic so I think this is something we should do at a minimum.

cc @twk3 @WarheadsSE @skarbek @ggillies @craigf @amyphillips

cc @andrewn for awareness since this will also impact our general metric collection

Edited by John Jarvis