►
From YouTube: Kubernetes Working Group for Multi-tenancy 20210309
Description
Discussion over different forms of multi-tenancy versus multi-cluster versus virtual cluster in prep for Kubecon
C
C
The
second,
of
course,
like
spinning
up
separate
clusters
and
which
is
fairly
common
with
cloud-based
kubernetes
and
the
other
one
which
is
a
hybrid,
is
sharing
the
control
plane,
perhaps
with
a
different.
You
know,
like
maybe
with
virtual
clusters,
having
some
components
per
tenant
and
then
with
nested
clusters.
C
B
Follow-Up
to
that
was
was
my
assumption
about
virtual
clusters.
Was
that
mainly
you
were
sharing
resources,
but
all
so
the
question
I
was
going
to
give
was
like:
are
there
any
kind
of
like
policy
objects
that
can
make
it
easier
for
the
different
virtual
clusters,
in
the
same
shared
cluster,
to
communicate
with
each
other
to
impose
common
policies
to
impose
like
different
policies.
D
D
I
repeat
so
in
the
current.
The
answer
to
the
entries
question
is
at
least
the
current
designs.
No
because
you
for
jim
you
know,
net
state
and
virtual
are
the
same
thing.
So
just
forget
about
the
nested,
so
there
I
have
to
make
a
compromise
about
the
name,
so
so
for
the
virtual
cluster,
so
we
don't
handle
any.
D
So
if
you
look
at
the
synchro,
you
know
we
we
modeled
the
super
cluster
which
actually
run
the
parts
as
a
resource
provider,
only
so
any
control
kind
of
crd
or
even
api
resources.
They
are
not
even
synced
to
the
super
cluster,
so
there
is
no
way
you
can
set.
You
know
advanced
network
policy
to
allow
the
different
tenants
to
talk
each
other
unless
you
completely
bypass
bypass
the
kubernetes
default
service.
C
D
C
D
C
A
C
B
A
A
I
know
that
we
have
a
ton
of
documentation,
because
I
had
to
write
the
multi-tenancy
yearly
report
that
you
all
saw
kind
of
fly
by
and
every
time
they
asked
me
what
about
this?
What
about
this?
I
just
had
to
go
look
at
like
our
copious
amounts
of
documentation,
but
I'd
forgotten
that
half
of
it
existed.
So
if
we
think
about
like
what
we
want
to
define
about
the
different
models,
I
can
go
kind
of
look
at
what
we've
already
written
up
and
then
we'll
kind
of
see
the
gaps.
A
D
E
But
but
it
has
the
same
it,
it's
not
necessarily
the
ideal
implementation,
but
I
think
it
still
fits
the
model
where
you
have
one
control
plane.
That's
ending
up
launching
pods
in
a
different
kubernetes
cluster.
Well,
that's!
Basically
what
cubefed
is
meant
to
solve?
Isn't
it
except
cubefed
has
a
different
api,
you're
you're,
creating
cube,
fed
objects
that
then
create
native
kubernetes
objects
in
other
clusters,
whereas
admiralty
when
it
goes
to
schedule
a
pod
and
the
the
one
control
plane.
It
then
takes
the
pod
and
copies
it
and
and
creates
it
in
an
another.
D
So
you
think
at
the
level
more
otherwise
I
would
say
yes,
they
are
kind
of
very
similar
to
you
see.
So
I
I
don't
think
I
want
to
argue
about
that.
So,
if
you,
if
you
cr,
if
you're
asking
whether
they
are
achieving
the
same
isolation,
you
know
probability,
I
would
say:
yes,
it's
all
just
implementation
decision.
D
I
agree
with
you
that
can't
really
agree
with
that.
So
yeah,
because
high-level
model
is
just
a
dedicated
control
plan,
make
sure
the
kubernetes
api
is
kind
of
fully
compatible,
which
I'm
not
exactly
sure
for
automatically
can
achieve
that.
If
they
use
virtual
cooperate,
I
would
assume
some
of
them
yeah,
that's
my
other
than
that.
I
would
say
no
problem
as
another
key
differences.
Is
that
the
no
no
semantic?
D
D
C
F
F
So
back
to
like
the
discussion
points
tasha,
I
wanted
to
kind
of
point
out
that
we
don't
really
none
of
the
discussion
points
really
talk
about
how
to
choose
if
a
multi,
tenancy
or
multi-cluster
is
right
for
you,
which
is,
I
mean
almost
impossible
for
us
to
actually
give
any
guidance
on.
But
I
don't
know
if
it's
worth,
I
think
that's
very
important.
Yeah.
D
E
E
B
Or
a
flowchart,
like
a
decision
flow
chart
like
that,
sometimes
something
that
that
I've
used
before
is
like
you
know,
this
is
the
like.
Multi-Cluster
gives
you
this
kind
of
isolation.
Do
you
need
that
kind
of
isolation?
Yes,
well,
then
you're
doing
multi-cluster.
Do
you
not
need
that
kind
of
isolation?
And
you
want
to
save
costs?
Well
then,
don't
do
that
it's
like
so
so
I
think
I
mean
well
yeah.
I
mean.
F
Yeah,
unfortunately
too,
like
I
mean
in
the
model
tendency
for
sure,
but
like
multi-cluster
also
comes,
becomes
a
question
of
like
eventually,
if
you
go
to
sizes-
or
you
know
you
need
to
like
for
us,
we
have
to
be
multi
multi-cluster,
because
our
data
can't
leave
the
country
of
origin,
and
you
know
certain
countries
don't
have
aws.
So
we
have
to
you,
know,
solve
those
those
issues
as
well.
So.
D
Yeah,
I
think
I
think
that's
a
good
point.
Maybe
I
we
should.
You
know,
use
this
kind
of
decision
tree
to
drive
the
discussion,
because
this
every
time
you
make
a
choice
you
have
to.
I
made
a
choice
because
a
model
doesn't
fit
b
model
fit
it,
but
in
what
sense?
So
that's
I
think
we
kind
of
flow
can
drive
the
discussion
more
concentrate
and
not
enough
spread
to
let's
go
wide.
B
And
also
focus
on
also
mention
the
fact
that
it
can
change
over
time
right,
like
we've
seen
this
a
bunch
is
that
somebody
starts
on
multi-cluster,
because
it's
quick
and
easy
and
cheap-ish
to
get
started
and
then
later
on.
There's
some
consolidation
that
happens
because
they
now
have
enough
experience.
B
D
C
D
Yeah
I
I
can
provide
tons
of
you,
know,
questions
I
was
I
have
been
asked
to
for
vc
because
because
I
have
to
I've
pushed
very
hard
to
make
production,
so
I
got
a
lot
of
questions
from
production
team
so
so
about
the
consonants.
So
I
can
provide
that
aspect
for
sure
but
yeah,
but
for
namespace.
I
still
think
you
know
you
guys
may
be
agreeing.
You
already
have
some
questions
for
people
if
they
choose
hnc.
D
You
probably
already
answered
some
of
the
questions.
Why
you
know
use,
as
you
can
see,
is
okay,
it's
good
enough
for
your
use
case.
Do
they
address
their
concerns?
So
you
know
I
mean
there
are
cases
people
just
say
that
vc
is
too
costly.
I
don't
want
to
spend
money
on
the
control
plan
so
as
as
a
yes
yeah,
so
I
agree
so
in
my
in
my
opinion,
so
vc
is
kind
of
fit
for
you
know
larger
organizations.
So
it's
not
very
good
for
small
small
scales.
D
If
you
only
have
a
few
users
or
even
tons
of
users
may
not
may
not
good,
I
mean
I
mean
name.
Space
may
be
good
enough.
So
it's
not
the
same
marty
cluster
many
cases,
marty
cluster.
I
don't
I
don't
know
how
you
guys
see
the
marty
cluster,
why
they
they
have
to
be
there
in
one
organization,
but
in
my
case,
is
at
least
in
my.
I
have
seen
cases
multi-cluster
that
is,
for
example,
in
edge
use
cases.
D
They
have
to
have
multiple
clusters
because
they
are
geography,
different
one
cluster
to
management
or
small
clusters,
which
makes
sense
to
me
other
than
that.
I
don't
know
I
I
heard
from
apple
from
chris.
That
apple
sounds
weird,
but
but
that's
what
he
said
saying
that
adding
a
node
to
a
cluster
is
difficult
but
create
creating
a
cluster
is
easy.
D
F
B
F
In
our
use
case,
too,
right
is
anything
that
runs
on
our
cluster
that
touches
phi
data
needs
to
go
through
proper
reading.
So
we
have
two
clusters,
one
for
phi
data
and
one
for
not
and
like,
and
then
the
not.
We
can
do
hnc
and
kind
of
segregate
things
that
way,
but
and
then
same
with
the
phi,
but
like
we
still
need
multi-cluster
for
that,
just
because
otherwise
we're
constantly
every
single,
every
single
you
know,
upstream
code
change
needs
to
go
through
documentation,
funness,
so
yeah.
F
F
B
F
Yeah
we're-
and
we
are
there's
still
one
piano-
we're
so
late
for
somebody
to
approve
the
pr
to
me,
be
an
official
subproject,
there's
like
a
pr
to
be
in
a
cigar
like
it's
just
in
the
yaml
like
we're
there,
but
like
there's
a
pr
for
the
yama,
but
we
have
the
the
repo
and
so
fey.
I
was
actually
going
to
reach
out
to
you.
After
this,
since
you've
been
slowly
getting
virtual
cluster
out,
I
was
wondering
what
your
process
was
to
preserve
git
history
without
muddling
everything
yeah.