Multi-Tenancy & Cluster Sharing at Scale

Assumes you're comfortable with ResourceQuota/LimitRange from Part 2, RBAC and NetworkPolicy hardening from Part 11, and admission control from Part 1 — this chapter is about combining those primitives into a real tenant-isolation boundary, not re-introducing any of them individually.

Table of Contents#

1. Why This Part Exists
2. The Isolation Spectrum: Soft to Hard Multi-Tenancy
3. Namespace-Based Soft Multi-Tenancy — the Baseline
4. Where Namespace Isolation Breaks Down
5. Hierarchical Namespaces — the Idea, and a Retirement Worth Knowing
6. Tenant-Aware Policy Engines: Capsule's Tenant Abstraction
7. A Worked Capsule Example: Onboarding a New Tenant
8. Virtual Clusters — vCluster Architecture Deep Dive
9. vCluster Isolation Tiers
10. Runtime Isolation for Untrusted Tenants: gVisor and Kata Containers
11. Choosing a Multi-Tenancy Model — Decision Framework
12. Noisy-Neighbor Mitigation Beyond ResourceQuota
13. Multi-Tenant Observability — Isolating Metrics and Logs Per Tenant
14. Multi-Tenant GitOps — Scoping Who Can Deploy Where
15. A Worked Numeric Example: Sizing Tenant Quotas
16. Cost Allocation and Chargeback in a Shared Cluster
17. Admission Policy as a Tenant Boundary
18. Choosing How Often to Re-Verify
19. Testing Tenant Isolation — How to Actually Verify It Holds
20. A Full Worked Scenario: Onboarding Three Teams Safely
21. When Multi-Tenancy Isn't Enough — Fleet Management as the Escape Hatch
22. Part 13 CLI Cheat Sheet
23. A Tenant Onboarding Checklist
24. Common Mistakes and Interview Traps
25. Worked Practice Problems
26. Summary and What's Next

Why This Part Exists#

Every mechanism this chapter needs already exists somewhere earlier in this series — ResourceQuota and LimitRange from Part 2, RBAC and NetworkPolicy from Part 11, admission control from Part 1 — but no part so far has addressed the actual platform-engineering question a growing organization eventually has to answer: "how many teams can safely share one cluster, and where does that stop being true?" This is squarely a platform-engineering concern — per the industry research behind this series' chapter list, platform engineering is forecast to reach roughly 80% enterprise adoption, and multi-tenancy design is one of its most concrete, recurring decisions.

The throughline system gains new neighbors in this chapter: alongside the existing checkout team, imagine a catalog team and a newly onboarded recommendations team, all sharing the same cluster the checkout namespace already lives in. Every worked example in this chapter treats these three teams as cooperative but independent — exactly the trust profile most internal platforms are actually designing for.

The Isolation Spectrum: Soft to Hard Multi-Tenancy#

Every multi-tenancy approach sits somewhere on one spectrum: how much of the underlying cluster does a tenant actually get to see and potentially affect, versus how much operational overhead and cost does providing that isolation require.

Namespace-Based Soft Multi-Tenancy — the Baseline#

Every stronger model in this chapter builds on top of this one — a namespace per tenant, RBAC scoping each tenant's ServiceAccounts and human users to their own namespace, a ResourceQuota capping their consumption, and a default-deny NetworkPolicy (Part 11) as the network boundary.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: recommendations-quota
  namespace: recommendations
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
    pods: "50"
    persistentvolumeclaims: "10"
    services.loadbalancers: "0"   # a common tenant restriction: no direct cloud LB provisioning

This baseline is genuinely sufficient for a large fraction of real internal platforms — most organizations aren't isolating mutually hostile parties, they're isolating cooperative teams who occasionally make mistakes, and RBAC plus quotas plus NetworkPolicy stops the overwhelming majority of accidental cross-tenant impact at a fraction of the operational cost of anything stronger.

Where Namespace Isolation Breaks Down#

The honest limitation of the namespace baseline is what it doesn't separate — and every stronger tier in this chapter exists specifically to close one of these gaps.

