►
From YouTube: Kubernetes SIG Multicluster 20181106
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
B
Okay,
so
your
fun
put
together
the
agenda.
I
think
he
just
wanted
us
to
mainly
go
over
the
Sig
multi
cluster
intro,
slides
that
he
and
Quinton
are
presenting
at
cube
con
China.
Next
week
I
I
think
I
mean
nobody
on
our
side
is
going.
Our
second
Google
side
is
going
to
represent
signal
booster
at
cube,
con
China,
so
I.
A
B
B
The
I
think
that's
about
it
with
relative
to
those
six
slides.
The
other
is
an
entry
that
Quentin
put
in
after
I
spoke
to
him
concerning
what
updates
be
had
for
multi
cluster
ingress.
Part
of
that
has
been
on
our
site
owned
by
his
participants,
would
be
in
the
networking
group
rather
than
multi
cluster
group.
B
We
I
had
a
discussion
with
them
yesterday
and
we
do
have
to
see.
Are
these
that
were
ready
to
polish
and
put
out
there
in
as
part
of
kubernetes
six,
so
I'll
be
putting
that
into
a
shape
to
distribute
so
that
we
can
discuss
them
in
the
same
not
ready
this
week
sometime
either
in
two
weeks
or
two
weeks
after
that,
although,
although
two
weeks
after
that
we'll
run
into
the
holidays,
I'll
try
to
get
at
least
one
of
them
out
by
next
week.
I'm
assuming
I
can
get
the
sufficient
amount
of
coordination.
B
A
A
A
There
there
had
been
at
least
as
I
understood
it,
an
interest
on
the
Google
side
in
developing
api's
for
multi
cluster
ingress,
but
that
sounds
like
it
is
out
of
date,
since
you
you've
just
said
that
these
won't
be
in
connection
with
the
with
the
current
cube
MCI
repo
I
I.
Guess
that
begs
the
question:
do
you
anticipate?
A
B
Yeah
I
mean
that's
that
could
be
up
for
discussion,
whether
it's
a
new
feature
for
Federation
I,
think
just
maybe
going
over.
The
api's
should
inform
some
of
that
decision,
maybe
for
now
for
some
I'll
just
put
it
as
a
types
that
go
within
cube.
The
existing
cube
mci
tool,
at
least
it'll-
be
something
to
look
at
a
pull
request
to
look
at
and
we
can
collect
comments
there.
A
B
That
there's
not
much
change
there
and
service
is
kind
of
the
best
way
to
try
to
is
it's
kind
of
a
meta
service
over
the
existing
service
type
with
a
few
extensions
I
think
it
could
fit
I
mean
as
much
as
I
know
about
the
Federation
to
model
I
figured.
You
could
fit
well
within
the
Federation
to
model,
but
I
think
we'll
have
to
witness
win,
see
yeah.
A
Yeah
so
going
to
the
ingress
one
is
it
it
sounds
to
me
like.
It
is
a
very
close
match
to
the
kubernetes
ingress
api
with
with
multi
cluster,
as
as
some
additional
aspect
to
it
right
in.
Is
it
something
like
you
want
to
control
the
the
ingress
objects
in
each
cluster,
or
does
it
have
more
of
a
does?
It
also
have
an
additional
connotation
of
there's
something
outside
potentially
any
of
those
clusters
like
like
the
existing
cube,
mci
functionality.
B
Know
the
ideas
there's
a
strong
link
between
the
multi
cluster
ingress
and
it
targets
only
multi
clusters.
Services
multi
cluster
services
essentially
are
created
from
endpoints
that
can
be
on
different
clusters
and
the
relationship
between
the
multi
cluster,
ingress
and
multi
cluster
service
is
kept
in
I
guess
some
meta
endpoint,
which
would
be
the
either
the
federated
control
plane,
but
it
could
also
be
installed
as
a
CR
D
as
to
CR
DS
in
one
of
your
clusters
that
you
designate
as
they
call
it
for
lack
of
a
better
word.
B
A
C
C
B
D
C
D
A
big
baked
into
it,
maybe
by
a
replication
controller
or
like
this
I
mean,
is
there
a
watch
mechanism
so
that
the
automatically
restarts
on
another
cluster
are
like?
Do
we
need
a
separate
I
would
say
the
Geo
cluster
geo
I
mean
some
other
load
back
nearest
controller?
That
is
outside
the
scope
of
this
question.
Yeah.
D
D
Who
speaking
this
is
someone
here,
I'm
I
work
for
DM
on
D,
okay,
so
so
far
we
have
been
working
with
multi
cluster
single
cluster
are
like
we
extended
the
same
single
cluster
to
about
50
miles
using
multi
zones,
but
I
think
that
is
only
temporary.
But
next
we
are
working
towards
multi
cluster.
That's
where
we
just
started
getting,
and
we
are
just
started
looking
into
this
one.
So
then
I
saw
kubernetes
multi
cluster,
so
we
also
join.
B
C
B
You
have
the
same
service,
that's
replicated
in
multiple
clusters
and
you
have
a
controller
that
configures
the
necessary
backends
I
mean
if
our
case,
if
we're
going
to
run
it,
it's
going
to
be
the
Google
cloud
load,
balancer,
but
I
think
what
may
may
change
or
where
the
options
are
are
about
the
hosting
model.
Where
the?
Where
does
that
controller
live?
So
if
you're
running
Federation,
then
I
I
would
say,
the
controller
should
probably
live
within
the
Federation
control
plane.
C
B
If
you're
not
running
Federation,
that's
why
we
bandied
around
the
term
just
golden
cluster
in
the
sense
where
you
could
just
designate
one
of
your
clusters
to
host
that
controller,
that
programs,
the
necessary
backends
across
all
the
participant
clusters.
So
I
mean
there
is
a
dependency
on
cluster
registry,
but
you
could
choose
to
host
the
cluster
registry
on
what,
if
you're
one
of
your
clusters.