►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Kubernetes WG for Multitenancy - Tasha Drew, VMware
This presentation will be an overview of the work the multitenancy group has been doing, defining soft and hard multitenancy and reviewing the project plan for addressing both that the working group is putting forward. We will explain how people new to the working group can get engaged and review the various KEPs that the working group is involved with.
https://sched.co/MPiD
A
Hey
everybody
we're
here
to
talk
about
the
kubernetes
working
group
for
multi-tenancy,
how
many
of
you
have
participated
at
all
in
that
working
group
before
okay
cool,
that's,
probably
the
right
number
of
people.
This
is
intended
to
be
a
beginner's
introduction
into
the
work
that
we're
doing.
I'm
gonna
go
over
some
of
the
high-level
concepts
and
then
introduce
you
to
some
of
the
work
that's
going
on.
A
So
the
multi-tenancy
working
group
was
founded
in
koukin
North
America
in
2017,
and
there
was
a
large
show
of
community
interest
in
the
subject
and
approaches
to
achieving
multi-tenancy
we're
a
working
group.
That's
formed
under
sig
off
and
multi-tenancy
and
how
we
achieve
multi-tenancy
touches
many
parts
of
kubernetes,
so
sig
note
scheduling,
security,
network
storage
and
API
machinery.
A
Who
are
we
I'm?
One
of
the
chairs,
my
name
is
Tasha
drew
and
I
also
work
at
VMware
I
have
a
co-chair
David
Oppenheimer
who's
at
Google,
David's,
actually
stepping
down.
So
we
have
an
open
request
to
see
who
wants
to
be
our
next
chair
and
that's
going
to
be
something
that
people
are
putting
forward
in
our
next
meeting,
which
is
Tuesday
June
4th.
A
Where
can
you
find
us?
We
have
a
slack
group,
so
the
kubernetes
community
has
a
community
slack.
It's
different
from
the
CNCs
slack,
so
I
would
really
recommend
if
you're
not
already
in
it,
I
put
the
link
up
there,
but
just
check
it
out,
jump
in,
and
then
we
have
a
channel
in
that
slack.
That
is
working
group
multi-tenancy.
We
also
have
a
Google
Group.
A
If
you
have
engaged
with
other
working
groups
and
SIG's
in
the
kubernetes
community,
then
you
know
that
the
work,
the
joining
the
Google
Group
really
the
best
way
to
quickly
engage
with
with
the
open-source
community.
The
mailing
list
is
where
all
the
meeting
notes
go
out.
It's
where
people
will
post
questions
and
ideas
and
links
to
their
keps,
so
join
our
Google
group
for
sure,
and
you
will
then
automatically
receive
Google
Calendar
invitations
to
all
of
our
events,
including
the
the
all-important
zoom
link.
We
have
bi-weekly
meetings.
A
If
you
join
the
Google
group,
you'll
get
the
invitation
to
this
bi-weekly
meeting.
They
are
at
Tuesday
11
a.m.
Pacific
time.
I
know
that
that
might
not
be
great
for
all
time
zones
and
we
are
open
to
moving
that
if
we're
having
an
additional
time.
If
that,
if
the
community
would
like
to
see
that
we
record
all
of
our
meetings,
they're
posted
to
YouTube,
we
have
a
playlist
that
you
can
check
out
to
see.
A
Every
meeting
we've
had
and
we're
also
on
github
under
kubernetes
SIG's,
so
I
would
really
recommend
checking
out
our
github
multi-tenancy
page.
That's
where
you
will
see
all
of
the
sample
code
for
our
proof
of
concept,
see
our
IDs.
It's
also
where
you
can
find
and
I
wrote
the
link
later
in
this
deck,
but
it's
also
where
you
can
find
a
link
to
all
of
the
important
documentation
that
we
as
a
working
group,
have
been
putting
together
that
defines
more
some
of
the
high
and
low
level
concepts
of
multi-tenancy
and
kubernetes.
A
So
why
multi-tenancy?
And
what
do
we
really
mean
when
we
talk
about
multi-tenancy?
So
at
the
end
of
the
day,
people
companies
departments
they
want
to
share
kubernetes
clusters,
they
might
have
multiple
users
of
the
same
kubernetes
clusters,
so
they
might
have
multiple
applications,
they
might
have
multiple
teams
or
they
might
have
multiple
customers.
So
why?
Wouldn't
you
give
everyone
their
own
unique,
kubernetes
cluster?
The
answer
is
reduced.
Cluster
sprawl
improved
resource
utilization.
A
There
may
be
different
tools
that
you're
installing
on
a
cluster
that
you
want
different
teams
to
be
able
to
share,
but
we
so
we're
kind
of
like
trying
to
explain
something,
and
we
do
this
in
our
mission
statement
as
well.
But
we
think
that
there
is
absolutely
a
use
case
for
cluster
API
Federation
ephemeral
clusters,
spinning
them
up
up
and
down
all
day.
We
think
that's
awesome,
but
still
think
that
there
is
a
need
for
multi-tenancy
as
well.
A
A
So
you
can
read
more
about
this
at
our
project
plan
proposal,
which
is
on
Google
Docs
and
we've
presented
that
a
couple
times,
and
it
has
a
high-level
project
plan
that
I'll
briefly
go
over
as
well,
so
for
tendancy
one
of
the
things
that
people
say
if
you
are
in
the
multi-tenancy
group
and
you'll
hear
this
a
lot
is
nobody
agrees
on
what
a
tenant
is.
So
I
mostly
put
this
light
up
to
show
you
that
we
do
agree
on
what
a
tenant
is.
So
we
have.
We
have
an
entire,
really
awesome
dock.
A
That
Eastway,
who
at
Google,
has
put
together
called
the
tenant
concept
in
kubernetes,
but
at
a
high
level.
What
we're
saying
is
a
tenant
represents
a
group
of
kubernetes
users.
A
tenant
has
certain
accessibility
to
a
group
of
resources
in
a
kubernetes
cluster.
A
tenant
can
manage
accessibility
of
the
group
of
resources
for
subgroups
of
users
limited
by
the
accessibility
granted
to
the
tenant.
A
tenant
can
be
allocated
quota
to
consume
resources
in
a
kubernetes
cluster.
A
A
kubernetes
cluster
is
shared
by
one
or
more
tenants
who
are
either
isolated
or
not
isolated
and
in
a
kubernetes
cluster.
A
tenant
is
an
entity
representing
a
group
of
resources
with
defined
accessibility
in
quota.
So
you
can
see
what
we're
doing
here
is
we're
really
trying
to
define?
What
is
that
use
case?
Why
do
people
need
multi-tenancy
and
then
how
do
we
draw
a
circle
around?
A
What
multi-tenancy
is
without
making
it
too
restrictive
in
a
way
that
really
cuts
out
a
lot
of
important
use
cases
for
people,
but
also
with
having
a
clear
enough
definition
that
this
really
gives
us
a
problem
that
we
as
a
group
and
a
community,
can
tackle
so
this
tenancy,
calm
concept
in
kubernetes
dock
is
open
for
comment.
It
was
presented
two
weeks
ago
to
the
community
and
to
ago
before
that,
and
we're
continuing
to
gather
feedback
and
really
iterate
on
that
so
different,
tenancy
models.
A
You'll
hear
these
terms
a
lot
when
you
engage
with
the
multi-tenancy
working
group,
so
I
just
kind
of
wanted
to
get
everyone
on
the
same
page
about
what
we're
talking
about.
So
we
have
soft
multi-tenancy
and
we
have
hard
multi-tenancy
and
really
what
we're
talking
about
is
how
isolated
we
can
make
the
tenants
within
your
kubernetes
cluster.
So
today
we
can
achieve
soft
multi-tenancy
in
kubernetes.
There
are
some
gaps,
there's
some
feature
gaps
and
there's
also.
There
is
not
an
official
kubernetes
profile
that
says.
A
If
you
run
this
exact
profile,
then
you
will
get
a
soft
multi,
tenant,
kubernetes
cluster
and
it's
signed
off
by
kubernetes
and
we
all
agree.
This
is
a
soft
multi-tenancy
cluster.
That's
all
work
that
this
working
group
wants
to
address.
But
what
soft
multi-tenancy
means
is
it's
a
model
of
multi-tenancy
in
which
the
users
of
the
shared
cluster
are
somewhat
trusted.
So
you're
not
saying
that
I'm
going
to
run
something
that
complete
strangers
are
kind
of
come
in
and
try
to
escape
everything.
A
There
is
some
contract
between
the
runner
of
the
cluster
and
the
users
of
the
cluster
that
says
I.
You
know
maybe
I'm
an
employee
like
I,
have
a
vested
interest
in
not
messing
with
you
too
much,
and
if
I
do
mess
with
you,
it's
going
to
be
logged
and
I'm
gonna
get
fired.
So
we
have
this
idea
that
people
have
an
incentive
to
act
as
a
good
actor
on
the
system.
So
tenants
don't
have
access
to
anything
from
other
tenants,
but
it
would
be
accessible,
for
example,
to
share
the
API.
A
So
here
we're
saying,
except
for
the
kubernetes
api,
which
could
be
protected
but
still
accessible
to
allow
tenants,
users
to
run
their
own
controllers
and
operators
and
take
other
actions
on
other
objects
between
their
namespaces.
But
there
are
some
people
who
say
that
there
actually
can
be
zero
trust
and
zero
sharing
of
that
API
control
plane.
A
So
that's
something
that
we
need
to
have
models
for
both
likely
and
there
has
been
a
really
great
series
of
presentations,
the
first
of
which
was
two
weeks
ago
at
the
multi-tenancy
working
group,
about
how
how
one
company
Alibaba
has
been
achieving
this
by
basically
having
multiple
nested
control,
planes
and
I
would
recommend
checking
that
out
and
they
are
gathering
feedback
in
use
cases
because
they
want
to
make
this
a
project.
That's
very
useful
for
a
lot
of
people.
A
How
to
get
involved?
Okay,
so
github
again,
I
would
definitely
encourage
everybody
to
go
check
out
our
multi-tenancy
project
page.
We
have
project
boards.
One
is
for
this
project,
the
tenant
CR
D,
which
is
a
CR
D
that
we're
attempting
to
automate
the
creation
of
tenants
using
namespaces.
So
you
can
check
that
code
out.
You
can
try
to
advance
the
project,
you
can
offer
feedback
pull
requests
and
we
have
some
other
projects
that
we're
gonna
work
on.
A
We
also
have
a
lot
of
documentation
like
this
working
group,
has,
over
time
really
iterated
on
attempting
to
define
tenancy
soft
multi-tenancy
hard
multi-tenancy.
What
do
all
of
these
things
mean?
How
do
we
apply
them
in
the
different
clusters?
So
those
Docs
are
also
open
for
comment.
Some
of
them
have
been
really
ratified
by
the
working
group,
and
some
of
them
are
more.
You
know
very
much
like
in
their
iteration
mode,
so
check
those
out.
A
So
if
you
want,
like
the
easiest
way
to
get
started,
is
really
to
review
those,
and
then
think,
is
this:
what
my
customers
and
my
users
are
looking
for
out
of
multi-tenancy,
and
if
it
is
that's
awesome,
you
can
just
+1
it
and
if
you
have
a
new
user
story,
we
definitely
want
to
gather
those
so
that
we're
sure
that
we
are
continuing
to
evolve
the
project
in
the
direction
that
the
community
and
the
and
our
customers
need
here.
I
have
something
also
from
the
project
plan,
which
is
going
over
basically
our
high-level
project
plan.
A
So
we
have
these
epics
and
then
we're
doing
now.
Next,
in
future,
you
can
probably
tell
I'm
a
product
manager,
because
I
put
this
together
and
then
some
of
the
engineers
involved
immediately
jumped
into
next
and
future
tasks,
but
this
is
like
basically
a
way
of
slicing
up
what
we're
looking
to
do
so,
first,
what
we're
doing
is
taking
kubernetes
as
it
is
today
and
defining
what
a
secure
cluster
means.
A
If
you
look
at
a
project
like
Sto,
SEO
has
a
page
where,
if
you
want
to
run,
is
do
in
a
multi-tenant
manner,
you
go
to
the
page,
you
click
the
docs,
and
it
tells
you.
This
is
how
you
said.
Sto
up
kubernetes
doesn't
have
that.
One
of
the
reasons
I
got
involved
with
this
project
is
because,
if
you
run
conformance
against
a
cluster,
that's
been
really
locked
down
for
multi-tenancy
you're,
not
gonna,
pass
conformance
and
that's
a
problem.
A
So
the
first
thing
we
want
to
do
is
define
a
secure
single
tenant
cluster
and
that's
just
because
if
we
want
to
have
a
profile
of
sick
of
a
secure
cluster,
let's
start
with
the
easiest
use
case,
which
is
zero
multi-tenancy
and
then
the
next
use
case
is
defining
a
secure,
soft
multi,
tenant
cluster
and
that's
again
using
kubernetes
today
without
asking
for
changes
from
sig
api
machinery
etc.
Once
we
have
both
of
those
definitions,
then
what
we're
gonna
do
is
we're.
A
Gonna
share
those
with
the
bug
bounty
program
and
we
were
asked
to
do
this
by
some
of
the
leaders.
And
so,
if
the
bug
bounty
program
now
has
these
secure
profiles,
then
they
can
start
running
them
through
all
of
their
testing.
And
then
we
can
get
really
fast
feedback
on
what
needs
to
be
changed.
We'll
get
peer
review
from
other
SIG's
and
then
we
want
to
invest,
investigate
using
and
providing
recommended
profiles
around
set
comp
and
app
armor
in
the
future.
A
A
Our
other
epoch
is
introducing
new
features
and
tools
to
improve
support
for
soft
multi-tenancy,
and
so
some
of
this
work
is
already
in
progress,
and
you
can
check
it
out
on
our
github,
but
we
are
looking
at
it
developing
a
tenancy
CRD,
a
cluster
auditing
suite
that
you
could
just
run
against
your
class
to
see.
Is
this
correctly
configured
for
multi-tenancy?
A
You
can
see
why
having
those
agreed-upon
profiles
of
multi-tenancy
are
important
in
order
to
be
able
to
do
this
next
step
and
also
introducing
monitoring
around
multi-tenancy
and
then
we'll
continue
to
iterate
on
those
and
then
finally
supporting
hard
multi-tenancy.
Now
this
is
what
a
lot
of
people
are
super
interested
in,
but
what
we
really
need
to
do
is
finish
these
first
two
epics
and
figure
out
what
is
concretely
needed
in
order
to
support
hard,
multi-tenancy
and
feed
all
of
that
into
requirements
and
then
kick
that
off.
As
another
project.
A
We
have
a
couple
other
sessions
at
coop
Connie,
you
that
are
being
done
by
the
leaders
of
the
working
group.
We
have
a
deep
dive
tomorrow
at
2:50,
and
then
we
have
a
panel
discussion
of
multi-tenancy
and
kubernetes
where
we're
going
to
have
a
bunch
of
different
people
from
different
organizations
talking
about
how
multi-tenancy
is
important
to
their
customers
and
in
their
use
cases,
and
also
talking
about
so
current
state
and
then
also
talking
about
the
roadmap
going
forward.
A
A
B
C
C
A
Would
say
that
you
could
definitely
try
to
do
hard,
multi-tenancy
clusters
right
now.
The
question
is
how
it's
going
to
you
might
end
up
doing
things
that
would
make
you
deviate
from
the
conformance
yeah.
So
if
you're
running
a
cluster
right
now,
you
could
maybe
change
things,
but
it
would
be
hard
and
so
like
as
clarification
like
they're,
absolutely
SAS
providers
today
using
kubernetes
underneath
and
providing
different
namespaces
to
different
customers,
but
they're,
not
necessarily
providing
access
to
the
API.
And
so
that's
really.
A
How
does
this
work
with
Active,
Directory
Active
Directory
would
be
your
choice
for
SSO,
so
it's
just
the
same
way.
It
would
work
with
any
other
LDAP
or
other
configuration
like
you
can
provide.
You
know
you
can
provide
your
users,
their
user
credentials
and
authenticate
them
to
the
cluster,
but
at
the
end
of
the
day
you
still
have
the
cluster
roles
that
they're
able
to
map
to
and
then
whether
or
not
you
want
them
to
be
able
to
access
the
kubernetes
api.
B
D
D
A
Okay,
so
next
is
already
next
is
already
going,
so
we
have
the
tenant.
Crd
work
has
already
started
as
far
as
timelines
like
it's
just
really
going
to
depend
on
how
much
engagement
interaction
we
get,
and
so
one
of
the
reasons
that
we
introduced
github
project
boards
was
a
lot
of
people
want
to
get
involved,
but
it's
not
really
clear
to
them
like
what
could
they
just
jump
in
on
and
not
be
stepping
on
anybody's
toes?
A
A
Yeah
yeah
Federation
is
absolutely
an
ongoing
project,
it's
just
not
in
our
working
group.
So
that
is
something
that's
being
actively
worked
on.
I'm,
not
sure
who
buy
off
the
top
of
my
head,
but
I
mean
yeah.
It's
something
we're
all
going
to
need
and
it's
probably
a
lot
closer
and
then
hard
multi-tenancy.
A
C
A
So
it's
you
know
it's
not
an
insignificant
number,
but
there
are
also
things
that
you
can
do
to
pass
the
conformance
tests
and
I'm
not
sure
if
everybody
has
this
context,
but
the
reason
it's
important
to
pass
the
conformance
test
for
kubernetes
is
that
that's
you're
not
allowed
to
call
what
you
do
kubernetes
unless
you
pass
the
conformance
tests-
and
you
know
that's
for
a
lot
of
really
important
reasons.
But
what
we're
sort
of
advocating
for
is
this
idea
that
there
should
be
multiple
profiles
of
conformance
tests
that
the
community
has
agreed
upon.
A
So,
in
addition
to
the
sort
of
one
that
exists
now
yeah,
but
that's
all
in
a
public
document
that
I
can
share
with
you.
If
you'd
like
to
see
it
and
I
wanted
to
collect
more
examples
of
people's
failures
of
conformance
tests
to
see
what
patterns
there
are
that
evolve,
and
then
some
of
the
cig
off
leaders
have
been
super
receptive
to
us
opening,
PRS
and
opening
bug
reports
on
the
conformance
test.
A
D
D
A
D
A
So
the
question
was,
you
know
if
somebody
is
working
on
something
for
multi-tenancy
where's,
a
good
place
to
talk
about
it,
I
would
say
we
could
definitely
talk
about
it.
Now
we
could.
The
deep
dive
is
intended
to
be
more
of
a
open
session
where
people
can
kind
of
put
up
what
they'd
like
to
talk
about
and
do
dot
voting,
and
then
also
we
were
talking
about
just
inviting
everyone
who
wants
to
talk
about
multi-tenancy
to
like
meet
up
at
the
at
the
party
too,
because
you
know
at
coop
con
north
america.
A
D
D
A
Yeah,
okay,
so
the
question
was
as
a
new
upstream
developer.
Where's
the
right
place
to
just
engage
with
people
and
talk
with
them
and
the
bummer
is
the
community
day
was
actually
yesterday
all
day
they
did
like,
and
that's
just
something
to
know
about.
Coop
con
is
usually
the
day
before
coop
con.
They
do
something.
That's
totally
focused
on
the
upstream,
that's
very
unconference
style,
but
in
the
future
definitely
join
the
working
group
meetings
and
then,
if
you
ever
have
something
you
want
to
talk
about,
you
can
just
say
to
the
mailing
list.