►
From YouTube: The Future of Multi-Tenancy in Kubernetes - Tasha Drew, VMware; Adrian Ludwin, Fei Guo, Jim Bugwadia
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
The Future of Multi-Tenancy in Kubernetes - Tasha Drew, VMware; Adrian Ludwin, Google; Fei Guo, Alibaba; Jim Bugwadia, Nirmata
Applications need multi-tenancy. Shared services need multi-tenancy. Internal users need multi-tenancy. Tenancy requires segmentations at all layers of the infrastructure and services stack, not to mention surrounding capabilities like charge back, service priority, and cost optimization. Where is it all going? What is the future of multi-tenancy? Join the leads of the upstream working group for multi-tenancy to find out! We will discuss how we see users and entrprises leveraging multi-tenancy, the tools and capabilities our group and the rest of Kubernetes upstream community have been building to make multi-tenancy … tenable … and answer audience questions.
A
B
C
D
A
So
a
quick
overview
of
what
we
do
in
the
kubernetes
multi-tenancy
working
group,
so
we
are
working
on
defining
the
mult.
The
models
of
multi-tenancy
kubernetes
will
just
support,
discussing
and
executing
upon
work.
That
needs
to
be
done
to
support
these
models,
creating
conformance
tests
that
prove
models
can
be
built
and
used
in
production
environments.
I'm
the
chair,
along
with
sanjeev
rampo
and
the
projects
that
we've
been
incubating
and
actually
graduated.
Two
of
these
are
the
virtual
cluster
project,
the
hierarchical
namespace
controller
and
the
multi-tenancy
benchmark
project.
A
A
If
you
want
to
talk
with
any
of
us
about
ideas
or
questions,
you
have
around
multi-tenancy
or
projects,
you
may
be
working
on
yourselves
that
you'd
like
to
talk
about
potentially
incubating
or
partnering
with
us
on
we're
very
active
in
slack,
and
if
you
want
to
attend
our
meetings
and
see
our
mailing
list,
then
the
only
thing
you
need
to
do
is
join
this.
Google
group
that
is
linked
right
here.
We
have
meetings
every
two
weeks,
tuesday,
at
11
a.m.
A
Once
you
join,
the
google
group
you'll
have
access
to
our
agenda
document
that
you
can
add
agenda
items
to
our
meetings
that
we'll
address
as
time
permits
based
on
how
many
topics
we
have,
and
we
really
encourage
people
to
join
chat
with
us
and
check
out
our
code
so
moving
into
the
main
content
of
today's
chat.
What
we're
going
to
be
doing
is
a
round
table
with
myself,
adrian
fay
and
jim
around
the
future
multi-tenancy
and
kubernetes.
A
B
Now
that
can
be
a
bit
of
a
double-edged
sword.
Sometimes
it
can
be
harder.
If
your
goal
is
to
isolate
tenants
from
each
other
as
much
as
possible,
sometimes
it
can
be
harder
to
isolate
them
than
it
is
within
one
cluster,
and
so
I
think
we'll
probably
get
to
that.
But
in
my
mind
those
are
the
two
sort
of
key
use:
cases
multi-team
and
sas
and
and
the
benefits
are
cost
savings
and
maybe
more
marginally
administered
savings.
A
C
C
So
we
be
beyond
on
this
three
concept
of
view,
so
the
the
the
community
actually
developing
different
solutions,
but
following
the
same
concept,
for
example,
loft
has
bring
up
a
v
cluster,
which
conceptually
very
close
to
virtual
class
that
we
are
posing
in
this
working
group,
and
we
can.
We
have
another
effort
called
capsule,
which
is
very
close
to
the
concept
that
hierarchical
namespace
developing
our
working
group.
So
that's
so
so.
C
D
Yeah,
certainly
so
I
think
you
know,
just
in
addition
to
some
of
those
projects,
some
different
patterns
that
we
also
see-
and
there
was
a
recent
blog
post-
also
put
out
in
the
community
where
folks
were
talking
about.
You
know
using
policy
engines
or
admission
controllers
and
being
able
to
inject
node,
selectors,
etc,
to
isolate
workloads
or
to
get
you
know,
sort
of
stronger
isolation
for
different
tenants
right,
but
going
back
to
the
two
major
use
cases
that
adrian
talked
about.
B
B
The
quota
like
these
are
all
building
blocks
that
are
in
upstream
kubernetes
that
were
designed
to
make
it
easier
to
share
a
cluster
among
tenants
whether
those
tenants
are
teams
or
sas
consumers
or
even
different
workloads
that
are
run
by
the
same
team
but
yeah.
There
is
this
kind
of
explosion
of
options
that
are
in
the
community.
B
One
of
them
is
the
project
that
I
started
hierarchical
namespaces,
which,
as
the
name
implies,
is
trying
to
take
a
fairly
well
established,
construct
from
upstream
case,
which
is
namespaces
and
just
add
a
couple
of
features
of
them
to
make
them
more
usable
in
more
contexts
and
we're
getting
some
pretty
good
adoption.
There
mercari
actually
just
announced
that
they're
using
us
in
prod
and
we've
got
some
other
people,
some
other
large
companies
on
slack
who
have
been
openly
contributing.
B
I
haven't
gotten
permission,
so
I
probably
shouldn't
say
their
name,
but
you'll
see
them
if
you
join
us
on
slack,
and
so
it's
clear
that
these
additions
are
meeting
a
need,
but
I
think
that
if
you
look
back
at
you
know
the
first
question:
what
are
the
patterns
we
haven't?
Seen?
A
lot
of
new
patterns
show
up
what
we've
seen
are
like
in
these
two
established
patterns.
We've
seen
people
with
different
needs
at
the
margins,
but
they've
kind
of
settled
into
as
both
things
and
said,
sort
of
these
three
classic
solutions.
B
One
of
them
is
based
on
name
spaces.
One
of
them
is
based
just
on
multi-cluster
and
then
the
last
one
is
based
on
virtual
clusters,
which
is
basically
you
run
multiple
control
planes
within
one.
You
know
overarching
cluster,
and
so
I
would
say
at
this
point
even
though
there's
a
lot
of
different
solutions,
they've
all
kind
of
coalesced
into
one
of
those
three
groupings
which
is
nice
because
it
shows
the
maturation
of
multi-tenancy
in
the
ecosystem.
A
C
C
I
think,
as
a
best
practice
when
we
talking
about,
if
you
want
to
support
using
multi-tenancy
solution
to
support
internet
team-
that's
probably
okay,
with
native
long-time
solutions
support.
But
if
you
go
beyond
that,
we
we
kind
of
highly
recommend
to
use
you
know
sandbox
long
time
to
prevent
any
candidates
to
get
good
access
to
the
melt.
I
think
carter
is
one
of
the
solutions.
The
market
angry-
maybe
you
can
mention
generally
describe
the
divisor,
which
is
how
google
use
this.
B
B
It's
just
you
basically
set
a
new
runtime
class
in
for
your
pod
and
you
just
got
the
sandbox
and
as
long
as
you
don't
use
an
unsupported
feature
like
certain
system
calls
or
gpus
everything
should
just
work,
maybe
at
a
slight
performance
penalty.
However,
if
you
really
are
worried
about
tenants
attacking
each
other
maliciously,
that's
when
you
want
to
that's
when
you
should
at
least
consider
simply
using
different
clusters
for
everybody.
It's
the
the
amount
of
work
that
it
takes
to
go
through
to
harden
kubernetes
is
not
impossible.
B
People
do
do
it,
but
you
have
to
be
very
clear
on
what
you're
getting
for
that
is.
The
cost
savings
really
worth
it
is
the?
Is
the
management
savings
really
worth
it?
If
not,
especially,
if
you're
using
a
cloud
provider,
it
might
be
worth
your
while
to
go
off
and
just
give
everybody
their
own
cluster
if
you're
managing
the
hardware
yourself.
C
B
Yeah,
it's
funny.
We
don't
have
anybody
from
the
eks
team
here,
but
that
you
can
use
I'm
not
sure
if
azure
has
something
similar,
but
you
can
use
fargate
as
a
back
end
if
you're
on
eks
and
that
then
you're
relying
at
least
for
your
runtime
security
to
rely
on
fargate,
managing
your
multi-tenancy
and
not
your
own
vm,
like
not
your
own
vm
setup.
B
Now,
if
that's
what
you
have,
if
you're
doing,
you
better
really
understand
what
the
multi-tenancy
implications
are
of
fargate,
which
I
don't
I
don't
work
on
it,
I'm
not
an
expert,
but
that
now
becomes
part
of
your
security
story.
But
I
think
in
some
cases
using
some
sort
of
serial
solution
could
be
another
potential
path,
depending
on
your
vendor
and
your
comfort
with
different
security
risks.
A
C
So,
to
be
honest,
so
so,
when
we
when
we,
when
we
think
about
how
to
resolve
the
multi-tenancy
power,
I
mean
the
grenade
is
the
first.
You
know
option
that
the
community
of
mine
is
trying
that
upstream
to
support
it,
but
we
we
have
trying
to.
We
talk
to
different
people,
so
we
have
so
many.
We
are
cap,
so
many
things
need
to
be
re-archived
and
people
kind
of
reluctant
to
do
that
in
terms
of
the
accommodation
issues,
but
luckily
in
the
community.
C
So,
based
on
my
understanding,
because
this
drawback
of
the
adoption-
I
I
think
the
actual
people
finally
decide-
don't
do
that
they
will
do
something
more
similar,
like
the
contribution
as
a
service
type
of
solution
to
using
their
multi-tenancy
use
cases.
So
that's
at
least
one
attempt
that
I
have
seen
so
yeah.
A
And
so,
if
you're
kind
of
looking
at
current
today,
any
given
release
of
kubernetes
and
saying
hey,
I'm
just
going
to
take
this
and
harden
it.
Keep
in
mind
that
if
you
can't
continue
to
consume
updates-
and
if
you
can't
stay
current
with
the
latest
releases,
what
you
have
ends
up
starting
to
look
like
a
hardened
fork
that
isn't
compatible
with
the
rest
of
the
ecosystem.
So
keeping
upgrades
in
mind.
A
It's
it's
a
lot
of
work,
but
it
ends
up
being
a
pretty
crucial
component
of
a
solution
you
might
add
here
so
the
I
think
that
one
thing
that
comes
up
consistently
when
we're
talking
about
this
space
is:
should
we
change
the
kubernetes
api
to
be
secure,
like
hardened
multi-tenancy
by
default
right
and
that's
a
huge
lift
and
a
big
architectural
change
on
the
back
end.
But
it
is
a
question
that
has
come
up
in
a
lot
of
our
meetings.
I
guess
kind
of
I'll
pass
this
one
to
jim
jim.
D
So
I
think
the
value
of
that
change
is
understood,
but
the
challenge
like
ferry
was
also
mentioning,
especially
with
like
the
project
that
tried
you
know,
adding
tenants
or
the
tenant
information
to
the
apis
is
what
it
would
do
to
the
compatibility
of
other
add-ons
other
solutions
that
are
really
built
on
kubernetes
right.
So
at
this
point
at
least
you
know
like
it
seems
like
it
would
have
to
be
a
breaking
change
and
since
kubernetes
the
core
apis
are
ga
they're.
D
You
know
kind
of
they're
not
to
manage
compatibility,
there's
no
easy
way
to
introduce
that
change
into
kubernetes
apis
itself.
Right,
however,
one
other
area-
and
speaking
of
you
know
add-ons
so
kubernetes
today,
you
know
if
you're,
implementing
or
using
kubernetes
it's
a
collection
of
projects
and
obviously
there's
a
control,
plane,
there's
but
there's
several
other
components.
D
Several
other
add-ons
that
need
to
be
run
to
be
able
to
you
know,
get
have
kubernetes
clusters
operationalized
within
an
enterprise.
So
from
that
point
of
view
there
are
projects
like
if
you
look
at
dns
right,
so
every
kubernetes
cluster
runs
dns
requires
dns
and
dns
is
not
tenant
aware.
So
those
sort
of
changes,
in
my
opinion
and
and
making
something
like
coding
standard
aware,
is
certainly
you
know,
feasible
and
seems
like
that
could
be
done
or
other
dns.
You
know
projects
can
offer
that
into
kubernetes.
B
Well
easier
to
use
so
yeah.
I
think
that
I'll
I'll
agree
with
what
jim
and
dave
just
said.
It's
like.
I
don't
think
that
there's
a
lot
of
value
in
making
large
changes
to
upstream
at
this
point
like
it's
really
nothing
breaking,
because
the
fact
that
we
have
been
able
to
implement
things
like
h
and
c
and
v
clusters
shows
that
there's
a
reasonable
path
forward
that
I
think,
is
probably
good
enough,
given
the
the
traction
that
the
current
kubernetes
api
has
and
it's
not
worthwhile
to
rip
that
all
up
now.
B
B
We
really
need
to
start
shifting
away
from
the
technical
solutions,
because
I
think
that
we
are.
We
have
either
plugged
those
holes
with
the
projects
that
we've
incubated
or
are
plugging
those
holes,
or
at
least
we
know
where
the
holes
are,
and
we
can
point
people
to
like
yeah.
Let's
go
work
on
core
dns
for
a
bit.
B
What
they
really
need
is
a
guide
right
and
what
you
need
are
best
practices
documentation,
possibly
well
for
the
vendors
you
can
actually
have
wizards
and
whatnot,
but
any
kind,
something
that
can
just
get
people
onto
the
right
path.
So
it
really
does
become
a
usability
and
documentation
question,
and
I
think
that
I
can
see
that
as
being
by
and
large,
the
future
of
multi-tenancy
and
kubernetes
is
not
new
technologies,
but
new
ways
to
help
people
use
them.
A
D
I
guess
the
building
blocks
seem
to
be
in
place
right
and
there
are
enough
usable
tools
and
we're
also
seeing
like
some
of
the
tools
we
mentioned
like
loft
and
capsule,
and
others
emerging
from
both
vendors
in
the
ecosystem,
as
well
as
open
source
projects
right.
So
at
this
point
you
know
the
the
work
that
seems
to
be
left
to
be
done
is
go
address.
Some
of
these.
D
You
know
smaller
remaining
issues
like
we
talked
about,
whether
it's
with
dns
or
perhaps
with
the
good
proxy
and
a
few
other
things
which
could
be
made
tenant
aware
without
changing
the
guts
of
kubernetes
itself,
and
then
you
know,
sort
of
that
evangelism
or
awareness
or
better
classification,
of
how
users
and
enterprises
can
map
their
use
cases
back
to
you
know
what
needs
to
be
done
in
multi-tenancy,
so
it
seems
like
there
are,
you
know,
and
within
the
kubernetes
community
itself.
You
know
like
there's
several,
of
course,
there's
sig
usability.
D
There's
it's
networking.
There's
the
policy
working
group,
so
those
could
be
areas
of
collaboration
when
some
outreach
into
those
streams
to
see
whether
they're
you
know
these
other
projects
as
they
graduate
and
mature,
whether
they
fit
in
well
and
to
carry
forward
some
of
the
work
that
we've
started
here.
C
Yeah,
I
I
think
I
do
I
agree.
Andrew
and
james
point.
I
don't
I
don't
have
too
much
to
add.
I
guess
so.
As
a
working
group.
We
certainly
welcome
any
people.
If
you
come
to
this
new
idea
to
first
point
out
the
challenges
you
are
facing,
putting
out
the
problem
that
you
think
is
not
in
kubernetes,
but
it's
not
what
you
can
see
ready.
So,
let's
see
if
we
can
have
something
new
or
maybe
we
are
leaving
our
minded,
because
so
you
I
think
at
the
open
community,
so
you're
certainly
welcome
anything.
C
B
Yeah,
I
I
think
that,
as
we
said
like
we
set
out,
I
wasn't
actually
here
when,
when
multi-tenancy
working
group
started,
but
my
understanding
is
that
we
set
out
to
find
out
like
what
are
the
patterns
that
need
to
be
supported,
and
what
do
we
need
to
build
or
out
to
upstream
or
to
the
community
in
order
to
enable
those?
I
think
that
we've
largely
succeeded
in
that
task,
and
so
does
the
working
group
need
to
continue
in
its
current
form.
Maybe
it
is
a
nice
landing
place
for
people
to
come.
A
Awesome
yeah:
well
thanks
everybody
for
sharing
your
thoughts
on
the
future
multi-tenancy
and
to
the
audience
listening.
If
you
have
joined
kubecon
live,
we
will
be
taking
audience
questions
both
within
the
platform
and
in
the
cncf
chat,
or
you
can
come
and
join
the
kubernetes
chat
channel
for
multi-tenancy,
which
we're
in
outside
of
events
too.
So,
thanks
looking
forward
to
hearing
your
thoughts
and
looking
forward
to
more
multi-tenant
solutions
thanks,
everyone.