Admission webhooks deserve the same scrutiny for an identical reason: a ValidatingWebhookConfiguration or MutatingWebhookConfiguration is cluster-scoped, and its namespaceSelector/rules determine which objects across the entire cluster it intercepts — a tenant's own policy engine or operator, installed with a webhook scoped too broadly, can start validating or mutating every other tenant's objects, not just its own. This is the same failure shape as the CRD risk above, applied to a different cluster-scoped kind.

Hierarchical Namespaces — the Idea, and a Retirement Worth Knowing#

Hierarchical namespaces let a parent namespace's policies (RBAC, ResourceQuota, NetworkPolicy) propagate automatically to child namespaces, so a platform team can define a tenant's guardrails once at the parent level instead of copy-pasting the same RBAC/quota YAML into every namespace a growing team spins up.

This capability lived in the hierarchical-namespaces (HNC) project from the Kubernetes Working Group for Multi-Tenancy — worth naming precisely because that repository is now retired, per its own GitHub archive status, and is not the recommendation to reach for on a new platform build today. The underlying idea — inherited, hierarchical policy propagation — remains valuable and has been carried forward primarily by tenant-policy engines like Capsule (next section), which implement a comparable propagation model as one feature of a broader, more actively maintained tool rather than as a standalone, now-unmaintained controller.

Tenant-Aware Policy Engines: Capsule's Tenant Abstraction#

Capsule (a CNCF Sandbox project) introduces a Tenant custom resource that groups one or more namespaces under a single owner and a single set of enforced policies — the platform team defines a Tenant once, and Capsule's admission webhooks enforce it consistently across every namespace that tenant creates.

The self-service angle is the practical win here — without Capsule, a platform team is either the bottleneck for every new namespace request (they must apply the RBAC/quota/NetworkPolicy boilerplate by hand each time) or trusts every team with enough cluster-wide permission to create namespaces freely, which reintroduces the cluster-scoped-resource risk from the previous section. A Tenant object lets the tenant owner create new namespaces within their own tenant boundary self-service, with Capsule's webhooks guaranteeing every one of them inherits the same guardrails automatically.

A Worked Capsule Example: Onboarding a New Tenant#

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: recommendations-team
spec:
  owners:
    - name: recommendations-lead@company.com
      kind: User
  namespaceOptions:
    quota: 5   # max namespaces this tenant can self-service create
  resourceQuotas:
    scope: Tenant   # aggregated across every namespace the tenant owns, not per-namespace
    items:
      - hard:
          requests.cpu: "30"
          requests.memory: 60Gi
          pods: "80"
  networkPolicy:
    ingress:
      - from:
          - namespaceSelector:
              matchLabels:
                capsule.clastix.io/tenant: recommendations-team   # only same-tenant traffic by default

# The tenant owner, with no cluster-admin access at all, can now self-service:
kubectl create namespace recommendations-experiments \
  --as recommendations-lead@company.com
# Capsule's webhook validates this against the Tenant's namespaceOptions.quota
# and automatically applies the Tenant's RBAC/quota/NetworkPolicy templates

The scope: Tenant ResourceQuota aggregation is worth calling out specifically — a per-namespace ResourceQuota (the Part 2 mechanism) caps each namespace independently, which a tenant with namespaceOptions.quota: 5 could otherwise use to multiply their effective total allocation by simply creating more namespaces. Tenant-scoped aggregation closes that loophole by summing usage across every namespace the tenant owns against one shared ceiling.

Virtual Clusters — vCluster Architecture Deep Dive#

A vCluster runs an entire, real, additional Kubernetes control plane — its own API server, its own etcd (or a lightweight equivalent), its own controller manager — inside a single namespace of the underlying "host" cluster, giving a tenant something that looks and behaves like their own dedicated cluster while still sharing the host cluster's actual compute nodes.

The "sync" step is the architectural core of how this works: a tenant creates a Pod against the virtual API server exactly as if it were a real, independent cluster; vCluster's synchronization controller translates that object down into a real Pod on the host cluster (in the vCluster's backing namespace), where it actually runs on shared physical nodes. The tenant never sees the host cluster's API server, other tenants' namespaces, or any cluster-scoped objects outside their own virtual control plane — from inside a vCluster, even kubectl get namespaces only shows namespaces the tenant themselves created, solving the cluster-scoped-resource visibility gap that plain namespace isolation cannot.

