The moment shared stops feeling safe
Sharing GKE clusters across teams works fine at first — a handful of Applications, everyone reasonably careful, nothing colliding. It starts to feel different once a team's Application, deployed without much scrutiny, consumes more CPU than expected and something else on the same cluster slows down. Or a namespace ships without the network policy every other namespace has, and nobody notices until a security review asks why. The platform team gets asked a question they can't fully answer: can we actually trust that one team's Application won't affect another's?
One cluster per team solves it — at a cost most teams can't justify
Cluster per team
Strong isolation, real operational and cost multiplication — more clusters to patch, monitor, and upgrade, more platform overhead per team added, harder to justify as team count grows.
Shared clusters, layered isolation
Namespace boundaries, identity, quotas, and network policy combine to isolate each Application Environment on a shared cluster — practical isolation without a cluster-per-team cost curve.
Neither extreme — one cluster for everyone, or a cluster for every team — is where most organizations should land. The practical middle is layered isolation on shared infrastructure, applied consistently rather than configured by hand per namespace.
What actually isolates a shared cluster
No single control is sufficient by itself — layering is the point. Each Application Environment gets its own namespace, with resource requests and limits generated from platform defaults rather than a developer guessing at CPU and memory numbers. Runtime identity is scoped per Application and Environment through Workload Identity Federation, limiting access to Google Cloud resources to the permissions explicitly granted to that workload. Network policy is generated or managed centrally, rather than left to each team to configure — or forget to configure — on their own. And the combination is what matters: quotas without network policy still let a misbehaving Application talk to things it shouldn't; network policy without quotas still lets one Application exhaust shared resources.
This governance model is the same one covered in more depth on Governance and Policy — this page is about the specific moment multi-tenant trust starts to strain, and why layered isolation is what actually holds it together.
Be honest about what isolation actually means
Namespace isolation is a practical tenancy boundary for teams that are all inside the same trust boundary — it is not equivalent to hard isolation against a hostile or actively malicious tenant. If your governance requirement is closer to "we cannot trust this team's Application at all," the right answer is a stronger boundary — a separate cluster or dedicated sandboxing — not a policy applied more strictly on top of shared infrastructure. Vertro's model is built for the common case: multiple internal teams, reasonably trusted, that still need consistent, enforced boundaries between them.
Consistency the platform team can actually verify
Policy applied through admission control and reconciled continuously from Git means a namespace can't quietly drift out of compliance without someone noticing — the platform team doesn't have to manually audit every team's configuration to know whether the standard is actually being followed. That's the difference between governance that's documented and governance that's checked.
Frequently asked questions
Does namespace isolation protect us from a hostile or compromised tenant?
Namespace isolation is one practical layer of tenancy in a shared cluster, combined with identity, quotas, and network policy. It is not equivalent to hard isolation against a hostile tenant, and Vertro does not claim otherwise — teams that need that level of isolation should evaluate cluster-per-tenant or stronger sandboxing separately.
Why share clusters across teams instead of giving each team its own?
A cluster per team provides stronger isolation, but it also multiplies operational and cost overhead. For Applications operating within the same organizational trust boundary, shared clusters with layered isolation can provide a practical balance between governance, efficiency, and operational complexity.
Can one team's Application exhaust resources needed by another team's Application?
ResourceQuota and LimitRange settings generated per Application Environment establish expected operating boundaries, reducing the chance that one Application's resource usage accidentally starves another sharing the same cluster.
Does every team need to configure their own network policy?
No. Network policy is generated or managed centrally as part of the platform-owned Kubernetes configuration, rather than left to each Application team to define correctly on their own.
How do we know if a team's Application is violating platform policy?
Admission controls can reject configuration that violates enforced policy, while Config Sync continuously reconciles platform-owned configuration from Git. This reduces reliance on manual review, although coverage depends on the policies and controls the organization has enabled.