►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
SIG Multicluster Intro - Jeremy Olmsted-Thompson, Google & Paul Morie, Red Hat
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. Beyond the technical details, we'll also cover the results of an on-going survey to gather feedback relevant to and assess adoption of the current SIG subprojects. Finally, we'll also be soliciting additional feedback from the community 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/Zew0
B
B
So
thanks
for
joining
us
a
little
overview
of
what
we're
going
to
cover
first
we're
going
to
talk
about
what
the
sig
is
about
and
how
you
can
contribute
and
then
we're
going
to
talk
about
the
history,
how
we
got
here,
the
evolution
of
cube,
fed,
v1
and
2
and
the
cluster
registry,
and
then
we'll
go
into
what's
happening.
Now
we
have
multi-cluster
services
api,
we
have
a
new
work.
Api
project
cube,
fed
v2,
is
still
evolving
and
we're
going
to
talk
about
a
cluster
registry
where
you
think.
A
A
A
The
first
project
that
we
can
really
attribute
to
the
sig
is
a
project
that
many
people
have
probably
heard
of
called
kubernetes
federation.
The
federation
project
is
about
spreading
copies
of
of
a
resource
to
multiple
clusters
and
possibly
overriding
those
those
resources
or
parts
of
them
for
certain
clusters.
A
A
A
A
It
wasn't
supported
by
any
major
vendor
and-
and
there
was
also
not
a
consensus
in
the
community
about
exactly
what
the
right
problems
to
solve
were
the
the
folks
that
were
contributing
at
the
time
all
got
together
and
tried
to
determine
where
there
might
be
areas
of
overlapping
interest
and
where
there
might
be
some
consensus
about.
Perhaps
some
individual
problems
to
solve
that
were
part
of
a
greater
whole
and
the
the
most
agreement
that
they
could
find
was
basically
that
there
need
to.
A
A
A
A
So
we
can
probably
see
by
now
that
one
of
the
central
challenges
that
we
have
in
this
area
is
exactly
how
we
should
track
clusters
that
software
that
works
with
multiple
clusters
is
interested
in
working
with
the
the
real
challenge
that
that
is,
or
one
of
them
anyway.
That
is
part
of
creating
the
cluster
registry.
Is
that
it's
really
easy
to
talk
about
conceptually
a
lot
of
you
that
may
be
watching
that
maybe
haven't
seen
this
content
before
might
be
kind
of
nodding.
A
Your
heads
that
it
makes
sense
that
you
should
have
a
list
of
clusters
or
a
set
of
clusters
to
track,
but
it
turns
out
to
be
really
kind
of
difficult
to
frame
up
exactly
what
that
means
and
how
that
translates
into
software.
That
accomplishes
something
useful
to
users,
but
is
is
focused
on
that
registration
type
of
primitive.
A
A
Just
make
I'll
make
a
plea
here
for
you
to
help
us
by
telling
us
what's
important
for
you
to
get
from
the
community
in
our
current
efforts
that
that
we're
going
to
talk
about
in
sort
of
the
second
logical
part
of
this
talk,
I
want
to
make
it
clear
that
we're
trying
to
avoid
characterizing
a
registry
as
a
first
step.
Instead,
we
want
to
focus
on
the
most
essential
parts
of
the
problems
that
we're
trying
to
solve
and
kind
of
work
backwards
to
the
registry
concept.
B
So
let's
talk
about
the
multi-cluster
services
api,
so
first
services
are
a
multi-cluster
building
block.
They
solve
a
specific
problem,
but
everybody
kind
of
needs
to
solve
this
problem.
No
matter
how
you
want
to
have
your
clusters
working
together,
you
need
some
way
for
them
to
communicate,
so
we
started
building
on
the
concept
of
namespace
sameness,
and
that
is
that
a
namespace
should
have
a
consistent
meaning
throughout
your
clusters.
B
Not
every
namespace
needs
to
have
some
multi-cluster
significance,
but
you
probably
want
to
avoid
a
situation
where
a
given
namespace
means
something
in
one
cluster
and
something
entirely
different,
a
number
in
another
cluster.
And
if
you
have
a
multi-cluster
namespace,
you
probably
want
it
to
be
somewhat
consistently
multi-cluster
and
not
pick
and
choose
which
namespaces,
which
clusters
are
exposing
a
namespace
and
which
aren't
so
to
start.
We've
we've
focused
on
really
just
trying
to
find
the
api
needed
to
allow
common,
behavior
and
tools
to
develop.
B
We
wanted
to
come
up
with
the
bare
minimum
that
we
needed
so
that
there
could
be
a
common
way
to
talk
about
a
multi-cluster
kubernetes
service,
but
we
wanted
to
leave
room
for
various
implementations.
So,
for
example,
a
control
plane
can
be
centralized
or
decentralized
with
this
model,
but
for
consistency,
consumers
only
ever
need
to
rely
on
local
data.
B
A
A
Your
input
is
extremely
valuable
here.
Both
use
cases
that
you're
interested
in
prior
art
and
especially
learning
experiences
that
folks
have
had
from
maybe
you've
implemented
an
api
like
this
yourself
or
maybe
you
have
a
tool
that
does
this
job
for
you
that
you
really
like
we'd
love
to
hear
about
all
that-
and
I
want
to
take
a
moment
here
to
just
give
a
shout
out
to
valerie
lancy
for
her
contributions
and
catalyzation
of
of
this
particular
problem.
A
A
Next,
let's
talk
about
cube,
fed
development
which
is
still
underway.
I
want
to
just
call
out
that
there's
no
one-size-fits-all
solution
in
this
really
complex
and,
frankly,
sometimes
confusing
problem
space.
That's
going
to
work
equally
well
for
every
user
and
every
use
case
that
every
user
has
the
cube,
fed
model
works
well
for
some
users
and
use
cases,
and
I
want
to
give
a
shout
out
here
to
jimi
and
hector
and
others
from
d2
iq
for
helping
to
move
the
project
forward.
A
This
is
interesting
because
it
comes
back
to
that
cluster
registry
concept.
How
does
a
pull
reconciler
running
in
a
remote
cluster
gain
access
to
observe
the
cluster
where
the
cube
fed
api
surface
exists
so
that
that
cluster
registry
problem
is
kind
of
popping
up
again
and
waving
at
us
all?
Right
back
to
you,
jeremy.
B
So
hopefully,
we've
done
a
good
job
of
kind
of
explaining
that
a
cluster
registry
is
harder
than
it
sounds.
Yes,
we
need
one
most
likely.
We
we
just
don't
know
exactly
what
it
is.
So,
the
more
use
cases
we
have
the
easier
it
will
be
for
us
to
understand
what
the
boundaries
should
actually
be.
What
should
be
included
in
that
cluster
registry?
What
should
be
defined
in
the
api
and
and
what
can
be
an
add-on
or
other
implementation?
B
We
can
only
know
this
if
we
know
what
your
use
cases
are
and
if
you
tell
us
there
are
some
things
that
are
pretty
obvious
like
there
needs
to
be
a
concept
of
a
cluster
identifier
to
identify
each
cluster,
and
you
know
we're
seeing
from
the
multi-cluster
services
implementation
that
they're,
probably
that
identifier
probably
needs
to
be
a
valid
dns
label
and
definitely
needs
to
be
unique.
But
we
don't
know
what
else
what
else
is
going
to
be
required.
So
what
are
the
other
building
blocks
that
we're
missing
come
come?