►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
SIG Multicluster Intro - Paul Morie, Red Hat & Jeremy Olmsted-Thompson, Google
SIG-Multicluster is focused on solving common challenges related to the management of many Kubernetes clusters, across multiple cloud providers (so-called hybrid cloud) and applications deployed across many clusters. In the introduction, we'll give attendees an overview of the current status of the multicluster problem space in Kubernetes and of the SIG. We’ll discuss current thinking around best practices for multicluster deployments and what it means to be part of a ClusterSet. Then we’ll highlight current SIG projects, focused use cases, and ideas for what’s next. Most importantly, we’ll provide information on how you can get involved either as a contributor or as a user who wants to provide feedback about the SIG's current efforts and future direction. This session will mostly be an open dialog; attendees will have the opportunity to ask questions in person as well as leave survey responses that the SIG will use to plan next steps.
https://sched.co/ekGj
B
A
B
Ours,
so
many
of
you
are
probably
familiar
with
cube,
fed
or
kubernetes
federation.
There's
been
a
couple,
different
versions
of
that.
The
first
one
was
built
before
we
had
custom
resource
definitions
and
was
really
about
spreading
a
single
resource
where
that
might
be
a
resource
of
one
of
the
well.
B
B
That
probably
looks
a
lot
like
you
would
expect
a
field
in
a
spec
called
template
to
look
like,
and
then
we've
got
a
section
called
placements
and
overrides
and
those
are
sort
of
what
they
sound
like
the
placement
one
contains,
which
clusters
does
this
resource
go
to
the
overrides
contain?
How
does
it
change
in
a
particular
cluster?
So
if
you
take
a
look,
there,
you've
got
under
overrides.
It's
a
list.
There's
one
item
in
it.
B
So
you
couldn't
just
take
a
helm
chart
for
example,
and
use
it
with
cube,
fed
v2
without
some
alteration
or
transformation,
and
another
point
to
mention
here
is
that
we
attempted
an
integration
with
the
cluster
registry,
but
the
correct
boundaries
were
never
apparent,
and
in
this
in
this
presentation
we're
telling
the
story,
maybe
with
a
new
ordering.
We
haven't
talked
about
the
cluster
registry
yet,
but
we're
about
to
so
just
remember
that
we
tried
to
integrate
cube,
fed
v2
with
a
cluster
registry,
and
there
were
never
really
a
clear
good
set
of
boundaries.
B
B
That's
supposed
to
have
the
resources
that
were
being
pushed
in
the
push
model,
and
it's
maybe
watching
a
cluster
that
has
the
federation
api
surface
and
pulling
it
in
so
again.
This
touches
that
kind
of
cluster
registry
concept,
but
there
there's
not
a
real,
clear
boundary
about
what
parts
of
that
problem
a
cluster
registry
could
solve.
I
do
want
to
just
pause
here
and
say
and
give
a
shout
out
to
jimmy
and
hector
and
others
from
d2
iq
for
helping
to
move
this
project
forward.
Thanks
a
lot,
your
work
is
appreciated.
B
Wanna
we
just
head
on
over
to
the
next
one
all
right,
so
that
cluster
registry
thing
we
mentioned
a
couple
times.
You've
probably
heard
of
this.
The
history
behind
the
cluster
registry
is
that
in
between
cube,
fed
v1
and
cube
fed
v2,
there
was
a
point
within
the
community
where,
basically,
the
only
thing
that
folks
could
agree
on
in
this
very
spacious
problem
space
is
that
if
you're
working
with
multiple
clusters,
it
makes
sense
to
try
to
track
them
and
to
have
some
registry
type
thing.
B
A
A
We
don't
want
to
solve
problems
that
don't
really
need
to
be
solved
and
real,
really
just
kind
of
focus
on
the
specific
functionality
that
we
want
to
build
to
meet
real
specific
needs.
So
we've
decided
to
kind
of
work
backwards
from
specific
problems
into
something
bigger.
Only
where
necessary.
We're
not.
You
know
we're
not
looking
to
solve
all
of
the
problems.
We've
got
a
few
use
cases
that
seem
very,
very
clear
that
are
that
are
well
defined,
that
you
know
we're
seeing
users
and
other
community
members
continuously
bring
up
and
we're
trying
to
figure
out.
A
So,
let's
talk
about
cluster
set
so
note
that,
even
though
it
looks
like
the
other
kubernetes
set
resources
you
you
may
be
used
to
seeing
this
is
a
pre-api
concept.
It
does
not
currently
correspond
to
a
real
resource,
but
it's
a
useful
concept
to
talk
about,
so
a
cluster
set
represents
a
pattern
of
use
that
we
see.
A
That
is,
a
group
of
clusters
governed
by
a
single
authority
that
could
be
a
team,
a
company,
any
organization,
even
an
individual,
but
some
set
of
clusters
around
which
you
can
create
concrete
statements
owned
by
someone
who
can
make
basically
absolute
decisions
about
the
behavior
of
this
cluster
set
within
the
set.
We
see
a
high
degree
of
trust.
A
Think
about
this
as
a
as
the
extension
of
the
trust
that
you'd
see
with
within
a
single
cluster,
not
necessarily
a
case
where
you
know
everything
can
talk
to
everybody
or
everything
needs
to
be
exposed,
but
you
should
consider
you
know
running
applications
in
the
same
cluster
set
if
you
would
run
them
in
the
same
cluster,
that
doesn't
mean
they
need
to
talk
to
each
other.
You
know,
obviously,
there
are
still
permissions
and
stuff
in
play,
but
you
know
owned
by
that
same
authority
who
feels
comfortable
running
these
these
applications
together.
A
We
also
introduced
the
concept
of
namespace
sameness.
This
applies
across
all
clusters.
In
a
set,
and
what
this
means
is
that
permissions
and
the
various
characteristics
of
a
name
space
are
consistent
across
all
of
the
clusters
in
a
cluster
set
for
a
given
namespace,
that
is,
you,
shouldn't
have
namespace
foo,
be
used
for
one
thing
and
have
one
meaning
in
one
cluster
and
in
another
cluster
in
the
same
set,
have
it
used
and
means
something
else
with
completely
different
ownership.
A
Namespace
should
be
that
primitive
that
you
use
to
share
ownership
across
clusters
and
should
behave
consistently
in
each
in
each
cluster,
in
which
they're
deployed
that
said,
namespaces
don't
necessarily
have
to
exist
in
every
cluster.
It's
just
that
any
cluster
they
exist
in.
They
should
be
behave
in
roughly
the
same
way.
A
So
one
of
the
first
use
cases
for
this
cluster
set
is
the
multi-cluster
services
api.
So
this
started
as
a
kepp
and
has
kind
of
been
evolving
to
alpha
right
now.
But
basically,
services
are
a
multi-cluster
building
block
it's
a
specific
problem,
but
it's
a
specific
problem
that
basically
everybody
has
in
the
multi-cluster
case.
A
A
We
left
a
lot
of
room
for
implementers
to
make
different
decisions,
but
we
wanted
to
focus
on
that
basic
api
and
behavior
that
that
means
that
whenever
you
use
this
api
with
any
implementation
on
any
platform
or,
however,
you
want
to
deploy
it,
you
get
similar
characteristics
and
can
kind
of
count
on
on
a
standard
behavior
and
we've.
We
actually
see
a
few
implementations
in
progress.
Already
we
have
submariner
has
been
working
on
an
implementation
with
submariner
lighthouse.
A
A
The
control
plane
in
our
design
can
be
centralized
or
decentralized,
but
consumers
only
ever
rely
on
local
data,
and
this
is
a
big
point,
so
we
left
open
for
all
of
those.
You
know
implementations
I
I
mentioned
and
any
more
that
may
come
the
way
that
you
build.
Your
control
plane
is
not
dictated
by
the
api,
but
we
did
want
to
make
it
consistent
that
consumers
only
ever
have
to
rely
on
on
cluster
local
data
when
consuming
a
service.
A
B
B
So,
instead
of
distributing
individual
resources,
the
the
main
idea
of
the
work
api
is
that
you'll
distribute
a
collection
of
resources
that
are
related
to
one
another,
so
think
about
the
difference
between
distributing
a
single
deployment
to
many
clusters
versus
distributing
a
deployment.
Maybe
it's
got
a
secret
or
config
map
that
it
references,
maybe
there's
a
service
in
front
of
that
deployment
and
you'd
want
to
distribute
those
things
together.
So
I'll
also
just
add
that
this
is
a
pre-alpha
state
right
now,
with
the
kept
that's
coming
together.
B
So,
if
we
think
about,
if
we
think
about
taking
away
all
the
dimensions
of
scheduling
and
having
overrides-
and
you
know
powerful
selection
primitives
for
where
something
should
go
and
just
think
about,
how
would
we
want
to
make
sure
that
we
applied
a
collection
of
some
resource
on
a
cluster
and
we
had
a
meaningful
status
about
that
work?
No
pun
intended
a
meaningful
status
about
whether
those
resources
had
been
fully
applied.
B
But
if
we
start
walking
backwards
thinking
about
those
higher
level
problems,
we
start
to
touch
this
sort
of
registration
concept
or
at
least
identity
concept
around
having
a
coordinate
to
use.
In
reference
to
a
particular
cluster,
where
something
should
be
scheduled,
so
this
is
still
a
work
in
process.
We
are
work
in
progress.
We
we
need
your
input
and
I
sense
that
there's
probably
a
fairly
strong
chance
that
maybe
one
or
two
people
at
least
watching
this
presentation-
have
have
built
something
like
work
api
before,
or
at
least
are
interested.
B
B
A
So
we're
talking
about
the
the
concept
of
a
cluster
id,
and
so
the
trick
here
is:
we
do
not
have
a
registry
api,
so
how
do
we
come
up
with
a
coordinate
without
a
registry
api
and
what
we're
looking
at
is
taking
that
step
back
and
trying
to
come
up
with
the
the
real
common
use
case
and
really
what
we
need
is
a
way
to
just
uniquely
identify
a
cluster
within
a
cluster
set
for
the
lifetime
of
membership.
So
this
isn't
attempting
to
define
the
identity
of
a
cluster
forever.
A
It
does
seem
that
this
id
needs
to
be
discoverable
within
the
cluster.
So
you
know
we
want
a
cluster
to
know
who
it
is
relative
to
the
cluster
set.
We
want
to
give
a
reference
for
multi-cluster
tooling
to
build
on
within
the
cluster,
so
you
know
there's
some
characteristics
that
we
want
there.
You
know,
for
example,
having
the
the
id
be
a
valid
dns
label.
This
is
something
that's
important
to
the
multi-cluster
service
having
a
way
to
disambiguate
back-ends
for
headless
services
between
clusters.
A
Other
uses
are
maybe
a
coordinate
to
use
for
scheduling,
work
with
the
work,
api
or
or
just
an
annotation
for
metrics
and
logs,
so
that
you
can
determine
which
cluster
is.
Is
you
know,
potentially
having
problems
and
aiden
debugging,
but
again
we're
kind
of
taking
a
step
back
and
and
trying
not
to
solve
optional
problems
and
really
just
get
to
that
basic
consistent
use
case
that
we
need
in
order
to
enable
kind
of
the
next
level
of
multi-cluster,
tooling,.
B
So
in
case,
it's
not
clear,
we
need
and
want
your
input.
We'd
love
to
have
you
have
you
involved
in
in
our
part
of
the
community
share
your
use
cases,
problems
your
ideas
and
you
can
check
out
our
home
page.
It's
under
sig
multi-cluster
in
community
we've
got
a
slack
channel,
also
called
sig
multi-cluster
and
hold
on
to
your
hat,
because
we
have
a
list
which
is
also
called
kubernetes
multi-cluster
and
if
you'd
like
to
join
us
for
our
meetings
there,
tuesday
12
30
eastern
9,
30
pacific
time.