vCluster Isolation Tiers#

vCluster's isolation strength is not one fixed level — it's configurable per deployment, trading cost against isolation strength the same way the isolation-spectrum diagram earlier in this chapter suggested.

Each tier only changes the underlying compute-sharing story — the virtual control plane's own isolation (separate API server, separate etcd, invisible host-cluster internals) is identical across all three. This means a platform team can start a tenant on Shared Nodes for cost efficiency and move them to Dedicated or Private Nodes later purely as an infrastructure change, without the tenant's own workload manifests, RBAC, or CRDs needing to change at all — the virtual cluster they interact with looks the same regardless of which physical isolation tier backs it.

Runtime Isolation for Untrusted Tenants: gVisor and Kata Containers#

Every model so far still shares the host kernel for at least some tier of tenant — gVisor and Kata Containers address the "shared kernel" risk specifically, by changing what actually executes a container's syscalls.

A third option worth naming alongside these two: AWS Fargate for EKS (Part 7) and similar serverless-container offerings use a comparable microVM-per-pod model (built on the same Firecracker technology Kata Containers can also use as a backend) as their default isolation posture, not an opt-in RuntimeClass — a relevant data point when comparing self-managed Kata adoption against simply running sensitive tenant workloads on a managed serverless-container tier instead.

These are selected per-workload via a RuntimeClass object, not cluster-wide — a platform can run most pods on standard runc for performance and reserve gVisor or Kata specifically for the namespaces/tenants where "this tenant's code might be actively malicious, not just occasionally buggy" is a genuine possibility, such as a platform running arbitrary customer-submitted code.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
spec:
  runtimeClassName: gvisor   # opts this specific pod into the stronger runtime

Choosing a Multi-Tenancy Model — Decision Framework#

Noisy-Neighbor Mitigation Beyond ResourceQuota#

ResourceQuota caps a tenant's total declared consumption, but says nothing about where their pods land or how they're prioritized against other tenants' pods under real contention — three more primitives, all covered individually in earlier parts, combine to close that gap.

# 1. A PriorityClass per tenant tier — determines who gets evicted first
# under real node pressure (Part 2's preemption mechanics)
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: tenant-standard
value: 100
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: tenant-premium
value: 1000
---
# 2. Taints reserving a node pool for one tenant tier only
# kubectl taint nodes -l tenant-tier=premium dedicated=premium-tenants:NoSchedule

Combining these with the ResourceQuota baseline turns "no single tenant can request too much in total" into "no single tenant can crowd out another tenant's pods when the cluster is genuinely under pressure" — a meaningfully stronger guarantee, since quotas alone say nothing about eviction order or physical placement once contention actually happens.

Multi-Tenant Observability — Isolating Metrics and Logs Per Tenant#

A shared Prometheus/Loki stack scraping every tenant's namespace by default creates two problems this chapter's isolation model needs to answer: can Tenant A query Tenant B's metrics/logs, and can Tenant B's high-cardinality metrics degrade query performance for everyone else sharing that same backend?

# A query scoped to exactly one tenant via Loki's native multi-tenancy header —
# the backend rejects this if the caller's auth doesn't match the claimed tenant
curl -H "X-Scope-OrgID: recommendations" \
  http://loki.observability.svc.cluster.local:3100/loki/api/v1/query \
  --data-urlencode 'query={namespace="recommendations"}'

Multi-Tenant GitOps — Scoping Who Can Deploy Where#

A shared cluster running GitOps (the automation-cicd-gitops tutorial series covers GitOps mechanics in full — this section is specifically the multi-tenancy angle) needs the deployment pipeline itself scoped per tenant, or GitOps becomes a way to bypass every RBAC boundary this chapter has built.

# ArgoCD AppProject — scopes what a tenant's own Application objects
# are allowed to deploy, and where
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: recommendations-team
  namespace: argocd
spec:
  sourceRepos:
    - "https://github.com/company/recommendations-*"
  destinations:
    - namespace: "recommendations*"
      server: "https://kubernetes.default.svc"
  clusterResourceWhitelist: []   # deliberately empty — no cluster-scoped resources allowed
  namespaceResourceBlacklist:
    - group: ""
      kind: ResourceQuota   # tenants can't self-service raise their own quota via GitOps

