►
From YouTube: Kubernetes WG IoT Edge 20221116
Description
November 16, 2022 meeting of the CNCF IoT Edge Working Group. Overview of Shifu. Overview of KCP Edge Multicluster
A
Hi
welcome
to
the
November
16
meeting
of
the
cncf
iot
edge
working
group.
This
is
a
group
that
discusses
supporting
Edge
applications
using
kubernetes
and
other
cncf
projects
on
today's
agenda.
We
have
got
two
items:
we're
going
to
start
with
an
overview
of
Shifu
and
then
after
that,
we'll
have
a
presentation
on
kcp
edge
multi-cluster,
if
there's
time
remaining
our
usual
practices.
That
will
then
open
it
up
to
additional
topics.
A
If
somebody
wants
to
laid
out
an
item
to
the
agenda
notes
document
and
if
there
are
no
items,
we
usually
fill
the
hour
just
with
birds
of
a
feather
open
discussion.
I
just
put
a
link
to
the
agenda
notes
document
in
the
chat
and
with
that
said,
I'm
going
to
turn
this
over
to
sorry.
I
haven't
heard
your
name
pronounced,
but
I'll
give
it
a
try,
Yong
Lee
Chan,
and
he
he's
going
to
tell
us
about
Shifu.
B
All
right
yeah,
thank
you,
so
much
Steve
right,
right,
yeah,
okay,
yeah
and
thanks
a
lot
from
the
for
the
invitation
from
Kate
yeah.
Actually,
let
me
share
my
screen
and
let's
see
my
screen
now.
Yes,
we
see
it:
okay,
nice,
okay,
okay,
so
let's
get
started
and
since
we
have
two
items
on
the
agenda,
so
I
will
get
this
quickly
go
through
this
and
we
can
leave
the
questions
later.
Okay,.
B
Let
me
introduce
myself
first,
so
I
I
was
a
Microsoft
team,
I
used
to
work
at
AKs
at
recubernetes
Service
for
a
few
years,
and
before
that
I
worked
working
on
the
other
container.
Networking
and
I
was
responsible
for
the
address,
C9
and
stuff,
so
I
started
working
on
kubernetes
since
2017
and
I
I
became
a
kubernetes
work
member
since
2019
and
and
UIUC
alumni.
B
B
So
in
the
left
we
have
a
report
from
McKinsey,
so
McKinsey
indicates
there
are
like
nearly
40
percent
of
economic
impact
requires
interoperability
between
iot
systems.
So,
and
you
can
see
the
the
market
value
of
for
it.
The
the
potential
impact
economic
impact
of
iot
is
like
11
trillion
dollars
and
a
40
percent.
Nearly
40
percent
of
it
comes
from
the
interoperability
yeah.
B
So
it's
like
a
four
trillion
dollar
thing
and
on
the
right
we
think
the
organizations
increasing
their
expenditures
in
this
iot
unique
integration
thing
so
and
more
than
half
of
them
are
investing
unmodern
level.
So
over
70
percent
of
participating
organizations
are
making
moderate
to
Major
Investments
to
support
their
integration
needs
yeah.
So
that's
a
background.
B
So
what
about
her
reality?
So
the
reality
is
ubiquitous
silos,
so
we
can
see
from
the
diagram.
So
sorry
it's
a
bad
drawing,
but
you
get
the
idea,
so
you
have
all
kinds
of
devices
running
in
different
protocols
and
connect
to
different
iot
platforms,
and
on
top
of
that
you
can
have
like
a
different
app
apps.
So
that
makes
up
a
silo
and
the
between
those
silos.
B
So
how
can
we
achieve
that?
There's
a
idea
called
a
structural
virtualization.
This
is
a
made-up
works,
so
let
me
explain
so
what
does
this
mean
so
virtualization?
We
are
all
very
familiar.
It's
like
the
the
virtual
machine
and
stuff
you
have
all
the
virtualized,
the
Computing
environment,
but
this
structural
virtualization
is
more
like
treating
the
underlying
device
as
a
a
black
box
and
on
we
only
care
about
the
input
and
output
so
and
there's
an
actually
an
analogy
from
Android.
B
B
So
us
software
developers
can
actually
write
codes
and-
and
actually
we
can
invoke
the
capabilities
from
those
Hardwares
very
easily
right.
We
don't
have
to
deal
with
the
actual
Hardware.
So
that's
the
idea
of
the
the
smartphone
operating
system
and
structural
virtualization.
We
actually,
the
rule
of
thumb,
is
to
virtualize
all
the
Harvest
into
softwares,
okay
and
then
we
have
our
product
with
structural
virtualization
under
the
hood.
So
it's
called
Shuffle,
so
you
can
see
on
the
left.
B
You
have
different
iot
devices
and
on
the
right
you
have
those
green
lines
of
the
virtualized
devices,
so
we
have
a
fancy
name
for
for
them.
Now
it's
called
a
digital
twins
right,
so
what's
Happening
Here
is
like
Shuffle
will
create
a
digital
twin
for
each
connected
device
in
the
system
and
re-expose
their
capabilities
as
apis.
B
So
the
traditional,
complex,
iot
app
development
will
be
simplified
into
like
API
heavy
web
development.
Yes,
and
that's
our
idea,
we
want
to
make
developing
and
like
a
industrial
scenario
as
simple
as
developing
an
app,
so
Shuffle
has
three
main
characteristics:
the
the
first
one
is
overnight.
It's
native
and
the
second
one
is
containerized
device
inter
integration.
B
B
So
here
is
a
comparison
of
the
before
and
after
before
this
submit
aware,
the
developer
has
to
deal
with
all
kind
of
underlying
silos
right,
but
in
with
introduced
thing
you
can
have
a
middleware
that
abstract,
abstract
out
all
the
underlying
mess,
and
you
only
need
to
deal
with
the
shuffle
and
not
not
even
sure
for
you.
You
already
have
the
kubernetes
cluster
right
and
Shuffle
actually
virtualize
all
this
those
devices
as
parts
in
your
kubernetes
cluster,
okay,.
C
C
D
And
automation
systems
PM
of
500
at
500,
we
build
fully
automated
synthetic
biology,
Laboratories
like
when
we
see
the
funding
to
do
this.
We
really
need
to
integrate
a
lot
of
different
iot
devices
into
our
Network.
We
build
devices
and
files
as
well
as
use
third-party
devices
and
Shifu
helps
us
integrate
all
these
devices
in
a
smart
efficient
way.
So
we
can
print
all
the
different
devices
as
software
objects
and
really
abstract
and
physical
layers,
so
that
we
don't
need
to
worry
about
the
underlying
connection
and
control
of
those
devices.
D
We
can
focus
on
building
software
on
top
of
the
existing
infrastructure.
This
also
helps
us
integrate
devices
in
a
smart
manner.
We
don't
have
to
keep
Reinventing
the
world
and
rebuilding
our
infrastructure
and
reaching
device
should
boost
generalized
interface
and
easy
expansion
in
that
framework
allows
us
to
quickly
integrate
a
huge
variety
of
devices
that
we
work
with.
So
some
of
the
devices
that
we
integrated
to
our
family
Network
include.
D
Robotic
arms
like
this
Thomas
grounded
bowls
and
different
into
both
in-house
and
third-party
lab
work,
but
like
centrifuge
or
dispensers,
all
these
devices
can
be
cleanly
integrated
using
the
shoulder
framework.
We
are
able
to
use
the
same
underlying
infrastructure
across
all
these
devices,
with
only
minor
configuration
changes.
This
helps
us
be
very
efficient
in
integrating
with
devices
prior
to
show
that
we
have
to
rebuild
our
infrastructure
for
each
of
these,
and
it
was
very
labor
intensive
and
hand
consuming
process.
There's
also
a
lot
of
different
errors.
D
We
encounter
each
time
we
integrated
the
new
device.
Everything
is
taken
care
of
behind
the
scenes.
We
don't
need
to
worry
about
rebuilding
all
this
for
each
device.
We
can
just
reuse
this
very
general
and
easy
to
build
upon
framework.
It
really
accelerated
our
integration
process
for
the
numerous
devices
we.
B
Have
here
at
the
top
all
right,
yeah,
so
yeah,
let
me
give
you
guys
a
little
background,
so
what's
actually
happening
in
their
Foundry,
so,
as
you
can
see,
they
have
like
numerous
devices
right
and
they
already
have
the
kubernetes
cluster
and
they
all
they
only
want
to
one
a
single
instance
of
infrastructure.
So
they
don't
want
to
manage
all
the
inference
right.
B
B
B
Yeah
so
actually
means
teacher
or
master
in
Chinese.
So
what
I
should
do?
He
teaches
the
students?
What
to
do?
It's
like
a
here's,
a
analogy.
So
we
have
the
shuffle
right
and
we
have
the
company.
The
shuffle
gives
instructions
to
the
student
and
the
students
give
the
Shifu
feedback
and,
in
our
scenario
the
structured
digital
twin
or
like
a
kubernetes
spot,
send
the
request
to
the
actual
device
and
the
device
sends
the
response
to
the
kubernetes
pod.
B
B
B
Okay,
we
can
see
the
crb
system.
The
control
manager
is
running
okay,
so
we
can
proceed
to
the
next
step
in
this
camera
come
big
directory.
There
are
like
total
of
four
the
simple
related
files
for
the
camera.
So
it's
it's
kind
of
tedious
right
now,
but
we
are
trying
to
reduce
it
to
one.
So
the
let
me
show
you
the
one
by
one.
B
B
C
B
C
B
B
B
C
B
C
A
A
A
Hawkmit
takes
on
software
updates,
ditto
is
device,
twins,
Hano,
would
be
device
connectivity
and
then
Kanto
is
a
stack
that
I
believe
integrates
a
bunch
of
those
into
a
wrapper
for
hosting
containerized
apps
adage
does:
does
this
overlap
those
or
work
with
them,
or
what
does
it
if
it
does?
Some
of
the
same
things
I'm
curious
as
to
what
different
approach
it
takes,
or
why
this
somebody
might
want
to
look
at
this
versus
the
other
ones
out
there.
B
A
Okay,
is
it
is
it
Docker
containers
specifically
then,
and
if
so,
is
this
tied
to
kubernetes
or
is
it
agnostic
so
in
other
words,
suppose
I'm
using
Docker
containers,
but
not
the
kubernetes
orchestrator?
Does
that
work
or
not
work
with
this,
and
if
it
does
require
kubernetes,
does
it
have
to
be
running
at
the
edge
or
can
it
be
running
at
a
higher
level,
control
plane
say
in
a
cloud
that
isn't
at
the
edge.
B
Yeah,
actually
that
that's
a
great
question
so
Shuffle
right
now
is
kubernetes
crd,
so
you
have
to
rely
on
kubernetes,
but
it
doesn't
have
to
be
on
the
on
the
edge.
So
on
that
you
usually
have
like
k3s
or
something
like
open
yard.
But
in
the
cloud
you
maybe
you
have
full
full-fledged
kubernetes.
Both
of
both
of
them.
Work
for
sure
should
only
requires
running
kubernetes
distribution.
A
A
Okay,
what
about
safely
keeping
secrets?
You
know,
I
suspect
some
of
these
devices
might
have
credentials
and
things
that
you
are
have
some
concerns
about
them
being
unencrypted
at
Edge
locations
without
physical
security.
How
does
this
to
the
extent
device
credentials
are
required,
like
you
know,
accounts
or
passwords
to
get
connectivity
to
a
device
or
encrypting
a
data
stream?
How
does
Shifu
try
to
manage
that
in
any
way.
B
B
E
B
E
Know
if
we'll
have
time
for
kind
of
digging
in
much
deeper,
because
we
do
have
another
presentation
today,
but
I'm
personally,
very
interested
in
that
I've
worked
on
the
awkward
project
and
the
main
maintainer
for
that
and
I
do
see
this
integrating.
Well,
what
awkward
does
is
it
discovers
the
iot
devices
on
your
behalf
and.
D
E
B
E
B
A
B
B
So
so,
basically
we
use
Discord
for
our
community
and
it's
just
established,
we
are,
you
guys,
are
welcome
to
join
and
we're
going
to
gonna
share
the
deck
or
Discord,
and
also
the
all
the
files
used
in
this
demo
Yeah.
So,
basically,
that's
all
my
presentations
and
thank
you
guys
for
listening.
Okay,.
A
Thanks
one
final
thing:
maybe
you
can
just
answer
this
offline
in
the
agenda:
notes
doc,
but
I'm
curious
about
the
background
of
the
organization
behind
this
The
Edge
nieces.
So
maybe,
if
you
can
fill
something
in
about
that
for
people
like
me
who
are
curious,
of
course,
yeah
sure
yeah,
oh
okay,
let's
move
on
then
to
cover
our
second
topic
on
the
agenda:
The
kcp
Edge.
If
somebody
wants
to
take
over
and
start
that
presentation
go
for
it.
Annie.
B
Question
yeah
yeah
sure
so,
actually
that's
interest,
that's
an
interesting
story.
So
back
when
I
was
at
Microsoft
Burnett
Burns
was
my
boss
and
I
I
talked
to
him
a
lot
and
I
and
and
back
then
the
Microsoft
strategy
went
from
mobile
first,
the
cloud
first
to
intelligent
cloud
and
the
intelligent
Edge
and
you
can
see
the
the
mobile
is
dropped
and
you
have
intelligent
ads
coming
up.
B
F
God,
it's
just
a
different
layout
apologize
for
that
I.
Usually
I
usually
tease
the
people
that
work
for
me
that
when
they
don't
know
how
to
do,
WebEx
sharing
and
I
just
got
a
taste
of
my
own
medicine.
There
apologize
hi
everybody
thanks
for
having
me
I
have
a
few
other
folks
on
the
phone
that
are
are
with
me.
Apollo
and
Gosha
Steiner
are
joining
me
on
behalf
of
the
kcp
edge
project.
F
F
State-Based
management
and
really
just
slim
down
the
API
server
to
be
very
very
small,
can
be
run
in
a
binary
as
a
matter
of
fact,
and
so
it
it
strips
away
a
lot
of
the
the
weight
that
comes
with
a
full-blown
kubernetes
cluster
and
allows
you
to
run
very
small
API
servers
wherever
you'd
like,
and
so
what
we're
we've
saw
this
as
a
possible
way
to
incorporate
some
of
the
edge
use
cases
that
we've
been
examining.
We
work
our
day.
F
Jobs
are
with
IBM
research,
and
so
we've
been
partnering
with
red
hat
internally,
because
red
hat
is
an
IBM
company
to
build
upon
what
they've
discovered
in
kcp
and
the
traction
and
adoption
they've
been
seeing
in
their
project,
and
so
our
specific
use
cases
have
to
do
with.
You
know
disconnected
operations,
as
you
pointed
out,
with
Shifu
scalability
large
numbers
of
objects
on
the
order
of
a
million
or
more,
which
would
be
represented
by
Edge
clusters,
and
then
also
you
know,
constraints
in
those
clusters
right.
F
They
could
be
running
on
as
small
as
let's
say,
a
Raspberry
Pi
or
you
know
some
other,
a
Jets
and
Nano
or
something
to
that
effect,
and
so
what
we
believe
is
there's
a
trend
taking
place
in
the
industry,
whereby
you
know
lots
and
lots
of
these
objects,
and
these
clusters
are
exist
today,
but
there's
a
real
challenge
when
it
comes
to
managing
them.
And
so
that's
where
we're
starting
to
focus
in
on
any
questions.
So
far,.
F
All
right,
so
this
is
our
project.
It's
part
of
kcp
Dev.
You
can
find
us
simply
by
going
to
kcp
dash,
Dev
and
GitHub,
and
then
look
us
up
as
the
edge
MC
or
the
edge
multi-cluster
project
and
you'll
see
very
quickly
up
front.
Some
of
our
objectives
have
to
do
around
supplying
a
way
to
organize
hierarchy,
have
some
runtime
into
interdependence
or
Independence,
you
know
being
able
to
run
operations
independently
of
having
connectivity
to
the
root,
node
and,
of
course,
large
numbers
of
destinations
for
where
you
can
deploy
workloads.
F
All
of
these
concerns
and
these
goals
that
we
have
you
know,
there's
a
number
of
different
ways
that
we
can
stretch
and
pull
the
kcp
orchestration
engine
that's
been
built,
and
so
what
we're
doing
in
that
area
is
where
you
see
under
areas
of
exploration,
is
changing
the
way
placement
is
defined,
and
so
today,
in
kcp
and
in
kubernetes,
you
can
address
clusters,
but
you
can't
do
that
in
such
a
way
that
you
could
say
this
set
of
clusters
gets
this
set
of
workload
and
do
that
at
scale.
Okay,.
A
F
No
I,
don't
think
so
at
the
actual
Edge
location,
so
the
edge
location
to
us
could
be
a
single
node.
Openshift
could
be
an
open
shift,
could
be
a
kubernetes
cluster,
it
could
be
a
kind.
Cluster
could
be
microshift,
anything
that
can
speak
Cube,
you
know
and
can
be
Cube
style
managed
that's
what
we
anticipate
to
have
at
that
edge,
so
it
doesn't
have
to
be
kcp
per
se.
It
could
be
anything.
A
F
All
right
so
in
the
areas
of
exploration,
we're
talking
about
things
like
how
to
custom
customize
those
workloads
such
that
you
know,
as
you
know,
to
have
to
manage
a
million
Edge
clusters
at
scale,
multi-cluster,
multi-vendor
Etc.
There
would
be
different
parameters,
different
Secrets,
different
configurations
that
need
to
be
rolled
out
to
those
different
destinations.
F
So
how
do
we
get
the
ability
to
fine-tune
and
control
that,
but
yet
not
overwhelm
the
developer
and
the
operator
at
the
same
time
to
have
to
be
able
to
manage
each
one
of
those
one
million
or
more
individually
right?
So
that's
a
real
kind
of
give
and
take
it's
a
push
and
pull
there.
The
exercise
that
we
have
we're
talking
about
scheduling,
also
rollout
control,
and,
of
course,
you
know.
Two
of
the
big
elephants
in
the
room
here
have
to
do
with
something
that
kubernetes
today
isn't
so
good
at
is
status
summarization.
F
So
if
you
try
to
retreat
brief
status
from
a
million
different
objects
and
then
interpret
and
use
that
information,
you'd
yeah
you'd
run
out
of
time
in
the
day
the
year
the
month,
whatever
you
know,
insert
your
time
frame
here
so
status.
Summarization
is
something
that
we
feel
is
going
to
be
a
significant
challenges
for
us
as
well
as
etcd.
So
it's
really
no
secret.
F
If
you've
been
working
with
kubernetes
long
enough
is
that
NCD
really
is
kind
of
an
Achilles
heel
to
kubernetes
and
doesn't
allow
you
to
scale
either
the
size
of
individual
objects
or
the
number
of
objects
stored,
and
so
we're
experimenting
with
different
ways
that
we
can
in
kcp,
proper
and
eventually
into
kubernetes
Upstream,
that
we
could
use
a
different
database
technology
there,
one
of
which
we're
working
with
right
now
in
kcp's
community
is
cockroach
because
it
has
the
has
support
for
time
series.
So
all
of
those
we're
working.
F
It's
a
combination
of
kcp
work
that
we're
doing
in
the
open
source
course
and
kcp
Edge.
We
have
a
project
board
where
we're
doing
a
whole
bunch
of
work.
Now,
we've
gotten
just
started
in
November.
The
first
November
1st
and
we've
got
a
number
of
Investigations
underway
and
we're
looking
for
more
members
to
join
the
community.
So
I
thought
we
were
kind
of
birds
of
a
feather
here.
You
know
fellow
fellow
constituents
looking
out
for
Edge
Music
use
cases
and
how
to
manage
them
at
scale.
F
F
F
G
F
H
Yeah
I
realized
that
maybe
it
would
be
been
helpful
in
this
context
to
give
a
little
more
intro
on
the
kcp
and
the
current
a
sub
project,
also
that
is
dealing
with
the
multi-clustering
kcp.
That
is
called
the
transparent
multi-cluster,
because
kcp
is
already
providing
some
support
for
Distributing
workload
to
multiple
clusters,
that
is
called
transparent,
multi-cluster
and
so
we're
sort
of
starting
from
there.
H
But
we
realized
that
there
are
gaps
and
there
are
things
that
don't
really
worked
well
in
the
context
of
hedge
and
that's
why
we
we
thought
we
need
mascal,
another
soup
project
within
the
kcp
organization,
to
deal
with
the
specific
Edge
problems
that
Andy
was
was
mentioning,
and
so
in
a
way
we
are
starting
from
an
approach
that
is
more
kcp
Centric.
This
idea,
compared
to
some
Alpine
cluster
management,
is
more
really
following
the
the
current
model
in
kcp,
where
essentially,
you
can,
for
example,
for
transparent
multi-cluster.
H
H
It's
really
a
way
to
sort
of
give
you
this
kind
of
virtual
model,
where
you
can
directly
interact
with
qcado
the
same
way
interact
with
a
regular
kubernetes
cluster
in
this
kind
of
visualized
model.
That
is
the
workspace,
so
we're
pretty
much
following
that
approach
and
and
also
to
say
that
there
is
some
work
also
going
on
with
with
the
open
cluster
management.
Some
of
the
faults
they
are
also
working
on
kcp.
Actually,
some
of
them
work
actually
on
the
kcp,
transparent,
multi-cluster
feature.
H
So
I
think
there
is
collaboration
between
these
two
projects
and
I
guess.
The
goal
is
also
to
evolve
some
of
those
both
of
them
in
a
way
and
potentially
it
could
be
there
at
some
point.
Even
open
cluster
management
me
maybe
use
some
of
these
capabilities
from
kcp,
but
that
is
probably
longer
tail
kind
of
goal.
A
F
Yes,
there
is
a
limited
there's,
a
limited
set
of
API
at
the
kcp
API
Machinery
level,
so
you
have
things
that
have
to
do
with.
You
have
apis
that
are
specific
to
a
workload,
distribution
and
not
much
else
right.
So
the
addition
of
others
is.
You
can
have
that
at
any
other
layer
in
that
in
the
hierarchy
that
you
build,
but
not
specific
to
anything
else,
but
workload,
there's
a
few
others
as
well.
I
think
there's
three
or
four
in
total.
I
I
I
Yeah,
so
if
can
a
cluster
system
cluster,
which
is
external
and
this
being
the
target
cluster
with
those
additional
apis,
will
they
still
be
able
to
use
this
specifically
I
mean
the
source
and
the
target?
Let's
say
master
is
source
and
Target
is
what
you
have
with
the
agent
which
you
have
with
the
Lesser
API
right.
I
F
F
You
when
you
go
to
deliver
a
workload
when
you
say
Let's,
send
a
work,
a
deployment
down
to
an
an
edge
cluster
once
you
send
that
edge
cluster
down,
there's
our
they
use.
What
are
called
synchers
and
sync
targets.
So
sync
Target
identifies
with
the
location,
the
location
of
where
that
Sinker
or
where
that
sync
is
pointing
at
that's
that
edge
location
that
edge
cluster
the
physical
cluster.
If
you
will
or
the
the
physical
Edge
code,
they
call
them
p-clusters.
F
So
the
sync
Target
is
associated
with
that
and
then
the
Sinker
itself
takes
the
package
that
it's
sent
to
it
and
says:
okay
at
deployment,
I've
got
a
config
map.
A
secret
I
have
to
deploy
it
here
and
then
has
the
full
support
of
the
Kube
API.
That's
running
at
that
edge
cluster
to
go
ahead
and
deploy
it.
So
we
have
also
bumped
into
situations
where
we
want
to
send
something
down.
F
There's
also
the
option
too,
to
wrap
these
things
in
sort
of
a
manifest
right.
So
you're
familiar
with
Helm,
so
taking
things
like
a
Helm
chart
or
overloading
config
map
and
then
sending
that
down
and
letting
that
on.
So
those
are
things.
Those
are
other
approaches
that
were
we're
experimenting
with
now
and
we
actually
have
a
discussion.
That's
queued
up
as
part
of
the
next
Community
call,
which
will
have
this
coming
Thursday,
where
we
are
introducing
how
we,
how
would
we
do
the
scheduling
and
what
AI
types
would
we
support
so.
H
H
There
is
also
another
feature
of
the
Escape
of
the
current
Sinker
in
kcp
that
we
are
in
a
way
we're
also
using
that
is
a
disability
of
import
apis
from
Target
clusters.
So,
basically,
even
if
the
API
is
not
on
the
kcp
API
server,
basically
in
kcp
there
is
this
notion
of
workspace.
That
is
like
a
virtualization
of
the
API
server.
H
So
by
default
it
may
not
have
all
the
apis
that
you
have
on
the
target,
but
you
can
actually
import
to
this
API
definitions
like
crds
Etc
from
the
target
clusters,
and
they
will
be
available
now
on
the
kcp
workspace
site,
and
then
you
can
start
creating
instance
of
those
apis
and
they
will
be
propagated
back
to
the
Target
cluster.
So
this
is
a
feature
that
is
already
part
of
kcp.
I
H
Workspace
is
actually
a
New
Concept
that
kcp
has
introduced.
It's
really
virtualizing
the
API
server
in
workspace.
From
the
point
of
view,
a
user,
a
workspace
looks
like
a
kubernetes
API
server,
so
you
could
cuddle
into
a
workspace
and
you
can
create
the
namespaces
within
that
you
can
apply
rbac.
You
can
do
a
cast
scope
stuff
and
this
complete
result
later
from
other
workspaces
for
other
users.
So
that's
pretty
much.
The
way
it
operates.
So
within
the
Iraq
is
pretty
much
within
a
workspace.
H
You
have
namespaces,
it
looks
exactly
like
a
kubernetes
cluster
and
the
structure
of
namespaces
when
you
sync
to
a
Target
cluster
is
replicated
in
a
way
to
those
Target
clusters.
Even
if
there
is
some
name
mangling
to
to
avoid
collisions,
see
a
lot
of
stuff
like
that,
but
pretty
much
any
space
resources
that
you
have
from
the
workspace
will
be
replicated
to
the
Target
cluster
within
new
namespaces
that
are
created
by
the
the
sync
the
Sinker
agent
on
those
clusters.
I
H
F
G
F
And
crdb
interchangeability,
but
we
are
relying
on
the
fact
that
you
know
to
work
at
to
operate
at
scale
that
specific
Dimension
is
going
to
have
to
be
solved
right.
So
we
work
we're
working
closely
with
kcp
to
figure
that
part
out
as
well
as
sharding
and
API
priority
and
fairness,
and
those
are
all
you
know,
separate,
separate
requirements
that
we
have
that
will
eventually
we
will
rely
upon
to
have
full
scale.
F
So
folks,
that
that
wraps
it
up
for
us
unless
you
have
other
questions
happy
to
stick
around
and
field
them
scan
the
QR
code,
it'll
take
you
over
to
our
repo
or
you
can
just
go
to
we'll.
Have
we'll
soon
have
an
investigation
listed
under
keysp.io
or
just
look
us
up
at
Edge
MC
on
GitHub
and,
like
I,
said
our
first,
our
first,
our
second
inaugural
meeting
will
be
this
Thursday
10
a.m.
A
B
F
This
is
usually
it's
a
it's.
We're
used
we're
relying
on
Pulp,
so,
as
you
know,
we
don't
we're
not
doing
push
from
the
top
down,
so
it's
it's
all
pull
and
then
at
some
point
you
know
having
the
ability
to
Interchange
API
Machinery
closer
to
the
edge
may
allow
us
to
actually
have
you
know
separate
Communications
happening
at
the
lower
portion
of
the
hierarchy
such
that
they
don't
have
to
have
direct
access
to
the
root
at
all
times,
and
so
that
was
where
we're
looking
at
supporting
disconnected
operations.
B
F
A
A
So
far,
well,
I
haven't
even
opened
up
the
spot
in
the
agenda
note
stock
to
have
to
allow
you
to
enter
it,
but
I
will
so
if
anybody
wants
to
present
at
a
future
one
or
even,
if
you're
curious
about
a
topic,
and
you
want
to
challenge
the
chairs
of
this
group
to
go,
find
a
speaker
go
ahead
and
put
something
you're
curious
about
on
the
agenda
at
a
future
meeting
and
we'll
do
our
best
to
try
to
line
that
up.
So
thanks.
Everybody
see
you
next
time.