►
From YouTube: Multi-tenancy vs. Multi-cluster: When Shou... Tasha Drew, Ryan Bezdicek, Adrian Ludwin, Jim Bugwadia
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Multi-tenancy vs. Multi-cluster: When Should you Use What? - Tasha Drew, VMware; Ryan Bezdicek, Medtronic; Adrian Ludwin, Google; Jim Bugwadia, Nirmata
The Kubernetes Working Group for Multi-Tenancy has a lot of fun projects helping people throughout the Kubernetes ecosystem manage sharing clusters. One question that comes up a lot is "when should I share a cluster using multi-tenancy, and when should I spin up multiple clusters?" We call this multi-tenancy versus multi-cluster. There are also a lot of people who are doing both simultaneously! People want to know when to do which, and we're here to help. Join this panel with the technical leads and chair of the Multi-tenancy working group to hear our thoughts on multi-tenancy versus multi-cluster, in a panel format.
A
Okay,
good
morning,
good
afternoon
and
good
night,
everybody
thank
you
for
joining
us
at
this
discussion
of
the
multi-tenancy
working
group.
Where
we'll
be
talking
about
the
similarities
and
differences
between
multi-tenancy
and
multi-cluster
setups.
Before
we
go
on
to
the
actual
panel,
I
just
want
to
basically
introduce
the
group
that
all
of
our
panelists
are
a
part
of.
We
are
all
members
of
the
multi-tenancy
working
group,
which
is
one
of
several
working
groups,
that's
organized
under
sigoth
and
a
couple
of
other
special
interest
groups
in
the
kubernetes
community.
A
This
slide
shows
how
you
can
join
us.
You
can
come
join
us
on
slack
at
wg
multi-tenancy.
We
have
a
google
group.
If
you
join
that
group,
you
will
automatically
get
the
calendar
invites
for
our
bi-weekly
meetings,
which
are
every
second
tuesday
at
11
a.m.
Pacific,
where
you
can
go
peruse
our
video,
like
the
recordings
of
our
meetings
on
youtube,
we
also
have
a
repo
where
a
couple
of
our
projects
live
those
projects.
A
We
might
have
a
chance
to
talk
about
them
later
in
this
panel,
but
those
projects
are
the
virtual
cluster
project
which
allows
you
to
take
one
kubernetes
cluster
and
subdivide
it
into
a
bunch
of
virtual
clusters.
There
is
the
multi-tenancy
benchmarking
set
that
will
test
your
cluster
for
its
compliance
with
multi-tenancy
policies,
and
there
are
hierarchical
namespaces,
which
is
one
of
the
things
that
I
work
on,
which
allows
you
to
cascade
policies
across
namespaces
and
and
treat
them
as
though
they
are
there's
an
ownership
structure
of
being
spaces.
A
So
please
come
and
join
us
we're
all
pretty
friendly.
At
least
I
think
we
are
and
we'd
love
to
see
you
so
without
further
ado.
I
would
like
to
introduce
my
fellow
panelists
today
who
will
be
talking
about
multi-tenancy
versus
multi-cluster.
Why
don't
we
go
in
alphabetical
orders?
So
jim?
Would
you
like
to
introduce
yourself.
B
C
A
Thanks
and
I
am
adrian
ludwig-
I
am
an
engineer
at
gke
at
google
cloud
and
I
am
the
tech
lead
of
hierarchical
namespaces,
we're
hnc,
the
hierarchical
new
space
controller.
So
why
don't
we
get
started
on
our
discussion
topic
today?
So
the
first
question
that
we
wanted
to
talk
about
was
what
is
the
difference
between
multi-cluster
and
multi-tenancy.
So
why
don't
we
start
in
the
reverse
order?
We
just
went
so
tasha.
You
want
to
give
your
your
reviews
on
this.
D
Yeah,
so
the
way
that
I
think
about
it
is
when
we
have
multi-cluster
that's
when
people
are
spinning
up
a
bunch
of
different,
potentially
single
or
multiple
use
clusters,
and
so
I
just
have
a
lot
of
clusters
I
may
have
cluster
sprawl,
and
so,
if
that's
kind
of
the
model
that
I'm
veering
towards.
As
far
as
how
I
leverage
kubernetes
as
a
service
in
my
organization,
then
maybe
every
time
a
dev
team
wants
access
to
kubernetes.
We
just
spin
them
up
a
cluster.
They
can
customize
it.
D
Meanwhile,
when
I
think
about
multi-tenancy,
what
I
really
think
about
is
the
shared
cluster
use
case,
so
I
might
have
different
development
teams,
different
organizations,
all
sharing
a
kubernetes,
a
single
kubernetes
cluster,
and
in
that
case
you
really
need
to
start
thinking
about
how
you're
securing
the
control
plane
and
securing
access
to
underlying
resources
in
order
to
make
sure
that
you
have
a
secure
and
you're
not
stomping
on
each
other.
When
you're
sharing
that
cluster.
C
Don't
know
she
covered
quite
a
bit.
Yes,
I
think
I'd
I'd
point
out
right,
like
I
guess,
in
my
view,
like
multi-tenant
and
multi-cluster,
aren't
necessarily
mutually
exclusive
right.
So
there
are,
you
know,
multi-cluster
kind
of
scenarios
that
you
can
have
that
include
some
form
of
multi-tenancy,
be
it.
You
know
how
you're
accessing
who
has
the
cluster
admin,
privileges,
etc
and
yeah.
I
mean
other
thing:
tasha,
pretty
much
summed
it
up
well,.
B
Jim,
do
you
want
to
go
ahead?
Yeah?
I
think
one
thing
just.
I
would
add
to
that
and
it's
interesting
because
you
know
again,
as
we
talk
to
customers
in
the
space,
it's
interesting
to
try
out
different
terminology
and
see
what
resonates
with
them,
and
you
know
how
customers
think
of
this
right.
So
one
one.
B
But
ultimately,
it
seems
like
it
comes
down
to
either
you're
consuming
a
namespace
you're,
getting
a
namespace
which
is
part
of
a
cluster,
perhaps
a
set
of
namespaces
with
something
like
htmc
or
you're,
getting
an
entire
cluster.
And
then
your
responsibility
as
the
end
user
within
an
enterprise,
is
to
manage
the
cluster
and
its
lifecycle
itself
right.
So
one
way
of
looking
at
it
is
also
either
namespaces
as
a
service
or
clusters
as
a
service,
and
those
seem
to
be
the
two
popular
models
of
consumption
that
you
know.
A
Yeah,
I
agree
with
everything
that
everybody
has
said
so
far.
I
think
that
the
two
are
not
mutually
exclusive.
In
many
case,
multi-clustering
can
be
a
way
to
implement
multi-tenancy,
and
that
becomes
even
more
clear
when
you
start
looking
at
virtual
clusters,
where
there's
only
where
there's
one
underlying
kubernetes
cluster
and
you're
essentially
running
multiple
kubernetes
control
planes.
On
top
of
that-
and
it
becomes
very
clear
that,
like
the
boundary
or
like
the
lines
between
you
know,
single
cluster
multi-cluster
can
actually
be
blurred.
A
A
A
You
would
want
to
give
them
each
their
own
database,
which
is
to
say
each
their
own
deployment,
and
so
does
that
mean
that
they
each
get
their
own
cluster
as
well
or
could
they
each
get
their
own
name
space
in
in
their
cluster
in
a
shared
cluster,
and
that
will
depend
on
a
wide
variety
of
factors
which
I
think
we
can
get
into
now
so
yeah?
Why
should
I
care
about
the
difference
between
so
now?
C
Sure,
well
I
mean
so
there's
a
lot
of
reasons
right
so,
and
it
really
kind
of
to
you
know
talk
about
adrian's
point
is
it
comes
down
to
who
is
kind
of
leveraging
this
cluster
right?
You
know
there
are
certain
things
in
kubernetes
that
are
cluster-wide
and
like
notably
crds
right,
so
crds
are
cluster-wide.
C
But
it's
also
notable
to
remember
right.
At
the
end
of
the
day,
these
are
containers
running
on
a
single
vm
or
bare
metal,
node,
sharing
a
kernel
right,
so
they're
still
sharing
a
kernel,
there's
no
like
cpu
or
hardware
level,
isolation
that
we
get
with
hypervisors,
at
least
not
yet,
and
so
you
know
understanding
your
security
posture
and
what
you're
running.
If
it's
untrusted
trusted,
you
know
somewhere
in
the
middle,
that's
really
the
one
or
why
you
should
care.
B
Yeah
sure-
and
it's
I
think,
just
to
kind
of
extend
on
that.
It's
it's
really
about
finding
that
balance
and
what's
right
again
for
each,
you
know
like
a
development
team
or
any
end
user
within
an
organization
and
of
course,
if
you
kind
of
look
at
the
the
whole
sort
of
you
know,
guts
of
kubernetes
itself
I
mean
ultimately
kubernetes
is
meant
to
share
a
collection
of
resources
and
to
do
some
bin
packing
and
scheduling
across
those
right
and
that's
one
function
of
it,
but
that's
part
of
the
core
function.
B
So
obviously
there
is,
you
know,
value
in
sharing
resources
within
enterprises
within
organizations
for
efficiency
for
agility,
and
it
really
comes
down
to
also
then,
okay,
if
you're
sharing
these
resources,
how
do
you
make
sure
that
the
right
workloads
are
segmented
or
the
right?
Users
are
segmented
and
folks
are
not
sort
of
you
know,
tripping
on
each
other's
are
stepping
on
each
other,
so
so
to
speak.
So
from
that
point
of
view,
it's
you
know,
there's
no
right
or
wrong
answer.
B
I
think
what
we're
starting
to
increasingly
see
is
that
even
within
the
same
organization,
some
teams
may
just
want
you
know
a
name
space
and
that's
perfectly
fine.
Other
teams
may
want,
or
perhaps
there's
a
need
in
production.
You
want
to
dedicate
an
entire
cluster
to
a
certain
workload
like
your
management
tools
or
your
security
tools.
Things
like
that,
so
it's
really
finding
the
right
fit
and
there's
again,
there's
there's
some
interesting
trade
offs
as
you
look
at
these
different
models.
A
Yeah
thanks,
so
why
don't
I
go
next,
I'm
going
to
riff
off
of
something
you
just
said
jim,
like
there
is
no
one
right
answer,
and
I
see
this
a
lot
with
people
who
are
starting
to
either
switch
to
kubernetes
or
expand
on
kubernetes
people
are
are
interested
in.
What
is
the
right
answer,
and
not
only
will
I
say,
there's
no
one
right
answer
for
everybody,
but
the
right
answer,
even
for
one
team,
will
change
over
time,
and
so
why?
Why
do
people
care?
Well,
it
might
be
that
you
shouldn't
care.
A
The
right
answer
might
be
just
do
whatever
is
easiest
for
you
at
the
time,
but
try
to
avoid
closing
the
door
to
improvements
in
the
future.
So,
for
example,
probably
the
bare
minimum,
I
would
say
is
don't
run
everything
in
the
default
namespace,
because
that
will
make
it
much
harder
if
you
ever
need
to
share
a
namespace
with
somebody
else
on
another
cluster,
but
yeah
watch
for
watch
for
those
kind
of
points
where
you
are
running
out
of
steam
with
your
current
approach.
A
So
if
you
want
to
give
every
team
their
own
cluster,
because
that's
easy
for
you
great,
if
you
then
later
find
out
that
that's
very
expensive,
because
all
of
the
clusters
are
regional,
so
there's
a
minimum
of
three
nodes
and
everybody's
running
in
multiple
regions.
So
now
each
every
single
workload
that
you
have
is
taking
up
a
total
of
nine
or
ten
vms,
even
though
your
total
aggregate
load
is
less
than
one
cpu,
that's
probably
a
good
time
to
start
considering
multi-tenancy.
A
So
basically
it's
good
to
be
aware
of
these
things,
so
that
you
know
when
you're,
starting
to
run
into
whatever
limitation
is
of
your
current
approach
and
just
be
flexible
and
know
that
it's
going
to
change
without
getting
too
hung
up
about
getting
it
right
from
the
beginning,
tasha.
Why
don't
I
give
you
the
the
last
word,
although
I
think
there
might
be
a
follow-up
so
actually
we're.
D
All
getting
excited
about
this
topic
yeah,
so
I
think
the
other
interesting
thing
to
me
is
dependency
management
in
the
kubernetes
control
plane.
And
how
do
you
really
manage
it,
because
a
lot
of
the
things
that
we
start
running
in
the
kubernetes
control
plane,
stomp
all
over
each
other
right
so
one
example
is
cert
manager.
D
Cert
manager
is
a
dependency
that
a
lot
of
applications
and
services
want
to
have
installed
if
they're
going
to
run.
And
if
you
have
two
versions
of
cert
manager
running
on
the
same
kubernetes
control
plane,
then
nobody
knows
which
one
to
call
and
you
you
enter
a
broken
state
right
and
so
just
starting
to
think
about
kubernetes
as
an
operating
system.
Right
like
starting
to
think
about
like
how
can
I
really
understand
what
are
all
the
dependencies
of
this
tools
and
services
I'm
running
here
and
then?
C
Today,
great
I'm
gonna
follow
up
so
yes,
one
thing,
I
think,
is
worth
pointing
out
a
lot
of
the
conversations
we
have
and
a
lot
of
people
that
use
multi-tenancy
are
concerned
about.
It
are
really
kind
of
looking
at
like
dev
systems
and
how
do
we
reduce
costs
for
sharing?
But
I
guess
I'd
point
out,
like
it's
actually
probably
a
good
idea
to
even
consider
using
a
multi-tenant
solution
in
production.
Even
if
you
don't
care
about
multi-tenancy,
because
you
get
that
isolation.
So
us
specifically
right
medtronic.
C
So
we
have
a
lot
of
compliance
around
that
and
so
adopting
kind
of
a
multi-tenant
solution
in
your
production
workload,
even
if
you're
not
multi-tenant,
but
having
some
of
that
isolation
and
segregating
things
off,
and
only
opening
the
holes
that
you
need
are
just
good
practice
and
I
think
some
of
the
tools
that
we're
working
on
kind
of
benefit
at
a
larger
level
than
oh.
I
just
need
multi-tenancy
it's
more
of
how
am
I
going
to
better,
I
guess,
isolate
and
secure
my
my
production,
kubernetes
cluster.
B
A
Yeah
and
I'll
go
even
further
than
that
like,
even
if
you
are
running
a
multi-cluster
setup,
it's
not
like
the
different
clusters
can't
interact.
It's
not
like.
Oh
I've
gone
multi-cluster.
Now
all
my
security
problems
have
gone
away.
No,
you
might
be
sharing
a
network
like
a
network
space
and
and
you
can
send
network
to
the
wrong
customers.
I
suppose,
if
you're
particularly
paranoid,
you
could
worry
about
vm
escapes,
although
hopefully
somebody
else
is
is
helping
you
out
with
that.
So
yeah
there
are
like.
B
There
are
new
proposals.
Being
you
know,
drafted
in
the
community.
There's
a
cap
which
is
you
know
just
coming
out
and
name
spaces
are
going
to
become
even
more
important
than
before
for
isolation
and
for
that
segmentation
boundary
right
because
really
you're
only
as
secure
as
the
name
space
that
the
pod
is
running
in
and
anyone
who
has
access
to
that
namespace
gets
all
the
privileges
that
namespace
allows.
So
the
new,
the
evolution
of
pod
security,
seems
to
be
moving
towards
using
namespace
segmentation
and
isolation.
B
C
And
they
get
a
little
more
specific.
If
you
don't
mind
right
so
like
one
of
the
biggest
problems
with
you
know,
prosecutors
policies
in
general
right
is
they're
at
a
cluster
level,
so
you're
only
really
as
secure
as
your
least
secure,
because
pretty
much
anyone
can
just
say.
Oh
give
me
that
one,
but
that's
actually
a
problem
that
we
have
in
name
spaces
that
a
lot
of
people
forget
about.
Is
your
service
accounts
generally?
C
Unless
you
add
extra
policy,
you
any
container
or
pod
running
in
that
name,
space
can
use
any
of
the
service
accounts
in
that
name,
space
right
and
people
kind
of
forget
about
that.
So,
if
you're
running
circ
manager
in
the
same
name
space
as
whatev,
you
know
whatever
you
might
have
some
cluster-wide
privileges
to
or
alter
the
ca
or
whatever,
because
you
know
they
have
ownership
so
segregating
by
namespaces
in
general.
Is
super
important
and
a
lot
of
people
kind
of
forget
that
at
the
our
back
level.
A
Yeah,
I
there's
a
an
engineer.
I
work
with
who
works
on
gk,
who
often
talks
about
that
name.
Spaces
should
be
like
the
atom.
The
smallest
possible
thing
that
you
deploy.
That
is
indivisible
because
everything
other
than
that
might
change
the
permissions
you
want
to
assign
to
a
service
the
secrets
that
it
might
have
access
to
the
config
maps.
All
of
these
things
are
at
the
name,
space
level.
A
I
I
think
that
I
wanted
to
to
maybe
let's,
let's
poke
a
little
bit
more
at
some
of
these
specifics,
because
we've
been
getting
a
bit
more
into
detail.
So,
let's
start
with
jim
we've
talked
a
little
bit
about
when
you
would
you
want
to
go
from
multi-cluster
sort
of
down
to
to
multi-tenancy?
When
would
you
want
to
consolidate?
A
Do
you
would
you
like
to
say
anything
about
what
would
push
you
in
the
other
direction?
What
would
you
say
to
a
customer
who
started
out
multi
with
multi-tenant
clusters
at
what
point,
let's
say
other
than
crd,
should
they
say?
Well,
maybe
we
should
be
considering
either
virtual
clusters
or
entirely
separate
clusters.
B
Yeah-
and
I
think
it
comes
down
to
also
the
again
back
to
the
usage
model
back
to
what
the
end
the
person
or
the
team
you
know,
sort
of
getting
the
cluster
is
trying
to
accomplish
right.
So
very
and
as
of
course,
you
know,
cloud
providers
and
different
software
vendors
make
in
even
projects
like
cappy
makes
spinning
up
clusters
easier
and
easier.
B
It
is
very,
you
know
why
not
get
a
cluster
use
it
and
sort
of
throw
it
away
or
dispose
of
it
when
you
don't
need
it
right.
So
much
like
we've
seen
that
evolution
with
vms,
where
at
one
point,
I
guess
none
of
us
remember
this
now,
but
servers
were
hard
to
get
and
you
would
get
a
server
and
you
would
keep
a
server
right,
but
now
we're
used
to
spinning
up
machines
and
disposing
machines
when
we
don't
need
them
right
so
similarly
clusters,
it's
definitely.
B
If
you
just
need
a
sandbox,
you
want
to
do
some
tests.
You
want
to
run
some
batch
jobs
that
make
sense
to
spin
up
a
cluster.
It's
completely
isolated,
at
least
at
that
boundary.
Of
course,
you
might
be.
You
know
sharing
other
things
like
networks
and
other
underlying
resources,
but
you
have
that
entire
cluster
and
you're,
not
you
know,
worried
about
impacting
anything
else
running
at
that
point.
A
All
right,
why
don't?
I
add
something
very
briefly
to
that
so
yeah,
I
think
when
you
would
go
from
a
multi-tenant
cluster
to
a
virtual
cluster
is
exactly
what
what
you're
saying
jim.
When
would
you
want
to
go
from
a
virtual
cluster
to
a
to
like
a
completely
separate
cluster,
which
is
a
separate
set
of
vms?
A
Obviously,
if
you
have
regionality,
you
need
to
be
running
in
different
locations.
That's
another
thing
that
can
push
you
out.
Those
are
probably
the
biggest
things
that
I
could
think
of
that
might
push
you
out
of
the
virtual
cluster
level
to
the
to
the
true
multi-cluster
level
as
well,
and
I
think
I've
already
spoken
about
what
might
drive
you
in
the
other
direction,
which
is
mainly
cost
cost
savings,
sometimes
ease
of
use,
depending
on
what
you're
going
for
tasha.
Anything
that
you
wanted
to
add
to
that.
D
As
far
as
like
multi-cluster
versus
virtual
cluster,
I
think
that
there's
just
some
inherent
complexity
over
sort
of
which
projects
you
want
to
adopt,
and
also
just
how
you're
managing
your
infrastructure
right.
So
as
jim
was
saying
like
if
you're
using
the
public
cloud,
it's
so
easy
to
just
spin
up
machines
and
also
to
add
nodes
right,
and
so
that's
something
that
we've
heard
from
some
of
our
users
is
that
when
they're
on
prem,
it's
actually
really
hard
for
them
to
add
a
node
to
an
existing
cluster.
D
D
So
it
just
kind
of
seems
to
be
pretty
impacted
by
how
your
development
teams
are
interacting
with
their
infrastructure
and
the
constraints
on
that
infrastructure
and
then
also
and
that's
just
kind
of
for
internal
use
cases.
And
then,
when
we
start
thinking
about
external
use
cases,
there's
just
a
lot
of
things
to
kind
of
unpack.
Around
security-
and
you
know
like
how
sort
of
how
open
your
customers
are
to
like
sharing
resources
versus.
Do
your
customers
even
know
they're
on
kubernetes
like
what
api
is
or
what?
D
C
Yeah,
so
I
think
you
know
there's
a
couple
of
reasons
in
in
and
kind
of
like
I
said
before
it
might
not
be
exclusive
right,
so
you
know
for
us
specifically
right
on
our
dev
machines.
We
have
kind
of
some
shared
clusters
that
are
multi-tenant,
but
then
you
know
when
we
want
to
look
into
like
performance
testing
or,
like
verification
testing
those
get.
You
know,
production
grade
level
clusters
by
themselves
so
that
we
can
have
that
parity.
C
So
that's
one
of
the
reasons
why
you
know
those
tenants
are,
I
guess
separate,
but
the
other
major
concern
or
not
really
concern
is
at
some
level
when
your
kubernetes
cluster
gets
large
enough.
Sometimes
it
might
not
be
worth
it
to
kind
of
be
like
oh
well.
Let's
just
keep.
You
know
figuring
out
how
to
scale
this
thing
and
even
though
it
can
scale
right
like
we,
we
see
kubernetes
clusters
with
5000.
C
You
know
workers,
you
know
fine,
but
it's
important
to
remember,
like
every
crd,
you
add
in
mutating
web
hook
or
validating
web
click,
all
that
that's
contention
you're
putting
on
the
ncd
and
the
api
server.
I
mean
at
some
point.
You
know
you
might
like,
we
certainly
hit
it
and
we
have
to
hit
it.
You
know
with
less
than
100
nodes
right,
so
it's
at
some
point
you
just
kind
of
like.
C
Well,
maybe
it's
easier
to
have
another
cluster
for
some
of
this
stuff,
because
ninety
percent
of
or
like
fifty
percent
of
our
tenants,
don't
need
you
know
cert
manager
or
something
and
yet
we're
adding
extra.
You
know
contention
to
their
workloads
because
of
those
shared
cluster-wide
services.
So
I
think
at
that
point
you
can
kind
of
get
to
the
level
to
understand.
You
know
what
makes
sense
to
separate
out.
A
B
Sure
yeah,
so
the
project
that
you
know
I'm
most
involved
in
is
the
multi-tenancy
benchmarks
project
and
the
whole
thinking
here
was
to
you
know,
of
course,
there's
a
lot
of
things
you
can
configure
in
kubernetes
for
isolation
segmentation
at
the
name
spaces
level.
So
the
benchmarks
projects
is
trying
to
make
sure
that
that
can
be
measured
within
the
cluster
through
both
configuration
as
well
as
behavioral
checks.
So
it's
a
tool
you
can
download
either
as
a
cli
or
you
can.
B
A
Thanks
I'll
take
one
step
up
the
stack,
which
is
h
and
c
hierarchical,
name
spaces,
as
I
said,
if
you
think
of
the
name
space
as
the
atom,
you
can
think
of
hnc
as
the
ability
to
create
molecules
which
is
groups
of
related
name
spaces
with
related
policies,
and
so
makes
it
easier
to
create
a
like
a
multi-name
space
network
policy,
for
example,
or
our
back
policy,
and
we
are
working
our
way
towards
one
point.
I
think
where
our
next
release
is
0.8.
A
D
Yeah,
so
I
was
just
pulling
up
his
blog
post,
but
to
show
kind
of
the
architecture,
but
basically
the
idea
of
the
virtual
cluster
project
is:
how
can
we
have
all
of
our
infrastructure
managed
by
one?
What
we
call
I
think
super
control
plane,
but
then
everybody
who
is
a
tenant
of
that
super
control
plane
gets
their
own
virtual
control
plane
that
they
can
customize.
However
they
want
to
so
as
an
individual
user.
A
Yeah
thanks
yeah
and
if
you
are
interested
in
any
of
these,
please
come
visit
our
repo
on
github,
so
we're
at
kubernetes
multi-tenancy.
You
can
find
links
to
all
of
these
projects
and
we
have
some
time
now
for
additional
questions.
So
thanks
for
watching
everybody-
and
please
add
your
questions
to
whatever
method,
we
add
questions
to.