DUSTIN KIRKLAND: Hello again.
I'm Dustin Kirkland, a product manager at Google,
and I'm here with one of my colleagues, David Oppenheimer.
He's a software engineer working on multi-tenancy in Kubernetes
at Google.
David, I've got a couple of questions for you
about multi-tenancy in Kubernetes.
I was at KubeCon a year ago in Berlin,
and multi-tenancy was quite the topic.
What have you heard over the last year
in terms of customer and user demands
around multi-tenancy in Kubernetes?
DAVID OPPENHEIMER: Yeah, so a year ago
it was very popular for people to just run lots of clusters
if they had different users or applications who they wanted
to isolate from one another.
And over the last year, we've either introduced
or brought to a greater level of maturity, like beta or GA,
a bunch of features in open-source Kubernetes
that enable multi-tenancy within a cluster.
DUSTIN KIRKLAND: Within a single cluster.
So that's a big change, because I've seen this as well.
Every team, every department gets their own Kubernetes
cluster.
They're completely separate management planes.
So you're saying that as of Kubernetes 1.10 now,
I should be able to run multiple tenants in a single cluster?
DAVID OPPENHEIMER: Yeah, that's right.
So some of the features that we have that are mature now are--
the most well-known one is RBAC for authorization.
So you can put very fine-grained controls
over which users or groups of users or applications
can create and update and delete which API resources on the API
server.
And so that kind of gives you control plane isolation.
And then we also have other features
that provide isolation on the node or at the container level.
For example, we have pod security policy,
which lets an administrator say, for example, no privilege
containers in this cluster or in this namespace,
or you can't run any containers as root in this namespace,
or these users can't do that.
So gives you pretty fine-grained control over what
privileges a container's running in the cluster.
And then another policy that's kind of at the node level
is network policy, which controls
which pods can communicate with which other pods so that you
can, for example, isolate namespaces from one another,
or say that you have part of your application in one
namespace and part of your application
in another namespace.
And the pods that constitute that application
should be able to talk to each other
across that namespace boundary, but not
with other namespaces in the cluster.
And so you can kind of partition your cluster
based on the groups of users and the applications
and the topology of the application using
network policy.
So between those three features, the RBAC and the network policy
and the pod security policy, we've
kind of met a lot of the needs that people
have for multi-tenancy for running enterprises or software
as a service where you want to provide isolation
between untrusted users sharing a cluster.
DUSTIN KIRKLAND: So now it's realistic for Coke and Pepsi,
as separate tenants, to run in the same cluster.
That feels reasonable at this point.
DAVID OPPENHEIMER: Well, so Coke and Pepsi
is kind of going to one extreme of the spectrum.
And so one of the things that people have asked a lot about--
and actually there's been just very recent technology
developed around solving that problem--
is kind of a hypervisor level of isolation between containers.
So when I was talking about pod security policy and network
policy earlier, those are kind of
based on the container isolation in Docker
or whatever runtime you're using,
and also what your network provider
can provide for the network policy.
But multiple containers on a node
are still sharing the same kernel.
And so if you want the level of protection
that you need, say, for Coke and Pepsi,
then you should use something like gVisor,
which was announced today, or yesterday, I
guess, from Google, which allows you
to have kind of the hypervisor level of security and isolation
between containers that are sharing a cluster.
And so I think that for the Coke and Pepsi use case,
now it's available, now it's possible to do that.
But that's a very recent development.
DUSTIN KIRKLAND: That's great.
And in terms of what's coming next, can you give us, maybe,
a brief taste of where multi-clusters
and multi-tenancy is headed in Kubernetes?
DAVID OPPENHEIMER: Sure.
There's kind of two areas where there's
ongoing work for multi-tenancy.
One of them is related to policies,
so making it easier for people to specify these policies.
Today you kind of have to be a bit of an expert in Kubernetes
in order to know how to set up the multi-tenancy policies
in a multi-tenant cluster.
So some of the work that's going on
is kind of towards unifying and making it simpler to specify
the different policies.
And then we also have work that's
kind of not related to policies, but more related to isolation.
So for example, improving the isolation between tenants
in the control plane.
So for example, different users can't DOS each other
by overloading the scheduler, overloading the API server.
So giving the controllers in the other components
of the Kubernetes control plane some notion
of how much of the control plane resources
each tenant is using so that it can kind of fairly
share the resources across those tenants,
or at least prevent them from DOSing each other,
and ensure that all the tenants can make progress
even if one of them is trying to impose a lot of load
on the scheduler or the API server,
or some other piece of the control plane.
So that's one of the key things that we're working on now
to improving the multi-tenancy story.
DUSTIN KIRKLAND: Yeah.
It's super impressive how far we've come in a year.
And I'm really looking forward to where we're going next.
David, thank you.
DAVID OPPENHEIMER: Yeah, great talking to you.
DUSTIN KIRKLAND: Yeah, thanks.