The clusterResourceWhitelist: [] and quota-blacklist lines matter for exactly the same reason RBAC should never grant CRD lifecycle permissions to a tenant — without them, a tenant's Git repository becomes an alternate, unmonitored path to the same over-privileged actions this chapter has spent several sections closing off through RBAC and admission policy. GitOps doesn't bypass Kubernetes RBAC on its own (ArgoCD still applies objects through the API server as whatever identity it's configured to run as), but a single shared, overly-permissive ArgoCD ServiceAccount used across every tenant's AppProject re-creates exactly the over-broad-grant risk this whole chapter exists to avoid — scoping AppProject per tenant is what keeps GitOps consistent with the rest of the tenant boundary rather than quietly undermining it.

A Worked Numeric Example: Sizing Tenant Quotas#

Abstract guidance ("set a reasonable quota") is less useful than working through the actual math a platform team would do — here's a realistic sizing exercise for the recommendations team's ResourceQuota introduced earlier in this chapter.

The team runs 3 services, each currently deployed at 4 replicas with 500m CPU / 1Gi memory requests per pod, plus headroom for Part 12's HPA to scale up to double that under load:

spec:
  hard:
    requests.cpu: "15"      # rounded up from 14.4
    requests.memory: 30Gi   # rounded up from 28.8Gi
    limits.cpu: "20"        # limits set higher than requests per Part 2's Burstable QoS pattern
    limits.memory: 32Gi

Sizing a quota from a real HPA ceiling, not a guess, is the actual discipline here — a quota set below what a tenant's own HPA maxReplicas could legitimately request under real load doesn't stop overspend, it just relocates the failure: instead of a clean cost conversation, the tenant's pods start failing scheduling (Part 10's Pending-pod diagnostic tree) the moment real traffic actually needs to scale, which reads to the tenant as a platform outage rather than the capacity-planning gap it actually is.

Cost Allocation and Chargeback in a Shared Cluster#

A shared cluster's bill is one number from the cloud provider — attributing it back to individual tenants requires tagging and aggregation that Kubernetes doesn't provide natively.

kubectl get resourcequota -A -o json | \
  jq -r '.items[] | "\(.metadata.namespace): \(.status.used["requests.cpu"]) / \(.status.hard["requests.cpu"]) CPU"'

Admission Policy as a Tenant Boundary#

Part 11 covered Kyverno/OPA Gatekeeper for security policy — the same admission-control mechanism is equally central to multi-tenancy, enforcing rules that RBAC alone can't express.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-storageclass-per-tenant
spec:
  validationFailureAction: Enforce
  rules:
    - name: only-standard-storageclass-for-non-platform-tenants
      match:
        any:
          - resources:
              kinds: ["PersistentVolumeClaim"]
              namespaces: ["catalog", "recommendations", "checkout"]
      validate:
        message: "Tenant namespaces may only use the 'standard' StorageClass"
        pattern:
          spec:
            storageClassName: "standard"

RBAC answers "who can create what kind of object" — it has no vocabulary for "what values are allowed inside that object once created," which is exactly the gap a policy engine fills. RBAC alone cannot stop a tenant with legitimate create permission on PersistentVolumeClaim objects from requesting an expensive, high-performance StorageClass never intended for their tier — only an admission policy inspecting the object's actual field values can enforce that kind of tenant-tier boundary.

Choosing How Often to Re-Verify#

A one-time isolation test at onboarding proves the boundary was correct on day one — it says nothing about whether a subsequent, unrelated platform change quietly reopened a gap months later.

Treating this as a scheduled, low-effort recurring check (the small script from the previous section, run on a cadence or wired into the same pipeline pattern Part 15 covers for cluster upgrades) costs far less than discovering an isolation gap the hard way, during an actual cross-tenant incident.

Testing Tenant Isolation — How to Actually Verify It Holds#

Every control in this chapter can be configured correctly on paper and still fail in practice — the only way to know tenant isolation actually holds is to actively try to violate it, the same "verify, don't just configure" discipline Part 11 applied to security controls generally.

