Kubernetes has supported "soft" multitenancy since the beginning, with features such as namespaces, ResourceQuota, and resource-based scheduling. Over the years Kubernetes has added a number of sophisticated features to strengthen its multitenancy support, for example RBAC, PodSecuityPolicy, NetworkPolicy, priority/preemption, etc.
Now is a good time to take stock of Kubernetes' multitenancy support from the perspective of different types of users -- for example small organizations where everyone trusts each other, large enterprises that need isolation between many internal teams and applications sharing a cluster, SaaS providers hosting instances of their SaaS for many users in a single cluster, and infrastructure providers offering hosted "Kubernetes as a Service" -- and ask what are the key gaps remaining to be filled. Do we need hierarchical namespaces? Better mechanisms to hide shared resources so users can't see who they're sharing the cluster with? Multitenancy policies (quota, RBAC, etc.) that span namespaces, or that apply to a label-selected subset of objects within a namespace? Split-horizon DNS? Resource scheduling within the control plane to ensure no tenant monopolizes the API server, controllers, scheduler, etc.? Where on the spectrum from "soft multitenancy" to "hard multitenancy" should Kubernetes aim (and what do these terms mean, anyway?)
In this session we will discuss what multitenancy means to us as a community, and where we should focus our multitenancy efforts in 2018.
