devops-infra-helm-charts-gcp/claude/02-cluster-fleet.md

Per AI Blitz Plan §claude. Layer: 1. Repo: devops-infra-helm-charts.

02 — Cluster fleet

The repo's cluster directories under helm-overrides/<cluster>/ are the canonical list of clusters this platform serves. Naming follows three patterns; each implies a different scheduling primitive set, which is why schedule fields are never copy-pasted between clusters (see ../docs/global/SANCTITY_RULES.md).

Naming taxonomy

k8s-<bu>-prd-ase1[c]

Standard GKE prod cluster, BU-owned. All in asia-southeast1, fleet meesho-admin-prd-0622. Trailing c denotes a secondary cluster for the same BU.

Known BUs in this repo:

• central, central-mqkafka
• supply, supply-dev
• demand
• dataengg, datascience, dengspark, dengspark-di, dengspark-notebook, dscispark
• dsgpu
• farmiso
• ml-platform
• admin, sec-admin, devops-admin

A few of these are GKE Autopilot clusters (different scheduling primitives — see below):

• k8s-central-prd-ase1
• k8s-dsgpu-prd-ase1
• k8s-shared-int-ase1

The rest are standard GKE.

k8s-shared-int-ase1

Shared integration (pre-prod) cluster — the only non-prod cluster in the repo. Used for integration testing of platform changes before they hit any prod cluster. Autopilot.

k8s-aurva-prd-ase1

Aurva integration (third-party security tooling). Minimal override set.

db-<numeric-id>-...

Auto-named dataplane / data-tier clusters. Each carries a minimal override set, typically kube-state-metrics and victoria-metrics-agent only. The fullnameOverride convention here is <kind>-dbc-<bu>-prd so that metrics labels stay legible across the data-tier fleet.

Autopilot vs standard scheduling

This is the dominant reason scheduling fields cannot be copy-pasted across clusters.

Standard GKE clusters

Use:

• nodeSelector.dedicated: <pool-tag>
• tolerations[].key: dedicated
• Node pools are explicitly provisioned per workload class.

Autopilot clusters

Use:

• nodeSelector."cloud.google.com/compute-class": <ComputeClass-name>
• tolerations[].key: cloud.google.com/compute-class (when applicable)
• A ComputeClass raw manifest is dropped at helm-overrides/<cluster>/<app>/computeclass/*-cc.yaml to declare the class. See ../docs/platform/schemas/raw-manifest-sidecar-schema.md.

Mismatched fields → pods strand on the wrong nodes or stay Pending. Diagnosis flow: ../docs/platform/runbooks/pod-pending-scheduling.md. Background: ../wiki/analyses/ADR-A3-per-cluster-scheduling.md.

Multi-Contour scheduling

Multi-Contour clusters run contour-external, contour-external-1, contour-internal-0, contour-internal-1, contour-internal-intra-0, contour-internal-intra-1 — each a separate Helm release pinned to its own node pool / dedicated taint or compute class. The per-cluster matrix (which Contour goes where) is documented in the repo-root contour-nodeselector-tolerations-summary.md. Always cross-reference that file before touching a Contour values override.

Cluster onboarding

Adding a new cluster directory is Layer-1 high-risk. The procedure (paired PR with the sister repo's ApplicationSet) is in ../docs/platform/procedures/onboard-new-cluster.md.

Cluster deboarding

Removing a cluster is rare and requires draining Argo Applications first. There is no in-repo procedure today; escalate to the primary owner — see ../docs/global/escalation-matrix.md.

See also

• ./03-chart-inventory.md — versioned siblings + multi-Contour pattern
• ./04-override-hierarchy.md — how cluster + chart compose
• ./07-singletons-and-blast-radius.md — manifests/priorityclass/<cluster>/
• ../contour-nodeselector-tolerations-summary.md