# 1. Cross-namespace RBAC check: can tenant A's ServiceAccount read tenant B's Secrets?
kubectl auth can-i get secrets \
  --as=system:serviceaccount:recommendations:default -n checkout

# 2. Cross-namespace network check: does NetworkPolicy actually block traffic
# from a pod outside the expected tenant boundary?
kubectl run isolation-test --rm -it --image=busybox -n catalog \
  -- wget -T 3 -O- http://checkout-svc.checkout.svc.cluster.local

# 3. Quota-bypass check: can the tenant exceed their aggregate quota by
# creating an additional namespace, if Tenant-scoped aggregation isn't enforced?
kubectl create namespace recommendations-shadow --as recommendations-lead@company.com

A Full Worked Scenario: Onboarding Three Teams Safely#

Bringing every tier in this chapter together for a platform team onboarding checkout, catalog, and a brand-new recommendations team onto one shared cluster:

Working through the actual decision for recommendations: it's a standard internal service, doesn't need its own CRDs, and the team is cooperative with no regulatory sensitivity — the correct-sized answer is the cheapest one on the isolation spectrum that still solves the real problem: a Capsule Tenant wrapping one or more namespaces, with the standard ResourceQuota/RBAC/NetworkPolicy guardrails from earlier in this chapter. Reaching for a vCluster or a separate physical cluster here would be over-engineering relative to the actual risk being managed — a useful, generally applicable lesson: isolation strength should be sized to the tenant's actual trust level and workload needs, not applied uniformly at the strongest tier "to be safe" everywhere.

When Multi-Tenancy Isn't Enough — Fleet Management as the Escape Hatch#

Every tier this chapter covers still shares something — at minimum, the cloud account and billing boundary. When even a Private-Nodes vCluster or a fully separate physical cluster is the right call per the decision framework above, the new problem becomes operating potentially dozens of separate clusters consistently — which is exactly what fleet-management tooling exists to solve.

The tradeoff this escape hatch makes explicit: separate clusters solve the "shares nothing" isolation requirement completely, but only if the fleet-management layer actually keeps every cluster consistently configured — without one, "give every tenant their own cluster" quietly becomes "give every tenant their own snowflake cluster that drifts further from every other one over time," which is a worse operational outcome than the shared-cluster noisy-neighbor problems this chapter otherwise solves. Choosing separate clusters as an isolation tier is really choosing separate clusters plus a real fleet-management investment — treating it as a lighter-weight option than vCluster because "it's just normal clusters" is a common and costly underestimate.

Part 13 CLI Cheat Sheet#

A Tenant Onboarding Checklist#

Every control this chapter covers, as a single checklist a platform team can run through for each new tenant — the kind of artifact worth keeping next to Part 10's troubleshooting runbook.

• Namespace(s) created, scoped under a Tenant object if using Capsule (or an equivalent grouping)
• RBAC: tenant's human users and ServiceAccounts scoped to their own namespace(s) only, no wildcard apiGroups/resources (Part 11)
• ResourceQuota sized from real projected usage plus HPA headroom, aggregated at the tenant level if the tenant can create more than one namespace
• Default-deny NetworkPolicy applied, with explicit allow rules for every real dependency including DNS and monitoring scrape traffic (Part 10, Part 11)
• PriorityClass assigned matching the tenant's tier, if running a tiered platform
• Admission policy confirms the tenant cannot create cluster-scoped objects (CRDs, ClusterRoles, webhooks) or select a disallowed StorageClass/RuntimeClass
• Observability isolation confirmed — tenant's Grafana/dashboard access scoped to their own tenant ID at the backend level, not just a dashboard filter
• GitOps AppProject (or equivalent) scoped to the tenant's own repos and destination namespaces
• Isolation test suite (previous section) run once against the new tenant before considering onboarding complete

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: A platform team gives every internal team a namespace, RBAC scoped to that namespace, and a ResourceQuota. Six months later, one team's misbehaving custom controller has degraded API server latency for the entire cluster. What isolation gap does this reveal, and which tier in this chapter's spectrum would have prevented it?

Answer: Namespace-based RBAC and quotas cap what a tenant can do inside their own namespace, but they don't isolate shared control-plane resources like API server request capacity — a controller with an inefficient or excessive watch/list pattern degrades API server performance for every tenant sharing that same API server, regardless of namespace boundaries. A vCluster would have given that team their own virtual API server, entirely isolating this specific failure mode from other tenants' experience of the shared cluster (the underlying nodes would still be shared, but the control-plane contention would not be).

