►
From YouTube: Intro: Kubernetes SIG Multicluster - Daneyon Hansen, Cisco, Quinton Hoole & Irfan Ur Rehman, Huawei
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Kubernetes SIG Multicluster - Daneyon Hansen, Cisco, Quinton Hoole & Irfan Ur Rehman, Huawei
SIG-Multicluster is focused on solving common challenges related to the management of multiple Kubernetes clusters, and applications that exist therein. We are responsible for designing, discussing, implementing and maintaining API’s, tools and documentation related to multi-cluster administration and application management. This includes not only active automated approaches such as Cluster Federation, but also those that employ batch workflow-style continuous deployment systems like Spinnaker and others. Standalone building blocks for these and other similar systems (for example a cluster registry), and proposed changes to kubernetes core where appropriate are in scope. In this intro we will give you an overview of the projects we're currently actively working on, how best to get involved, and what our future plans look like.
To Learn More: https://sched.co/Grbw
A
A
The
intention
of
the
session
today
is
really
just
to
you
know
tell
you
who
we
are,
what
we
do,
what
we
think
about,
give
you
a
little
bit
of
background
into
some
of
the
work
that
we've
done
in
the
recent
past
and
we
have
quite
a
fun
demo
for
you
today.
Danyoung
will
be
telling
you
a
little
bit
about
how
they
used
Federation
in
particular,
which
is
one
of
our
sub
projects
in
the
multi
cluster
sig
to
deploy
and
manage
sto
applications,
both
STR
and
the
applications
that
run
on
top
of
it.
A
We'll
have
a
healthy
Q&A
session
afterwards,
but
I
personally
don't
mind
if
anyone
wants
to
interrupt
me
along
the
way.
If
you
have
questions
that
you
would
rather
ask
in
the
middle
of
the
talk
instead
of
at
the
end.
That's
that's
also
fine
with
me
right,
so
you
know
we're
going
to
talk
a
bit
about
our
mission.
We
have
these
three
sub
projects,
one.
A
We
call
Federation
it's
in
version
two
at
the
moment,
another
one
called
cluster
Registry
and
another
one
called
cube:
MCI
multi
cluster
ingress
and
then
we'll
have
you
know
demos
and
Q&A,
as
I
mentioned.
So
first
of
all,
let's,
let's
just
step
back
from
the
specific
projects
and
and
get
an
understanding
of
what
the
mission
of
the
sig
is.
So
we
started
off.
Some
of
you
may
have
been
involved
in
the
early
history.
It
used
to
be
called
sig
Federation.
A
We
have
this
project
to
federate,
multiple
clusters
together
and
then
about
a
year
or
so
after
that
we
broadened
the
scope
of
the
sig
to
multi
cluster
issues
in
general.
So
so
there
are
many
different
reasons
why
people
would
want
to
run
multiple
clusters.
We
don't
have
time
to
go
into
those
today,
but
for
those
of
you
who
are
interested
there'll
be
more
discussion
of
that
at
the
deep-dive.
A
Is
it
tomorrow
yeah,
but
suffice
to
say
there
many
different
reasons
you
might
want
to
run
multiple
clusters
and
in
particular,
in
some
cases
large
numbers
of
them
either.
You
know
tens
hundreds,
even
thousands
we
have
cases
of
and
depending
on
why
you're
doing
it.
You
might
have
different
implementations
that
you
prefer
to
use
to
manage
these
multiple
clusters
and
Federation
turns
out
to
be
one
of
the
more
useful
ones,
but
there
are
other
ways
of
doing
it
as
well.
A
So
all
of
those
you
know
we
consider
to
be
in
scope.
Anybody
who's
interested
in
running.
You
know
fairly
significant
numbers
of
clusters
via
whatever
mechanism
we
encourage
them
to
interact
with
our
sig
cooperate
where
they
can
with
other
such
efforts
or
at
least
be
aware
of
what
other
efforts
are
going
on.
A
So
this
is
both
the
management
of
the
actual
clusters
themselves.
So
the
cluster
configurations,
things
like
quotas,
are
back,
although
all
the
kinds
of
things
that
a
cluster
administrator
might
look
after
in
clusters,
as
well
as
applications
that
run
either
in
one
of
many
clusters
or
in
some
cases
across
multiple
clusters.
A
So
if
you
wanted
to
deploy
an
application
that
ran,
you
know
on
every
continent
in
the
world,
you
wouldn't
necessarily
want
to
manage
the
application
in
every
single
one
of
those
continents
and
make
sure
that
the
pieces
in
Europe
could
get
hold
of
the
pieces
in
North
America
if
they
needed
to.
We
try
to
make
some
of
that
stuff
go
away
for
you,
so
we
we
design,
discuss,
implement
and
maintain
api's
tools,
documentation,
etc
related
to
both
of
those
areas.
Cluster
administration,
as
well
as
application
administration.
A
These
are
not
only
automated
approaches,
so
cluster
Federation
for
those
of
you
might
have
come
across
it
before
is
a
very
active.
You
know
it's
a
software
managed
system.
So
not
unlike
kubernetes,
you
have
declarative
configuration
that
you
say
I
want.
You
know
n
replicas
across
some
number
of
clusters
and
then
there's
software
that
you
know
has
a
reconciliation
loop.
That
makes
sure
that
this
is.
You
know
true
from
that
point
onwards,
but
there
are
other
ways
of
doing
it.
A
You
can,
for
example,
you
know,
check
changes
into
github,
for
example,
and
have
clusters
automatically
polling
github
to
find
out
what
their
latest
configuration
is
and
not
necessarily
have
an
ActiveX
control
plane
that
looks
after
all
of
these
clusters.
We
also
consider
that
to
be
a
valid
approach
and
there
are
groups
that
are
following
that
approach
as
well.
A
We
have
tried
to
not
only
build
end
to
end.
You
know.
Solutions
of
cluster
Federation
to
some
extent
is,
is
something
that
you
can
install
and
use
as
a
complete
system,
but
we
also
try
to
make
it
possible
to
use
the
individual
building
blocks
involved
there,
so
that
people
who
might
have
other
use
cases
or
different
ways
they
want
to
implement
multi
cluster
management
can
at
least
make
use
of
some
of
the
pieces
that
we've
built.
So
cluster
registry
is
a
good
example.
A
In
many
cases
you
need
to
you
know,
build
networks
that
span
multiple
clusters
in
one
way
or
another,
and
that
may
be
necessary,
irrespective
of
whether
you
use
Active,
Federation
control
or
some
other
mechanism,
and
there's
lots
more
in
our
readme
file.
For
those
of
you
might
want
to
have
a
look
at
it.
I
think
I've
spoken
mostly
about
the
different
sub
projects
already,
so
we
don't
need
to
go
into
too
much
more
detail
there.
A
Federation
I
think
is
interesting,
so
it
went
through
a
version,
one
iteration,
where
we
basically
prototype
the
whole
thing
using
the
kubernetes
api.
So
we
exactly
use
the
kubernetes
api
as
it
was
defined
and
wherever
we
need
to
extend
it
for
multi
cluster
use
cases,
for
example,
specifying
which
clusters
you
want
your
application
to
run
in
and
perhaps
what
proportion
of
your
application
runs
in
different
clusters.
A
We
used
annotations
and
that
was
purely
a
sort
of
proof
of
concept
mechanism
to
get
an
idea
of
whether
we
were
solving
a
useful
problem
and
what
sort
of
other
primitives
might
be
necessary
once
we'd
done
that,
and
we
got
pretty
far
with
that.
Actually
we
got
the
vast
majority
of
the
kubernetes.
Primitives
were
federated,
so
you
could
create
federated
services.
Jobs
daemon
sets
services
which
could
be
discovered
between
clusters.
All
these
kinds
of
things
were
done.
We
never
took
it
to
GA.
A
That's
got
both
simple
propagation,
so
the
ability
to
propagate
essentially
snapshots
of
the
same
kubernetes
entities
to
multiple
clusters,
but
then
also
has
high
functionality
to
do
the
management
of
these
applications
across
clusters.
So,
for
example,
make
sure
that
if
a
single
cluster
goes
down
your
replicas
get
repopulated
in
a
different
cluster
and
that
applications
in
different
clusters
can
find
each
other
in
a
uniform
way,
irrespective
of
which
clusters
they
might
be
running
in
cluster
registry
and
multi.
Cluster
ingress
I
think
I've
spoken
about
enough
for
the
moment.
B
C
Hi,
sorry
for
that
hi
folks,
I'm,
your
fan,
I
work
with
Wahby
and
I'm,
going
to
walk
you
through
a
couple
of
other
slides
which
basically
talk
about
the
current
status
of
the
projects
that
we
are
at
and
a
little
bit
of
the
roadmap.
What
we
are
going
to
do
in
near
future
and
after
that
I'll
hand
over
to
Danian,
who
will
show
you
a
cool
demo
about
federating,
an
application
like
this
teo,
so
I
think
Quintin
already
talked
about
the
first
sub
sub
project
in
a
little
bit
detail
which
is
Federation,
be
v2.
C
C
A
C
Define
the
Federation
API
is
as
C
Oddie's
like
they
are
quite
advanced
now
and
the
generation
part
or
the
Federation
automatic
Federation
part
of
that
we
are
using
a
tool.
We
call
it
cube
fat,
2
and
more
details
about
this
would
be
there
in
the
deep
dive
that
we
would
be
doing
day
after
tomorrow.
So
people
are
folks
who
are
interested
in
that
then
can
certainly
attend
that.
C
C
We
have
a
push
reconciliation
for
any
arbitrary
k
test
type
we
have
in
terms
of
higher
level
features.
We
have
a
cross
cluster
pluggable
dns
discovery,
or
we
also
call
it
a
service
discovery
mechanism
across
multiple
creators
clusters.
We
use
another
project
for
some
portion
of
it.
We
call
it
external
DNS.
That
project
is
also
hosted
in
community
6.
C
We
have
completed
the
config
based
reconciliation,
so
we
use
a
federated
type.
We
call
it
type
config,
which
is
something
like
mechanism
which
an
admin
can
use
to
ensure
what
or
which
type
to
be
propagated
or
which
type
not
to
be
propagated.
As
I
said,
this
is
just
a
very
high-level
pointers
to
what
features
we
have
completed.
We
will
be
talking
much
more
about
this
in
deeper
details
or
in
the
deep
dive
I
mentioned
this
earlier.
C
C
Currently,
we
do
not
have
a
direct
view
of
or
a
user
centric
view
of,
the
statuses
of
all
those
resources.
So
we
are
working
on
that.
We
are
also
working
on
some
more
high-level
scheduling,
behaviors
one
pain,
point
right
now
or
not
pain.
Point
one
missing
piece
right
now
is
that
any
given
K
tests
resource,
for
example,
you
have
a
helmet
or
you
have
amell's
or
manifest,
which
are
defining
your
application
in
terms
of
K.
It
has
resources.
C
One
more
thing
which
we
might
consider
later
as
in
terms
of
development,
is
the
pool
reconciliation
a
little
bit
of
update
on
Cluster
registry.
Like
winter
mentioned
earlier.
We
have
two
other
projects
in
this
space
as
part
of
the
sig,
so
one
is
cluster
registry.
Another
one
is
cube
and
CI,
so
cluster
registry
is
almost
there
to
be
term
beta,
except
they
have
an
outstanding
issue
which
has
to
do
with
auth
information
to
individual
clusters.
C
So
there
is,
there
has
been
discussion
going
around
that
and
as
soon
as
that
issue
is
resolved,
it
would
probably
be
released
as
beta
cube.
Mci
is
a
little
bit
mature.
So
last
couple
of
months,
the
folks
at
Google
were
actually
collecting
feedback
from
users,
their
users
of
cube
MCI,
and
they
have
received
a
good
amount
of
feedback,
and
a
couple
of
users
are
actually
using
that
in
their
environments.
D
D
Why
Feder
8
st
oh
eh,
it's
multi
cluster
support,
similar
to
the
progression
of
kubernetes
Sto,
is
now
going
beyond
how
to
I.
How
do
I
run
sto
in
a
single
kubernetes
cluster
to
how
do
I
run
sto
across
multiple
kubernetes
clusters
before
getting
involved
in
Federation
v2
of
about
three
months
ago.
Maybe
four
months
ago,
I
looked
at
the
landscape
and
basically,
what
I
saw
was
the
existing
multi
cluster
sto
solutions
out
there
had
caveats
workarounds.
D
There
was
no
really
consensus
on
what's
the
best
way
to
manage
sto
across
multiple
kubernetes
clusters,
and
that
brought
me
to
Federation
v2
and
the
reason
one
of
the
first
initial
reasons
why
I
was
very
interested
in
Federation
v2.
Is
that
if
we
think
of
sto
SEO
is
nothing
but
a
collection
of
kubernetes
resources
right
and
I
want
to
be
able
to
manage
sto,
which
is
essentially
an
applic
stationed
across
multiple
clusters
and
I
want
to
manage
it.
D
A
simple
user
experience
or
fun
mentioned
that
there's
a
higher
level
API,
that's
being
developed
or
right.
Now
the
community
we're
still
trying
to
figure
out.
What's
the
best
way
of
doing
that.
But
from
my
standpoint,
even
the
the
initial
primitives
of
a
template
of
an
override
or
a
placement
resource.
D
And,
last
but
not
least
as
earth.
I
mentioned
it's
a
strong,
diverse
community,
whereas
when
I
was
looking
at
other
ways
of
approaching
this
multi
cluster
sto
problem,
I
felt
some
of
the
projects
that
I
saw
out
there.
There
was
really
no
strong,
diverse
community
behind
it,
and
just
one
caveat
too
is
when
I
was
doing
my
research.
It
was
really
wrong
at
the
one
dot
o
time
and
I
know
that
one
dot
one
with
an
sto.
D
There
are
changes
that
are
occurring,
that's
making
it
better
to
run
and
manage
sto
across
multiple
clusters,
and
so
you
know
you
know
what
does
federated
SCO
do
right:
we're
able
to
manage
the
sto
control
plane,
so
a
pilot
Citadel
so
on
and
so
forth
across
multiple
clusters,
and
it
doesn't
stop
there
right.
So
now
we're
able
to
actually
Fedder
8u
federated
our
micro
service,
our
micro
services
across
the
clusters
in
a
demo.
D
But
the
unique
thing
is
this
is
essentially
the
applications
running
across
multiple
clusters
and
across
a
couple
of
the
multiple
sto
meshes
and
you
know
think
of
it
as
kind
of
like
cluster
level
of
replication.
So
if
this
was
a
production,
application,
I'm
not
gonna,
have
a
single
instance
of
these
application
services
running
in
a
single
cluster
and
then
last
but
not
least,
is
I
Confederate.
All
the
stos
capabilities
orphan
mentioned
that
we
Confederate
any
kubernetes
resource
type,
including
CR
DS.
So
right
I
mean
if
you're
familiar
with
the
details
of
isseo.
D
You
know
that
there's
includes
a
ton
of
CR
DS
right,
so
things
like
gateways
and
virtual
services
service
entries
all
these
extensions
that
sto
is
implement
to
make
sto
what
it
is
right.
We
Confederate
those
resources,
and
so
I
can
now
have
these
multiple
sto
meshes
across
my
multiple
clusters
and
run
a
federated
application
like
book
info
across
these.
D
D
If
it's
something
you're
interested
in
feel
free
to
chime
in
and
give
it
a
thumbs
up
or
say,
let's
get
this
upstream,
oh
and
I
also
currently
have
it
sitting
in
my
repo.
So
this
federated
SEO
repo
just
has
Doc's
some
deployment
scripts
that
manifests
so
that
you
can
follow
the
Federation,
v2
user,
guide
and
stuff
and
stand
up
a
couple
clusters
and
run
your
Federation
v2
control,
plane
and
then
jump
over
to
this
repo
and
take
the
next
step
of
running
federated
hist
yeah.
D
D
So
I
and
I
run
this
federated
SCO
script
from
the
repo
that
I
just
shared
with
you,
one
of
the
first
things
that
that
we
do
and
let
me
take
a
policy
or
first
I,
can
give
you
the
background
right.
So
in
this
demo,
I've
got
a
couple.
Gke
clusters
in
two
different
zones
could
be
two
different
regions
whatever
it
might
be
right,
but
I
want
you
to
try
to
imagine
this
actually
being
50
or
100
clusters
right
and
I.
D
Have
the
the
Federation
be
two
control
plane
running
in
cluster
one
cluster
one's
also
a
target
cluster.
So
whenever
I
create
these
federated
resources,
cluster
one
is
not
only
hosting
the
the
Federation
be
to
control
plane,
but
it
will
also
propagate
those
target
resources
to
cluster
1
and
then
cluster
2
is
just
a
normal
target
cluster.
But
one
of
the
first
things
I
do
is:
is
I've
federated
ease,
additional
kubernetes
resource
types.
D
So,
when
you
stand
up
your
Federation
v2
control
plane
as
part
of
the
the
deployment,
the
control
plane
creates
some
of
these
federated
type,
configs
right
that
tell
Federation
v2.
These
are
the
the
resources
that
I
want.
You
to
handle
for
Federation
and
there's
certain
native
kubernetes
resources.
Resource
types
at
the
standard
installation
doesn't
include
so
I.
Add
some
of
those
here.
D
Is
you
see
the
federated
config
map
and
the
federated
config
map
placement
right
and
so
that
federated
config
map,
that's
a
federated
representation
of
that
kubernetes
resource
type,
and
then
it's
associated
placement
says:
where
do
you
want
to?
Actually,
you
know
which
target
resources
or
target
clusters.
Do
you
want
to
instantiate
these
these
resources?
D
And
so,
if
we
keep
going
and
again
if
you're
familiar
with
installing
SEO
you'll
know
that
there
is
a
ton
of
resources
that
are
involved
yet
right.
So
it's
a
finish.
Installing
federated
sto
do
have
an
open
issue
where-
and
this
is
actually
an
upstream
kubernetes
issue
and
when
we
actually
try
to
or
when
we
Fedder
eight
mutating
webhook
configurations,
there's
a
bit
of
an
issue.
D
Let's
see,
federating
the
SEO
custom
resource
types
right
so
as
part
of
the
sto
installation
is,
it
creates
a
bunch
of
CR,
DS,
ok
and
after
SEO
is
done
installing
and
create
those
CR
DS.
We
now
federate
them
so
that
we
can
manage
those
federated
resources
like
any
other
native
kubernetes
federated
resource.
D
Let's
see
here:
label
the
Federated
CEO
control
plan
installations
to
play,
deploying
the
sample,
but
a
book
info
application
right.
So
now
you
know
I
mentioned
kind
of
the
three
bullets
of
federated
isseo
with
you
know:
managing
the
the
sto
infrastructure
across
multiple
clusters,
but
we
can
now
use
Federation
to
federated
an
application.
That's
what
we're
using
book
info
floor
so
that
we
can
create
the
book
info
application
across
the
the
clusters.
Have
them
run
on
the
sto
meshes.
D
D
And,
let's
see
here,
let's
see
here,
I
got
a
two
hundred
code
here,
so
I
just
wanted
to
make
sure
that
didn't
have
any
demo
problems.
But
last
but
not
least,
we
create
the
Federated
domain
that
helps
kind
of
stitch.
The
different
clusters,
together
from
a
DNS
standpoint
and
then
I
just
go
and
test
and
say:
okay,
is,
is
this:
you
know
federated
application
available
outside
of
these
multiple
clusters
and
I
did
that
by
just
crawling
it,
and
so
we've
got
the
application
here.
D
B
So
if
I
understand
what
you're
doing
here,
you
are
basically
the
pointing
several
stills
distances
right.
So
several
meshes
and
I
think
the
the
objective
of
is
to
multi
cluster
was
to
have
one
mesh
spanning
across
multiple
clusters.
So
it's
a
different
use
case.
So
can
you
explain
why
Oh
what-what
use
cases
you're
seeing
yeah.
C
I
I
and
I
can
add.
So
what
Daniel
was
trying
to
show
here
is
that
steel
steer
is
a
complex
application.
It's
a
huge
application
and
it
is
quite
easy,
or
it
was
quite
easy
to
read
rate
that
which
has
tons
of
resources,
and
it
can
be
done
so
it's
not
necessarily
offering
a
solution
for
multi
cluster
using
steel
I
mean
that
might
be
a
confusion.
I
thought
you
are
the
the
viewers
might
get.
It
is
just
to
showcase
that
it
is
easy
to
Frederator
complex
application
like
sto,
also
and
just
just
like
Co.
D
Just
to
add
to
that
to
is
I've
done
more
in
depth.
Discussions
on
on
this
effort,
but
a
little
short
on
time
today,
but
even
though,
in
this
implementation
we're
deploying
an
sto
mesh
in
each
cluster,
the
federation
v2
primitives
are
there
where
you
can
go
ahead
and
say:
okay,
I
want
certain
control,
plane,
components
in
cluster,
one
certain
control,
plane,
components
in
the
cluster
two
and
so
on
and
so
forth.
C
E
Lots
of
questions
but
I'll
pass
on
off
my
first
one.
We
talked
a
bit
about
kind
of
cluster
Registry
and
setting
that
up.
My
initial
thought
was:
what's
the
story
around
like
high
availability,
like
if
I
with
my
cluster,
that
has
the
cluster
industry
on
it
and
it
goes
down,
can
I
then
not
deploy
or
what's
the
story
there
so.
C
E
C
A
Just
want
to
add
one
thing,
which
is
the
cluster
registries
is
essentially
two
things:
it's
an
API
definition.
So
if
you're
writing
applications,
you
know
what
the
API
looks
like
and
if
there
is
a
cluster
registry
available
to
you,
you
know
exactly
what
it
looks
like
and
then
there's
a
reference.
Implementation
of
it,
which
currently
I
don't
think,
has
much
complex,
h.a
stuff.
But
it's
reasonably
easy
to
build
and
and
other
people
will
build
custom
registries
with
the
same
API
which,
which
is
AJ.
F
So
my
question
is
around
storage
classes
and
stateful
applications
and
how
it
works
with
federated
v2,
if
I
wanted
to
say,
create
a
key
value
store
that
has
a
part
of
my
data
in
one
cluster
and
part
of
my
data
in
another
cluster
and
make
that
ubiquitous
between
the
two
clusters
will
I
still
be
able
to
access
through
this
format,
the
actual
data
that
I
need.
Yes,.
C
F
C
We
have
so
far
built
is
replication
of
all
key
test
resources,
so
sort
of
propagating
the
same
key
test
resources
with
some
updates
or
changes
in
different
clusters.
What
you're
talking
about
is
possibility
of
having
storage
class
or
having
a
stateful
application
where
the
application
could
span
across
multiple
clusters.
So
the
possibility
is
to
build
that
kind
of
application
using
these
primitives
that
we
have
built
in
filtration
right
now,
and
the
next
step
is
that
actually
to
build
higher-level,
behaviors
or
higher-level
applications
using
these
primitives,
hey.
D
D
Those
are
the
different
versions
of
the
reason
review
service
and
so
I
federated
the
virtual
services
and
the
destination
rules
to
say,
hey
point
everything
to
reviews
v1
so
that
you
don't
get
any
of
the
red
or
black
stars
and
and
again
this
you
know
if
you've
seen
this
demo
before
you're
like
okay.
What's
so
special
about
it?
Well,
it's
the
same,
look
and
feel
same
resources.
We're
using
is
just
Federation
and
so
we're
doing
this
across
multiple
clusters.