Rethinking Workload Ownership in Shared Clusters

Multi-tenant Kubernetes is operationally convenient but conceptually messy. When several teams share a cluster, who owns a failing pod that consumes resources from one namespace but whose image is maintained by another team?

The Namespace Boundary Problem

Namespaces were designed as a soft isolation primitive, not an ownership registry. A RoleBinding tells the API server who can act on resources; it says nothing about who is responsible when those resources misbehave.

What Team-Scoped Ownership Could Look Like

One approach: a lightweight WorkloadOwner CRD that attaches a team identity and an on-call rotation reference to a label selector. Admission webhooks enforce that every workload carries an owner label.

Open Questions

Does this belong in the platform layer or in each team's app manifests? How do you handle transient ownership transfers during incident response? These are genuinely unsettled questions we are actively prototyping.