> Per AI Blitz Plan §claude. Layer: 1. Repo: devops-infra-helm-charts. # 02 — Cluster fleet The repo's cluster directories under `helm-overrides//` 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`](../docs/global/SANCTITY_RULES.md)). ## Naming taxonomy ### `k8s--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--...` 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 `-dbc--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: ` - `tolerations[].key: dedicated` - Node pools are explicitly provisioned per workload class. ### Autopilot clusters Use: - `nodeSelector."cloud.google.com/compute-class": ` - `tolerations[].key: cloud.google.com/compute-class` (when applicable) - A `ComputeClass` raw manifest is dropped at `helm-overrides///computeclass/*-cc.yaml` to declare the class. See [`../docs/platform/schemas/raw-manifest-sidecar-schema.md`](../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`](../docs/platform/runbooks/pod-pending-scheduling.md). Background: [`../wiki/analyses/ADR-A3-per-cluster-scheduling.md`](../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`](../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`](../docs/global/escalation-matrix.md). ## See also - [`./03-chart-inventory.md`](./03-chart-inventory.md) — versioned siblings + multi-Contour pattern - [`./04-override-hierarchy.md`](./04-override-hierarchy.md) — how cluster + chart compose - [`./07-singletons-and-blast-radius.md`](./07-singletons-and-blast-radius.md) — `manifests/priorityclass//` - [`../contour-nodeselector-tolerations-summary.md`](../contour-nodeselector-tolerations-summary.md)