Problem 2: A team's platform documentation still recommends installing the Hierarchical Namespace Controller (HNC) for propagating quota and RBAC to child namespaces. What should a reviewer flag, and what should the documentation point to instead?

Answer: HNC is a retired project (per its own GitHub repository status) and shouldn't be recommended as the path for new platform work, regardless of how well-established it appears in older material. The underlying capability it provided — inherited policy propagation across related namespaces — is available today via a currently-maintained tenant-policy engine like Capsule, which implements a comparable model (a Tenant grouping namespaces with propagated RBAC/quota/NetworkPolicy) as an actively maintained alternative.

Problem 3: A tenant with legitimate create permission on PersistentVolumeClaim objects in their namespace repeatedly requests an expensive, high-IOPS StorageClass reserved for a different tier of customer. RBAC review confirms their Role is correctly scoped to only PersistentVolumeClaim resources — no over-broad grant is found. What's the actual gap, and how is it closed?

Answer: RBAC controls which kinds of objects a subject can act on, not what values those objects may contain — a Role correctly scoped to PersistentVolumeClaim still has no vocabulary for restricting which storageClassName a tenant may request within that resource kind. The gap is closed with an admission policy (Kyverno/OPA Gatekeeper, Part 11) validating the PVC's actual field values against the tenant's allowed StorageClasses, layered on top of an otherwise-correct RBAC configuration rather than as a replacement for it.

Problem 4: A platform team decides that, since Capsule already scopes tenants well, they'll skip a fleet-management tool and give their three most sensitive tenants entirely separate physical clusters provisioned by hand. A year later, the three clusters are on different Kubernetes versions and have drifted NetworkPolicy configurations. What was the actual decision the team made without realizing it, and what should they have planned for upfront?

Answer: Choosing separate physical clusters as an isolation tier is really choosing separate clusters plus an ongoing fleet-consistency commitment — without a fleet-management layer (Cluster API, Rancher Fleet, or equivalent GitOps-across-clusters tooling) actively pushing consistent configuration and upgrade schedules to all of them, each cluster inevitably drifts independently over time, since nothing is reconciling them back to a shared baseline. The team should have planned for a fleet-management investment at the same time they chose the separate-clusters isolation tier, not treated it as a simpler, lower-effort option than a shared-cluster approach with vCluster or Capsule.

Summary and What's Next#

Every tier in this chapter is additive, not exclusive — a mature platform typically runs plain namespace isolation as the universal floor for every tenant, layers Capsule-style policy enforcement on top once self-service scale demands it, and reserves vCluster or separate clusters for the specific tenants whose trust level or regulatory requirements genuinely need it, rather than picking exactly one model cluster-wide.

Multi-tenancy is a spectrum, not a single decision — plain namespaces with RBAC, quotas, and NetworkPolicy solve the majority of real internal-platform cases cheaply; Capsule-style tenant-policy engines add self-service at scale; vCluster adds genuine control-plane isolation for tenants that need it; and gVisor/Kata add kernel-level isolation for the specific risk of an actively malicious, not just occasionally buggy, workload. The one consistent lesson across every tier is sizing isolation strength to actual tenant trust and workload needs, rather than defaulting to the strongest (and most expensive) option everywhere.

Part 14 turns to a workload type this chapter's isolation models increasingly need to account for: AI/ML workloads. GPU scheduling, device plugins, and the platform patterns for serving models at scale are, per this series' industry research, the fastest-growing driver of new Kubernetes adoption in 2026 — and several of this chapter's multi-tenancy patterns (chargeback, RuntimeClass-based isolation, dedicated node pools) apply directly to a cluster sharing expensive GPU capacity across teams. GPU capacity in particular sharpens every tradeoff this chapter walked through: a GPU node sits idle at real dollar cost the moment it isn't scheduled, which makes the noisy-neighbor mitigation and cost-chargeback sections above far higher-stakes for a shared GPU pool than for the general-purpose CPU/memory tenancy this chapter mostly illustrated with.