►
From YouTube: Kubernetes Working Group for Multi-Tenancy 20220308
Description
In which the intrepid working group designs their approach to delivering multi-tenancy documentation to the upstream project.
A
B
Yes,
I
think
you
know
we're
making
progress
and
we
don't
have
to
get
into
unless
there's
some
burning
issue.
We
can
obviously
just
address
comments
and
other
things
asynchronously,
but
the
main
thing
I
wanted
to
make
sure
if
you're,
all
okay
with
the
schedule
and
the
proposed
date.
So
maybe
if
you
just
want
to
go
down
to
that
section.
B
Right
so
yeah,
I
think
we
should
be
seems
like
the
main
sections,
there's
some
already
quite
quite
a
bit
of
activity
and
other
things
on
some
of
the
other
sections
we
may
not.
You
know.
Maybe
we
may
need
more
time,
but
I
think
we
have
till
the
end
of
march
to
complete
pretty
much.
You
know
the
at
least
something
we
can
convert
into
a
pr.
D
B
E
E
C
B
C
Okay
sure,
sorry
about
that
yeah,
I
just
wanted
to
see
if
we
could
find
out
if
we
could
get
people
to
sign
up
for
this,
because
if
you
look
at
the
topics
that
we
want
in
there,
sandboxing
isolation,
etc.
Yeah,
I
don't
have
a
lot
of
experience
in
any
of
those
areas
and
I
think
that
grunges
and
jeremy
well
rhonda.
I
can't
remember
if
you
experienced
there,
but
I
think
jeremy
did
as
well
like
one
of
the
two
of
you
or
both
of
you
plus
considerations
just
for
sas.
C
I
think,
might
be
useful
to
put
into
this
section
as
well,
and
so
I
was
wondering
if
we
could,
if
maybe
some
of
the
things
that
we
were
putting
into
like
concepts
and
things
based
tendency
might
be
better
off
done
in
additional
considerations.
Or
maybe
we
break
that
out
into
some
higher
level
stuff
based
on
people's
expertise.
D
So
hey,
okay,
are
you
all
able
to
hear
me
properly?
This
is
david.
I
can
hear
you
guys
yeah
so
yeah.
I
just
turned
on
my
videos
so
that
you
can
put
my
face
to
my
name
but
I'll
turn
off
the
video.
Just
I'm
having
a
little
bit
of
choppy
bandwidth
issues
here,
but
adrian
to
your
point,
what
I
feel
is
yeah
the
one
other
considerations
that
as
part
of
additional
consideration,
what
we
we're
thinking
at
cloud
arc
is.
What
we
have
seen
is.
D
D
So
one
of
the
things
that
we
would
like
to
add
and
which
can
go
in
the
additional
considerations-
and
I
can
definitely
work
on
that-
is
this
aspect
of
what,
while
building
assassins
you
mentioned,
sas
related
things
can
go
in
there.
How
do
operators
play
into
an
overall
sas
delivery
so
yeah?
That
is
something
that
makes
sense.
D
C
Yeah,
so
maybe
we
need
to
have
additional
consideration,
then
either
we
have
a
dedicated
sas
subsection
in
here,
or
maybe
we
just
have
like
additional
considerations
for
sas
additional
considerations
for
multi-team,
because
that's
kind
of
like
up
here
in
use
cases.
Those
are
the
two
sort
of
divisions
that
we're
creating
and
I
I
like
that
as
a
general
organizing
principle
for
the
stock,
so
yeah
maybe
like
up
here
in
use
case.
We
don't
need
to
do
everything
we
just
need
to
introduce
the
concepts.
C
Then
we
go
into.
You
know
other
key
concepts,
some
stuff
about
name
spaces
and
and
and
virtual
clusters
with
control
planes,
and
then
we
can
go
into
more
of
the
considerations
down
there.
Maybe
we
can
take
this
stuff,
like
name
space
based
and
see
based,
and
maybe
we
can
go
into
sort
of
general
approaches.
C
E
E
C
And
actually
that's
a
good
way
instead
of
calling
it
like
general,
we
like
or
common
concerns.
We
can
basically
just
call
them
isolation
like
that,
and
we
can
use
isolation
levels
out
of
to
key
concepts
at
a
top
level
section,
and
then,
under
that
we
have
name
space,
we
have
virtual
control
planes
and
then
we
can
even
add
a
multi-cluster
as
it
can
just
as
an
option
just
to
say,
like
yeah,
no
sharing
within
a
cluster
at
all.
If
you,
if
you
really
need
that
kind
of
isolation,.
E
C
That
sounds
good
yeah.
I
would.
I
would
love
to
mention
hard
and
soft
just
so
that
we
can
sort
of
knock
them
down
and
say
we're
not
going
to
use
those
terms
because
they're
meaningless.
You
can
have
harder
and
softer
among
along
many
axes.
I
think
jim
and
tasha
ferguson
like
harp
on
this
subject
many
times
yeah
jim.
Are
you
okay
with
us
to
go,
make
that
change.
B
B
C
B
C
B
Okay,
yes,
I'm
just
looking
at
the
table
of
contents.
I
think
this
flows
pretty
well,
so
we're
saying
introduction
will
go
into
use
cases,
key
concepts,
then
isolation
levels,
name,
space
based
virtual
control,
planes
and
dedicated,
so
it's
increasing
levels,
and
then
we
have
other
considerations
yeah.
So
one
one
question
I
had,
which
I
don't
know,
I
guess
it's
just
something
that's
been
so
we
use
the
term
isolation,
but
I
also
see
segmentation
used,
especially
when
it
comes
to
networking
and
things
like
that.
Is
anybody
and
I
couldn't
find
any
good
reference
for.
B
C
B
At
least
the
way
I
was
thinking
of
it
as
like,
if
you
have
in
a
network
segmentation,
typically
refers
to
vlans
you're
on
a
when
we're
talking
about
the
kubernetes
api,
we're
segmenting
the
api
to
have,
you
know,
objects
with
the
same
name,
it's
kind
of
creating
a
space
under
the
main
route,
but
isolation
means
you're,
preventing
one
segment
from
seeing
the
other
segment,
so
I
was
kind
of
thinking
of
it.
The
other
way
around
where
isolation
is
stronger
than
segmentation,
but
just
my
theory,
I
don't.
E
I
mean
just
you
know,
you
know
my
personal
opinion.
Segmentation
is
something
that
I've
seen
mostly
on
the
networking
side
of
our
realm
right,
but
isolation
sort
of
applies
to
broader,
like
it
could
have
storage,
insulation
and
sure
yeah,
compute
isolation,
for
example
right.
So
it's
a
little
bit
much
broader
and
I
think
yeah
segmentation
is
very
focused
on
the
networking
aspect,
at
least
from
what
I've
seen.
B
C
B
C
B
A
C
Okay,
I
haven't
really
heard
that
term
and
so,
to
a
certain
extent
like
we're
inventing
the
terms
that
are
that
we're
going
to
try
to
standardize.
So
if
we
decide,
we
only
want
to
standardize
one
of
them,
which
is,
I
think,
what
I've
leaned
towards.
If
we
don't
have
a
crisp
definition,
let's
just
use
one,
at
least
for
the
terms,
we're
introducing
that's
kind
of
the
way
I
would
tend
to
lean.
B
C
Yeah,
if
we're
referring
to
like
a
well-known
term
from
some
other
domain
like
networking,
which
I'm
not
an
expert
in
at
all,
like
microsegmentation,
it's
not
a
term
I've
ever
heard
before.
So,
if
we're
referring
to
like
a
term
that
has
some
well-known
meaning
in
some
other
domain,
then
sure,
but
if
we're
just
talking
about
like
kubernetes
multi-tenancy,
I
think
we
can
keep
it
simple.
If
okay
is
where
the
direction
I
tend
to
have.
B
D
So
one
suggestion
that
I
had-
and
probably
this
is
what
you
are
referring
to
our-
if
not
probably
we
can
consider
that,
is
I
remember
in
the
first
iteration
you
had
said
that
we
can
have
primary
young
secondary
authors,
that
kind
of
split
which
I
felt
probably
may
not
work
out
based
on
you
know.
Certain
folks
are
probably
dealing
with
certain
use
cases
much
more
regularly
than
others.
D
So
what
I
felt
was
we
can
have
someone
like
an
editor,
and
probably
you
are
adrian
who
have
been
exposed
to
many
of
these
use
cases
or
have
had
a
chance
to
broadly
look
at
this
space
for
a
lot
more
time
can
be.
You
know,
overall,
in
charge
of
the
whole
thing
in
the
sense
that
once
all
the
content
comes
in,
then
you
sort
of
make
sure
that
it
all
meshes
well
and
flows
really
well.
B
B
C
Yeah
and
I'm
happy
to
help
with
that
as
well,
even
though
I'm
writing
some
of
the
sections
too
yeah
jim,
if
you
want
to
take
the
lead
on
the
on
the
sort
of
redacting
and
editing
and
stuff
like
that,
that's
that
sounds
good
to
me.
If
you
want
me
like,
I
might
make
comments
elsewhere,
but
I
can
leave
them
for
you
to
resolve.
B
Sounds
good
all
right
yeah,
so
we'll
we'll
update
that.
So,
let's
you
know,
I
guess
once
we
I
don't
know
if
we
don't
need
to
do
this
real
time,
but
if
there's
any
gaps
in
where
we
need
help,
let's
figure
out
anyone.
Certainly
I
think
they're
yeah,
I'm
trying
to
think
about
from
security
or
other
areas.
If,
if
we
do
want
to,
you
know,
request
folks
to
help
with
specific
sections
we
can
otherwise
we
can
take
a
first
stab
and
just
work
through
and
then
broaden
the
review
process.
B
B
F
Yeah
what
I'm
saying
that
the
the
figures,
maybe
is
even
harder
to
get
a
consensus
about
about
things
to
show,
so
I
think
you
can
set
a
tune.
So
so
we
do
expect
every
editor
add
a
lot
of
figures.
It's
make
it
really
really
hard.
So
maybe
you
can
just
specify
one
guys.
Just
don't
have
too
much
figures
so.
B
Can
help
we
can
also
again,
you
know,
ask
the
cncf
help
desk.
They
have
some
folks
who
can
help
with
graphics
if
we
want
to
just
drop
something,
because
I
I
don't
see
too
many
diagrams
in
the
kubernetes
talks,
but
there
are
some
like
the
four
c's
of
security
and
a
few
others
right,
which
are
just
high-level
graphics,.
F
C
C
So
today,
if
you've
got
like
a
great
diagram
that
you
want
to
make
people
can
other
people
can
complain,
but
if
they
don't
want
to
put
in
the
work
to
to
to
actually
update
the
figure,
then
then
I
would
say
that
whatever
you
want
goes
in.
I
generally
don't
write
a
lot
of
figures,
because
I'm
lazy,
because
figures
are
often
better
so
but.
F
F
F
So
in
that
sense,
maybe
even
that
figure
can
be
a
collaborative.
You
know
effort.
Oh,
we
have
somebody
just
on
behalf
of
us
just
draw
figures
which
most
likely
so
that's
the
reason
I
want
to
bring
it
up.
So
I
I
I
see
the
I
see
the
benefit
of
having
figures,
but
I
would
say
just
one
or
two
maximum
sure.
B
Yeah,
so
if
it,
if
it
helps,
prove
or
you
know,
make
a
point
or
emphasize
something
or
clarify
something,
definitely
let's
I
don't
think
we
should
shy
away
from
taking
a
stab
at
it
and
we
can
worry
about
the
sort
of
normalization
and
putting
it
in
the
right
graphics
later
or
we'll
get
get
help
for
that,
but
yeah.
If
it's,
I
guess,
for
these
type
of
dots,
it's
mostly
text
that
that
seems
to
be
the
norm.
C
B
B
Okay
and
one
other
thing
to
point
out,
is
google
docs?
Has
a
pretty
nifty
versioning
feature
now
right,
so
you
can
always
save
a
version.
So
if
you're
making
major
changes,
especially
to
a
section,
somebody
else
is
also
working
on,
just
go
and
save
a
version
name
it
something,
and
then
you
can
kind
of
edit
it
right.
So
we
don't
have
to
you
know,
because
otherwise
it's
always
a
little
bit
awkward.
B
D
D
B
B
All
right,
yeah
one
other
thing
I
just
wanted
to
quickly
point
out
is
in
typically
for
kubernetes
talks.
I
think
that
guidance
or
even
other
cncf
docs,
has
to
not
mention
specific
tools
but
to
say
things
like
if
you
want
to
say
ci,
cd
or
build
system,
that's
perfectly
fine,
but
instead
of
saying
jenkins,
even
as
examples
and
then
later
we
can
have
a
section
with
the
right
disclaimer,
where
we
kind
of
put
third
party
tools
and
there's.
A
B
C
A
B
A
Yeah
and
to
kind
of
elaborate
on
what
jim
was
describing.
If
you
look
at
the
docs,
usually
like
there's
like
a
very
sort
of
third
person,
removed
explanation
of
the
concept
and
then
at
the
bottom,
they'll
be
like
in
red
hat.
You
do
it
this
way
on
google
cloud,
you
do
it
this
way
right
and
so
they'll
there
can
be
specific
kind
of
stuff
like
at
the
bottom.
D
James
from
tasha
and
adrian,
so
the
one
question
that
I
have
not
related
to
this
discussion,
but
broadly
the
multi-tenancy
discussion
was
what
is
happening
at
the
cncf
level.
Remember
there
was
this
entire
thread
of
cncf
is
also.
There
is
some
folks
who
are
working
on
a
multi-tenancy,
end-to-end
picture
and
how
that
will
work
together
with
what
we
are
doing
here
and
has
anyone
heard
any
updates
or
what's
happening
there.
D
So
yeah
yeah
the
feeling
sorry
I
got
to,
but
but
then
what's
the
I
mean
the
effort
that
is
happening
on
that
side
at
the
broader
level?
How
will
it
really
proceed
further?
I
I
was
sort
of
not
sure
because
key
as
we
are
just
discussing
it
will
come
down
to
every
tool
and
figuring
out.
What's
the
multi-tenancy
pusher
of
every
tool,
and
then
you
know,
how
do
you
put
together
the
end-to-end
thing,
but
again
the
core
will
come
down
to
whether
kubernetes?
What
are
the
options?
History?
What
are
the
options?
A
B
Yeah,
I
think
that
was
from
the
app
delivery,
cncf
group
right.
They
had
a
issue
and
they
kind
of
linked
to
our
issue
or
we
linked
to
theirs,
or
so
I
think
the
general
so
something
I
guess.
The
brief
answer
like
tasha
said
is,
you
know
we
don't
know
and
we
don't
kind
of
control,
what
exactly
they
are
doing,
but
obviously
we
want
to
align,
and
you
know
the
idea
is
once
we
have
something
worth
reviewing.
We
would
go
back
to
them
and
ask
them.
B
A
C
Yeah,
that's
how
I
want
to
do
this.
I
want
to
get
a
first
draft
or
just
like
publish
your
first
version
before
worrying
too
much
about
how
it
fits
into
their
stuff,
because,
like
I,
I
would
be.
It
wouldn't.
Surprise
me,
for
example,
if
they
focus
solely
on
let's
say
the
multi-team,
what
we're
calling
the
multi-team
aspect
and
ignore
sas
multi-tenancy
completely.
C
I
don't
have
to
work
into
their
framework.
I
would
rather
get
like
our
stake
in
the
ground
and
and
then
sort
of
iterate.
If
there
are
ways
that
we
can
make
it
more
compatible
with
what
they're
doing
or
vice
versa,
and
if
they
want
to
align
to
some
of
the
ideas
that
we've
put
in
as
well
so
yeah,
I
wouldn't,
I
wouldn't
plan
up
too
much
upfront.
I
think
we've
got
a
pretty
good
set
of
ideas
and
concepts
and
and
suggestions
for
implementations
that
are
tightly
tied
to
kubernetes.
C
B
Yeah
and
I
think
some
of
the
questions
you
had
added
dave
data
may
actually
belong
at
that
level.
Right
and
those
are
very
good
questions.
Obviously
somebody
has
to
think
about
if
they're,
implementing
a
multi-tenant
app
or
if
they
want
to
take
a
single
tenant
app
and
you
know
kind
of
deliver
it
as
a
multi-tenant
app
yeah,
but
for
our
focus
I
think
it
would
be
best
to
just
kind
of
stay
as
close
to
kubernetes
as
possible
and
then
point
to
other
things
for
the
broader
level
make
sense.
E
Okay,
so
jim
so
jim,
like,
like
adrian
mentioned
for
the
section
on
additional
considerations,
I've
added
put
my
name
as
well,
so
I
can
take
a
stab
at
the
node
isolation
and
the
fairness
and
the
quality
of
service
sections.
But
I
don't
have
a
whole
lot
of
experience
with
the
sandboxing
aspect.
Right
so
say,
if
someone
wants
to.
B
C
G
B
Yeah,
I
didn't
have
anything
else:
either.
We'll
certainly
will
continue
collaboration
and
if
we
need
to
you
know,
have
smaller
meetings
or
just
discussions
and
slack
or
whatever
works
for
folks
feel
free
to
you
know,
call
that
out
or
just
raise
your
hand
and
say
hey,
you
need
some
inputs
or
help
on
any
section
but
yeah.
This
is
looking
great,
it's
pretty
exciting
and
will
be
awesome
to
get
see
something
in
the
kubernetes
talks.