This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed devops data stores -

Cells ADR 003: One GKE Cluster per Cell


In this issue we discussed:

  • Whether we should have multiple Cells in one GKE cluster, or just a single one
  • Whether a Cell should run on one GKE cluster or multiple clusters


It was decided that we should have a single GKE cluster per Cell. The motivating factor behind this decision is simplicity: the Cells tooling will harness the existing Dedicated tooling, which in turn uses the GitLab Environment Toolkit (GET) to deploy the Reference Architectures. None of the Reference Architectures support running a single GitLab instance across multiple GKE clusters.

The decision made in ADR 002 to have one Cell per GCP project, along with the choice made above, precludes the possibility of having multiple GKE clusters serve a single Cell.


Having a single GKE cluster per Cell will make provisioning and management of a Cell easier as there will be no need to build in complex routing logic between GKE clusters.

Should we ever hit the limit on nodes per cluster (currently 15000), we will be limited to vertically scaling nodes rather than being able to spread the workload over multiple clusters. However, since our current production setup for only uses around 300 nodes, this is unlikely to occur for quite some time, if ever.


Alternatives discussed above would necessitate significant structural changes to GET, such that it would arguably be more efficient (and less disruptive) to simply not use any existing tooling. However, this goes against the overall Cells infrastructure philosophy.