GKE Node Pool Selection

nodePoolSelection.run(memory_request, cpu_request, priority_v2) computes the GKE node pool label for the deployed application (not the Jenkins build agent). The label is written to the Helm values as nodeSelectorValue.

Where it applies in this repo

src/com/meesho/utilities/nodePoolSelection.groovy:run

Selection logic (prd only):

Parse memory_request (Mi or Gi) and cpu_request (m or whole cores) to numeric values.
Compute ratio = memory_mb / cpu_millicores.
For non-critical priorities (cp1-cp3, up1-up3, sp1-sp3): node name is {mega|sumo}{tetra|duo}lite.
- cpu_req >= 2200m → sumo; else mega.
- ratio >= 2.5 → tetra; else duo.
For critical priorities (sp0, up0, cp0 — not explicitly listed but implied): node name is {compact|mega|sumo}{duo|tetra|octa}.
- cpu_req >= 2200m → sumo; 1000m-2199m → mega; <1000m → compact.
- ratio > 5.5 → octa; >= 2.5 → tetra; else duo.
BU-specific overrides for supply and demand apply to certain {nodevalue, ratiovalue} combinations.

Non-prd environments:

int → preprod-cost-optimized
stg/ftr/dev → {BU}-shared

The result is set as value_binding1['nodeSelectorValue'] in deployArgoCD.update_helm_repo.

Why this design

GKE node pools are heterogeneous — some are memory-optimized, some CPU-optimized. Placing services on the wrong pool wastes resources or causes throttling. The automated selection reduces per-team cognitive load: teams declare their resource needs in deployment.yaml and the pipeline finds the best matching pool.

The BU-specific overrides exist because certain BUs have limited availability of some pool types in the region — the fallback to tetra avoids scheduling failures on unavailable pools.

Deploy ArgoCD — nodeSelectorValue is computed in update_helm_repo
Infra pods — build agent pod selection (separate from app node pool)

Sources

(no raw/ sources at bootstrap)

Notes

← Wiki index

2.5 KiB Raw Blame History

GKE Node Pool Selection

Where it applies in this repo

Why this design

Related

Sources

Notes

2.5 KiB

Raw Blame History