Cluster-per-team vs cluster-per-app vs hybrid — choosing the right granularity

Cluster granularity — how many clusters and at what boundary — is one of the most consequential architecture decisions. This lesson walks the patterns (cluster-per-team, cluster-per-app, cluster-per-environment), the trade-offs, the hybrid approach, and the operational discipline.

The granularity options

flowchart LR
    A[Cluster granularity] --> B[Cluster-per-team]
    A --> C[Cluster-per-app]
    A --> D[Cluster-per-environment]
    A --> E[Hybrid]

The options:

• Cluster-per-team. Each team gets its own cluster. 10 teams = 10 clusters.
• Cluster-per-app. Each application gets its own cluster. 50 apps = 50 clusters.
• Cluster-per-environment. One cluster per environment (dev, staging, prod). 3 clusters total.
• Hybrid. 3 environment clusters with namespaces per app/team.

Cluster-per-team

flowchart LR
    A[Team A] --> B[Cluster A]
    C[Team B] --> D[Cluster B]
    E[Team C] --> F[Cluster C]

Cluster-per-team provides isolation but is over-provisioned:

• Pros. Strong isolation; each team has its own control plane.
• Cons. 10 teams = 10 control planes (30 nodes minimum for HA each); each cluster has its own upgrade cycle; cross-team collaboration is harder.

The pattern is appropriate only for large teams with distinct infrastructure needs. Most teams do not need their own cluster.

Cluster-per-app

flowchart LR
    A[App A] --> B[Cluster A]
    C[App B] --> D[Cluster B]
    E[App C] --> F[Cluster C]
    G[App D] --> H[Cluster D]

Cluster-per-app provides maximum isolation:

• Pros. Each app has its own control plane; blast radius is per-app.
• Cons. Operationally explosive — 50 apps = 50 control planes; upgrades and monitoring multiply.

The pattern is rarely appropriate. Reserve for apps with specific regulatory requirements (PCI, HIPAA) or distinct infrastructure needs (batch analytics, ML training).

Cluster-per-environment

flowchart LR
    A[Dev cluster] --> A1[All dev workloads]
    B[Staging cluster] --> B1[All staging workloads]
    C[Prod cluster] --> C1[All prod workloads]

Cluster-per-environment is the most common pattern:

• Pros. Three clusters; manageable operational cost; clear environment boundaries.
• Cons. No isolation between apps within an environment; a bug in one app can affect others.

The pattern works for small to medium deployments where the environment boundary is the most consequential.

The hybrid approach

flowchart LR
    A[Dev cluster] --> A1["Namespace: app A"]
    A --> A2["Namespace: app B"]
    B[Staging cluster] --> B1["Namespace: app A"]
    B --> B2["Namespace: app B"]
    C[Prod cluster] --> C1["Namespace: app A"]
    C --> C2["Namespace: app B"]
    C --> C3["Namespace: app PCI"]

The hybrid: environment clusters with namespaces per app/team, and additional clusters for specific regulatory or infrastructure needs:

• Dev cluster with namespaces per app.
• Staging cluster with namespaces per app.
• Prod cluster with namespaces per app, plus a separate PCI cluster for the payment app.

The hybrid balances isolation, cost, and operational simplicity. Most production deployments use this pattern.

The decision framework

The pattern depends on team size, app count, and regulatory requirements.

The operational failure modes

Granularity choices fail for predictable reasons:

• Cluster-per-team over-provisioned. 10 teams each get a cluster; the operational cost is unsustainable.
• Cluster-per-app explosive. 50 apps each get a cluster; the upgrades and monitoring are unmanageable.
• No isolation within environment. A bug in one app affects others in the same cluster; namespaces are not enforced.
• Drift between environments. Dev, staging, prod have drifted configurations; staging does not validate production.
• Inconsistent policies. Different clusters have different PSS, NetworkPolicy, RBAC; compliance gaps.

Quiz

Production discipline

Cluster granularity in production rests on five non-negotiable elements:

• Choose based on drivers, not team or app count. Environment isolation, blast radius, compliance, geography — the driver determines the pattern.
• Hybrid is the most common. Environment clusters with namespaces per app, plus dedicated clusters for special cases.
• Avoid cluster-per-app. The operational cost is rarely justified.
• Avoid cluster-per-team for typical teams. Use namespaces within an environment cluster.
• Review quarterly. Granularity decisions drift; the review catches the drift.

Cluster granularity is an architecture decision. The discipline is to make the decision based on drivers, not on convenience, and to review it regularly.