►
From YouTube: KubeEdge – Kubernetes Native Edge Computing Framework - Jason Wu & Sean Wang, Futurewei
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
KubeEdge – Kubernetes Native Edge Computing Framework - Jason Wu & Sean Wang, Futurewei
KubeEdge is an open source edge computing framework that extends the power of kubernetes from central cloud to edge. In this session attendees will learn about: - Why KubeEdge is useful for Edge Computing; - Architecture and major design considerations of KubeEdge; - Latest updates and challenges we faced getting there; - Where KubeEdge is headed. There will be an extended open Q&A at the end for attendees to ask questions. KubeEdge was accepted as the first edge computing project hosted under the Cloud Native Computing Foundation (CNCF) in March 2019.
https://sched.co/Uahz
A
All
right,
good
morning,
everyone,
let's
get
started,
welcome
to
the
cooperage
session.
This
is
the
session
about
the
kubernetes
native
computation
framework
for
running
on
the
edge.
My
name
is
Jason
Wu
I
have
my
colleague
Sean
one
with
me.
We
have
been
working
on
the
project
that,
since
the
very
beginning,
so
in
today's
discussion,
we're
in
the
first
I'm
going
to
talk
a
little
bit
about
the
cooperage,
the
project
itself.
A
What
are
the
thinking's
and
the
history
behind
it?
How
we
get
started?
What
is
a
design
for,
and
then
my
colleague
Sean
he's
going
to
talk
about
the
overall
architecture,
as
well
as
some
of
the
major
design
decisions
behind
the
project
at
the
end,
we're
going
to
leave
some
time
for
Q&A
and
also
want
to
invite
all
of
you
guys
if
you
are
interesting
the
project
and
want
to
participate
or
want
to
learn
more
about
the
project.
You're
welcome
to
join
us
or
check
us
out
check
us
out.
A
So
with
that
said,
let's
get
started
so
this
the
project
really
started
a
couple
of
years
ago,
Sean
and
I
were
talking
about
with
all
these
emergence
of
smart
devices
and
IOT
devices
coming
up,
there's
a
huge
problem
which
is
not
yet
really
resolved
before
you
know
how
to
manage
this.
For
all
these
new
smart
devices
and
IOT
devices,
you
know
what
kind
of
a
computation
framework
we
can
build
to
enable
developers
to
easily
manage
these
devices
and
as
well
as
the
developing
applications
on
top
of
it.
A
We
all
know
that,
with
a
lot
of
these
devices,
they
generate
a
huge
amount
of
data
right
a
lot
of
times
in
the
addition
to
the
old,
like
the
telemetry
data
and
all
that
now
we
have
a
lot
of
this
image
data
and
the
video
data
and
all
that,
so
it's
simply
not
possible
to
move
all
this
data
from
the
original
to
the
cloud
and
then
do
the
analysis
and
the
center
decision.
Time
is
just
not
possible
to
do
it
that
way
and
oftentimes.
A
I
OT
devices
they're
running
like
an
operation
controls
they're
running
in
the
factory
they're
running
in
stuff,
like
in
the
out
there
in
the
field.
They
need
a
real-time
decision
making.
So
the
latency
is
also
a
consideration
factor
to
say
how
can
we
get
you
to
take
the
data
and
then
response
very
fast,
and
on
top
of
that,
a
lot
of
the
customers
we
talk
to.
They
also
have
this
security
and
privacy
concerns.
A
They
say:
yeah,
I'm,
okay,
to
run
data
analytics
on
top
of
them
like
data
within
a
controlled
environment
in
my
environment,
but
I'm
not
feeling
comfortable
or
I'm
not
allowed
to
let
any
of
these
data
out.
So
that
was
another
thing,
and
the
very
last
thing
is
about
you
know
with
all
this
a
denote
out
there.
The
network
connectivity
is
not
always
guaranteed
and
reliable.
So
when,
since
I've
got
to
disconnect
it,
you
wanted
the
local
node
to
be
able
to
run
autonomously
to
able
to
continue
to
function.
A
So
that's
a
lot
of
these
challenges
we
have
seen
and
from
our
point
of
view,
we
you
know
wizard-like.
We
shine
and
I
worked
in
the
cloud
space
for
quite
a
while.
We
look
at
they
say.
Look.
The
easiest
way
for
us
to
do
is
actually
to
build
a
similar
experience
so
that
we
can
hide
a
lot
of
the
complexity.
I
just
talked
about,
so
that's
the
developers
and
the
customers.
They
don't
have
to
view
or
worry
about.
A
Oh
there's,
a
ton
of
will
network
connectivity
issues
or
there's
a
ton
of
devices
out
there,
so
the
review
to
the
edge
as
an
extension
of
the
cloud.
The
idea
is
that
you
know
from
the
cloud
the
point
of
view
one
customer
coming
in.
They
have
this
essential
control
panel
control
client.
They
can
look
at
and
say
whether
the
node
is
you
know,
happens
to
run
on
one
of
the
customer
societal
happen
to
run
in
the
computer
node
in
the
hyper
scale
cloud.
The
data
center,
that's
kind
of
from
a
customer
point
of
view.
A
They
don't
they
can
look
at
all
this
node
at
the
same
time-
and
you
know
the
system
were
managing
all
those
differences
of
order.
So
that's
the
idea.
We
also
want
to
build
this.
A
bidirectional
communications
between
the
cloud
under
the
edge
right-
it's
we
don't
want
a
like.
Only
the
AG
is
a
kind
of
a
down
terminal
which
only
get
a
controlled
by
the
cloud
we
all
want.
The
cloud
are
denoted
to
be
to
have
the
ability
to
sense
the
in
some
of
the
informations
back
and
then
this
is
can
be
coordinated.
A
We
wanted
to
add
you
know
to
have
the
ability
to
pour
additional
like
applications
from
the
cloud
as
needed.
If
there's
a
new
application,
get
it
developed
and
build
on
the
cloud
that
we
want
to
be
able
to
push
that
out
to
the
edge
node
and
then
customers
who
can
write
and
they
can
use
it.
So
it's
a
bidirectional
communication
over
quite
complex
to
commit
and
network
conditions.
A
You
know
the
network
often
tire
have
to
traverse
rule
some
of
the
private
network
with
the
fire
wars
with
you
know,
occasional,
disconnected
network
connectivity
and
all
that,
and
that
will
also
build
the
framework
to
in
to
to
have
the
ability
to
manage
massive
amount
of
all.
You
know
add
node
out
there.
So
that's
kind
of
the
the
second
aspect.
The
first
thing
I
want
to
talk
about
is
this
is
a
really
hydro
genius
environment
in
term
of
the
Act
I
mean
not
only
that's
a
when
we
talk
about
IOT
devices
or
a
denote.
A
It
varies
quite
a
bit
and
the
different
people
are
referring
to
this
thing,
as
you
know,
could
be
very
different
things
from
very,
very
lightweight
and
low
powered
IOT
devices,
which
only
sends
like
a
bytes
of
information
at
a
time
which
you
can
run
by
the
way
four
years
from
that
type
of
device.
All
the
way
up
to
you
know
very
powerful,
full-fledged
in
the
node
to
even
to
a
small
cluster.
A
We
can
all
refer
them
as
the
add
node,
so
our
goal
was
really
to
targeting
the
edge
node
with
a
certain
processing
and
computational
capabilities.
You
know
this
is
a
right.
Now
we
support
one
IV
CPU,
like
the
computation
capabilities,
one
with
one
v,
CPU
with
128
megabytes
of
a
memory.
So
that's
kind
of
the
the
computational
resources
required.
The
two
runs
The
Container
applications.
So
we
set
that
to
limit
to
two
there
and
in
the
future
we
can
look
at
how
to
expand
it
further.
A
So
right
now
our
framework
can
run
from
you
know
this
one
V
CPU
with
120
megabytes
of
memory,
all
the
way
up
to
a
very
powerful
server
for
flight
asobu
is
the
terabytes
of
memory
with
you
know,
multiple
GPUs
and
you
know
32
CPUs,
and
all
that,
so
we
can
run
all
the
way
up
to
cover
pretty
wide
range
of
devices
and
edges
scenarios
out
there.
The
last
thing
I
want
to
talk
about
this.
Really
we
want
to
build
the
synergy
between
the
edge
and
the
cloud.
A
A
We
can
leverage
the
massive
amount
of
computational
resources
and
and
train
the
model,
and
then
we
push
the
model
to
the
edge
node
and
having
the
edge
node
more,
focusing
on
the
inference
aspect
of
the
workload
and
with
the
antinodes
collecting
more
and
more
data,
then
the
model
work
gets
involved
with
the
additional
data
and
in
the
vault
model
will
also
get
refreshed.
You
know
from
time
to
time,
so
that's
kind
of
a
typical
scenario.
A
That's
also
demonstrates
the
synergy
between
the
original,
as
was
the
cloud
capabilities
we
have
so
I
talked
about
some
of
the
main
scenarios
and
here
and
talk
about
some
of
the
major
advantages
of
our
approach,
as
well
as
some
of
the
work
we
have
done
to
address.
Some
of
the
I
talked
earlier.
So
the
first
approach
at
earlier
of
the
project
we
made
a
few
very
important
decisions.
You
know
the
first
of
the
decision
who
made
is
that
we
want
our
framework
to
be
fully
compatible
in
the
support
containerized
the
applications.
A
A
So
that's
you
know
as
a
developer.
As
a
customer,
you
come
to,
you
know
to
our
control
planes
in
a
cloud
you
have
the
same
experience
managing
you
know
the
kubernetes
cluster
in
the
cloud,
and
you
have
the
same
experience,
so
you
can
take
that
knowledge
in
the
skill
set
and
you
have
the
same
experience
where
you
are
managing
a
lot
of
notes
in
on
the
edge.
So
that's
the
kind
of
the
second
scene.
The
third
thing
it's
really
about
the
project.
They
said
we
want
to
take
an
open
approach.
A
We
want
to
make
the
architecture
expendable
so
that
people
can
come
in
and
plug
in
to
add
their
plugins
and
people
can
come
here
and
contribute
to
the
project.
So
that's
kind
of
the
third
approach.
We
said
to
said
that
there
are
a
number
of
challenges
we
have
to
address
as
a
part
of
this
project.
You
know.
First
thing
is
limited
resources
at
the
edge
you
know.
That's
the
computation
of
resources
and
memory
are
very
limited.
A
Math
working
conditions
are
pretty
complex,
so
we
have
to
manage
a
lot
of
these
things
very
carefully
and
to
make
so
hide
a
lot
of
these
complexities
as
a
part
of
the
infrastructure
framework
itself
and
not
having
to
have
our
customers
and
the
developers
to
worry
about
that
and
the
because
we
wanted
the
autonomy
at
the
edges.
So
we
also
want
to
enable
the
the
local
metadata
I
know.
A
You
know
the
the
know
the
computation
can
make
independent
decisions
when
the
network
connectivity
is
lost,
so
there's
a
bunch
of
these
metadata
managing
them,
synchronizes
them
with
the
cloud
and
how
to
manage
them
and
use
them
on
the
ID
in
order
for
decision
making.
So
that's
kind
of
another
major
work
we
have
done
and
the
last
one
is
the
device
management.
You
know.
I
talked
about
this
wide
range
of
the
devices
we
support.
There
are
also
very
wide
range
of
protocols.
A
We
need
to
support
to
get
the
data
flow
from
different
protocols
and
all
that
and
also
with
the
number
of
devices
it
could
be
fairly
large.
So
we
need
to
support
those
as
well.
So
this
is
the
project,
a
Cooper,
IT
project,
the
you
know.
As
I
talked
earlier,
it's
build
upon
kubernetes
hundred-percent
compatible
with
the
kubernetes
api
s--.
A
We
build
a
lot
of
these
optimizations
in
for
this
lightweight
eight.
You
know
1802
scenario
both
for
the
node
component,
as
was
runtime,
would
build
this
by
direction.
Multiplexing
messaging
protocols
between
the
edge
and
the
cloud.
The
metadata
is
a
persistent
at
add
to
the
edge
which
enables
the
total
local
autonomy
when
they
run
without
in
the
network.
We
also
support
extensive
set
of
all
edge
applications
and
the
protocols
you
know,
simplify
the
access
control
of
the
edge
devices
and
you
we
also
have
a
unified
management
for
both
cloud
and
applications.
A
So
this
project
has
a
you
know.
We
actually
talk
about
this
in
the
last
cooper
come
2018
in
INSEAD.
Oh,
we
are
officially
open
source
project
early
this
year.
So
since,
since
we
open
sourced
it,
we
have
been
getting
quite
a
bit
of
full
traction.
You
know
the
project.
The
framework
is
deployed
by
a
wide
range
of
customers,
either
in
production
and
some
of
the
in
you
know,
POC
or
deep
EOC
testing
environment
with
some
pretty
large
deployment
out
there.
We
also
have
a
you
know
the
project
on
github,
with
Twitter's
and
with
the
contributors.
A
Obviously,
this
we'd
like
to
see
a
couple
additional
zeros
behind
all
these
numbers.
So
that's
why
we
want
to
share
this
information
with
all
the
folks
here
and
encourage
you
all
you
guys
to
check
it
out
and
talk
to
us
and
we'll
be
happy
to
to
work
together
to
get
this
seen
even
more
usable
and
developer
friendly.
So
with
that
I
would
hand
it
over
to
my
colleague,
Sean
he's
going
to
cover
the
specifics
about
the
the
cooperage
architecture
as
wise
to
some
of
the
major
decisions.
Sean
thank.
B
B
Okay,
so
hi
everyone,
Sean
Wong,
I'm
gonna
cover
the
architectural
part
of
Quebec,
so
there
will
be
about
six
seven
slides
today
to
talk
about
the
overall
architecture,
our
considerations
and
breakdown
break
going
to
some
of
the
major
components
and
gave
a
1-1
page
overview
of
it.
Then,
tomorrow,
if
you're
interested
in
more
details,
please
come
come
to
our
deep
dive.
It's
the
same
time
tomorrow
in
room,
33,
I
believe,
and
there
we're
going
to
go
into
more
details
of
the
deployment,
the
implementation
and
the
work
flow
and
all
the
considerations.
B
So
there
will
be
some
interesting,
interesting
topics
about
why
we,
this
architecture
versus
some
possible
other
choices
or
whether
or
not
we
can
do
those
things
answer
is
basically
yes,
so
let's
look
at
it.
On
the
overall
level,
like
Jason
said,
this
is
a
edge
computing
platform
that
we
started
about
two
years
ago.
The
the
mission
we
give
it
in
a
short
sentence
is
to
enable
compute
and
the
intelligence
at
edge.
Now
we've
seen
a
Jason
gave
a
lot
of
good
examples
why
this
is
necessary.
I
won't
be
repeating
when
coming
to
solving
the
problem.
B
I
think
the
very
first
thing
before
you
can
actually
utilize
this
computer
resource
is
to
manage
them
right
because,
based
on
the
some
analysts
estimates
we're
going
to
be
dealing
with
hundreds
of
millions
of
potential
computing
devices
in
the
coming
years.
That's
not
in
the
data
center
everywhere,
but
data
center
exposed
and
on
a
power
post
on
a
car
and
everywhere
else
right
so
without
capability
to
manage
them
orderly,
there's,
no
way
you
can
utilize
them
so
and
luckily
I
think
we
came
to
the
right
time
and
with
the
right
technology.
B
Kubernetes
is
the
perfect
compute
orchestration
engine
and
that's
why,
on
you
see
on
the
top,
we
have
kubernetes
and
our
service
is
build
on
top
of
that.
It
talks
in
kubernetes,
api
uses,
kubernetes
object
model
and
it
defines
our
own
object
model
with
kubernetes
CRD.
So
we
want
to
be
full
100%
kubernetes
compatible.
So
we
can
write
the
tied
and
utilize
kubernetes
future
potential
foley.
B
So
here
one
of
the,
if
you
can
see
that
we
did
couple
of
dotted
lines,
the
first
one
is
top
and
bottom
where
it
says
orchestration
versus
compute.
Arc
is
courage
orchestration.
This
is
one
of
the
main
design
decisions
we've
made.
I.
Think
it's
pretty
later
on
proven
to
be
powerful
is
to
separate
orchestration
and
compute
right.
The
separation
people
say
it's
already
separated
right,
but
there's
some
limitations.
B
So
you
don't
want
to
put
too
much
of
august
russia
and
other
tasks
on
it
to
compete.
The
the
pressures
computer
resource,
so
that's
one
thing,
we've
done
and
I'll
also
touch
some
of
the
technical
details
later
on.
Then,
if
you
look
at
the
second
part,
the
bottom
is
compute
or
the
edge
component,
where
edge
component
works.
On
two
major
functionalities,
one
is
compute
and
the
other
one
is
device
connectivity
both
are
important
because
we
work.
Our
main
goal
is
to
enable
compute
at
edge
and
the
real
scenarios
being
applied.
B
There
are
two
major
ones:
one
is
the
computer
oriented,
for
example,
CD
ends
and
small
clusters.
A
couple
machines
on
a
stack
you
can
will
bury
it
somewhere.
The
other
scenario
is
is
what
we
just
discussed
is
nearly
answer.
Even
billions
of
devices
that's
scattered
everywhere,
so
that
modeling
and
managing
devices
is
important
and
we
have
a
full
flow
implemented
in
cube
edge.
Now,
look
at
focus
on
the
left
bottom
side
with
compute.
We
have
an
edge
court.
B
That
is
a
modulized
platform
which
implements
basic
container
interfaces
so
that
we
can
bring
in
new
container
implementations
and
other
technologies
quickly
and
easily.
Then,
with
this
infrastructure,
up
to
this
point,
developers
are
able
to
write
their
business
logic
packing
to
a
container
and
send
it
down
from
cloud
to
our
edge
notes
and
start
running,
but
that's
just
the
beginning,
because
once
you
have
all
this
business
logics,
you
would
want
them
pack
them
into
different
packages.
B
Put
into
multiple
containers
and
potentially
putting
them
onto
multiple
edge
nodes
right
once
you
have
this
in
mind,
you
will
see
that
there
is
a
clear
picture
of
micro-services
right
and
then
it
leads
to
the
idea
of
where
is
the
service
mesh,
and
we
have
answer
for
that.
We
have
a
module
implemented
explicitly
for
service
mesh
is
called
edge
mesh,
and
with
this
we
come
to
the
next
level.
B
Where
developers
have
the
true
cloud
native
experience,
they
would
be
managing
their
services,
incriminating
concepts
of
service
and
divide,
deploy,
multiple
instances
of
the
application
to
different
nodes
onto
your
edge
network,
and
then
you,
you
will
be
able
to
write
the
same
cloud
native
applications
that
runs
either
on
edge
or
on
the
on
the
cloud
or
mixed,
and
that
is
one
of
our
end
goal
is
to
write
something
and
in
a
very
transparent,
called
native
way
and
run
it
anywhere.
You
want,
so
that's
compute.
The
second
part
is
devices.
B
Like
I
said
we
face
the
challenges
of
billions
of
devices
and
thousands
of
different
protocols,
proprietary
different
standards,
different
working
model
and
everything.
So
what
we
want
to
do
there
is
to
have
a
device
be
able
to
first
connect
to
a
containerized
mapper,
where
you
can
convert
all
these
different
protocols
and
manage
their
states
and
convert
that
information
into
standard
MQTT
and
then
through
a
broker.
We
use
mosquito
and
send
all
that
information
to
edge
and
there
it'll
be
shadowed
by
our
own
device
strain
component.
B
So
you
have
a
device
device
string
on
the
edge
side
and
then
further.
The
information
is
origin
actually
create
originated
from
the
kubernetes
side,
with
csa.
Rd
defined
object
models
to
model
these
devices,
and
I
have
a
slide
to
talk
about
that
as
well.
So
with
this
we
think
we
have
a
platform
that
is
flexible
and
open.
You
can
freely
add
new
modules
and
new
functionalities
and
new
technology
into
the
platform.
B
We
think
this
will
be
the
best
fit
for
edge
computing
space
because
we're
seeing
a
lot
of
upgrade
opportunities
in
this
area,
but
also
great
challenges
and
some
technical
in
a
lot
of
technical
innovations
and
so
on.
That's
the
overall
architecture
now
break
down
into
each
of
the
component.
Let's
look
at
PocketStation.
First,
orchestration
part
in
the
first
version
runs
in
the
cloud
with
a
standard.
B
Kubernetes
called
Canaries
master
right,
what
it
does
if
you
look
at
from
bottom
up,
there's
first
of
all
a
gateway,
what
we
call
called
hub,
which
receives
a
connection
from
every
edge
node
and
keeps
that
connection
use
the
channel
for
management,
managing
the
the
device
ins
nodes
and,
as
the
same
channel,
can
be
used
for
other
purposes
for
application
data.
It
statue
as
well
now,
behind
the
hub.
There
are
two
controllers
directly
mapping
to
two
of
the
major
functionality
on
the
edge
side,
which
is
compute
and
device,
so
edge
controller
works.
B
The
computer
side
and
device
works
on
the
device
control
device
control.
Now
both
of
these
they
work
on
top
of
kubernetes.
So
going
to
the
coder,
you
will
see
a
very
clear
pattern.
Each
of
the
control
can
turn
maintains
two
streams.
One
upstream
and
one
downstream,
and
intuitively
upstream
reports
update
status
to
kuba,
Nadi
and
kubernetes.
Then
the
downstream
pushes
object,
definitions
pushes
status
thing
and
all
this
information
down
the
pipe
to
the
edge
to
the
devices
other
than
those
major
components.
B
There's
a
couple
of
assistant
component
I
mentioned
about
a
separation
of
occupation
and
compute,
where
one
of
the
challenge
we
faced
was
in
a
in
a
urban
area.
In
the
environment,
a
traditional
environment,
the
the
storage
volume
was
created
in
a
kind
of
a
synchronous
manner
right,
the
the
persistent
volume
controller
would
actually
go
and
ask
a
volume
to
be
created
or
update
or
delete
it
and
then
wait
for
that
to
come
back
and
finish
a
loop
right.
B
That's
the
only
different
pattern
in
there
we
observe
and
this
thing
will
not
be
happening
once
we
separate
orchestration
was
computed,
because
now
you
realize
that
illustration
is
happening
in
the
cloud,
but
the
actual
provisioning
happens
on
the
edge
node
thousand
miles
away
right.
So
for
that
purpose
we
plug
in
a
CSI
CSI
driver
to
make
this
happen.
B
Similarly,
we
will
you,
users,
developers,
can
add
other
modules
for
validation
for
other
improvements
and
the
application
logic
and
admission
webhook
is
one
we
recently
editing
that
does
basically
device
validation
now
coming
to
edge
side,
edge,
side,
infrastructure
or
frame
requires
uses
the
same
modulized
approach
and
this
approach
actually
is
we're
more
powerful.
On
the
edge
side,
because
we
mention
edge
side
has
limited
resources
and
the
user
scenarios
vary
a
lot
so
currently
in
our
ship
out
code,
the
the
edge
side
module.
B
We
have
probably
seven
eight
of
them
and
there
can
be
a
lot
more
because
it's
there's
a
lot
more
application
and
usage
scenario.
But
a
benefit
of
this
design
is,
you
can
have
one
process
start
running
and
at
the
time
we
can
pick
based
on
our
needs,
which
modules
are
needed.
So
we
can
really
keep
the
footprint
of
this
module
to
the
minimum.
We
can
run
in
some
of
the
cases
to
just
70
megabytes
and
the
truth
is
that
can
be
even
smaller
and
we
could.
B
We
can
see
why
so
again,
edge
hub
is
the
gateway
into
the
system
and
the
next
star
point
star
next
point
is
made
her
manager
made
a
manager
has
two
functionalities.
First,
it
routes
messages
between
cloud
and
edge
and
between
at
different
edge
components
right
to
major
flow.
One
goes
to
the
right
where
it
finishes
the
devices
routine
and
the
other
one
goes
to
downward
to
edge
D,
which
is
the
computer
component.
B
The
second
functionality
of
made
up
manager
is
persist
of
metadata.
Now
this
is
a
major
difference.
We
have
with
a
lightweight
ku
blade
type
of
agent,
where
the
information
of
all
these
objects
from
kubernetes
are
being
cached
locally,
so
that,
in
case
of
let's
say,
there's
a
reboot
of
machine,
a
complete
network,
shutdown
or
anything.
Your
business
logic
won't
stop.
B
Let's
see
a
container
crashed,
you
will
be
able
to
just
take
the
information
from
the
from
the
from
the
local
storage
and
take
the
image
that
we
cache
and
bring
up
the
container
and
keep
the
business
running.
So
it
is
certain
level
of
autonomy
already
later
I'll
talk
about
what.
If
we
want
to
do
more
at
this
stage,
we
have
the
HD,
which
you
can
treat
it
as
a
couplet
light,
and
it
deals
with
standard
container
interfaces.
B
So
you
can
do
all
use
all's
container
technology
freely
and
we
believe
edge
needs
to
use
more
than
just
containers.
As
of
today.
We
think
that
in
the
future
we
will
be
adding
on
the
same
infrastructure
of
VM
support
of
process
of
or
functions,
and
all
these
things
will
come
handy
with
this
infrastructure
in
place.
B
So
let's
talk
a
little
about
device
management.
I
said
that's
the
second
part
of
the
major
functionality
of
edge
devices,
our
first
model
to
assess
CRD.
We
maintain
two
object
model.
One
is
a
device
model
which
is
the
definition
of
what
a
device
is,
how
you're
going
to
reboot
it
into
the
shape
that
can
be
used
if
you
have
to
rebuild
right.
B
So
you
would
be
cashing
this
information
in
the
device
trains
and
there
with
the
settings
there.
It
comes
to
the
standard,
devising
device,
trains
control
where
either
from
the
cloud
or
from
the
edge
side,
you
would
be
able
to
set
expected
States
on
to
the
devices
and
then
that'll
get
get
propagated
to
the
device
and
be
updated,
and
similarly
information
can
flow
backwards
with
actual
state
and
where
all
the
cache
data
can
be
refreshed.
B
We
talked
about
edge
mesh
being
implementation
of
service
mesh,
so
here's
a
little
bit
details
of
how
that
happens.
In
general
concept,
we
use
kubernetes
service
concepts
to
manage
all
the
nodes
and
that
information
is
pushed
down
and
stored
in
our
local
storage.
Then
we
have
a
we
use,
IP
table
mapping
to
hijack
the
traffic
and
from
there
we
will
be
able
to.
We
have
a
internal
build
DNS
that
parses
the
information
get
the
service
names
and,
in
turn,
get
which
parts
actually
support
the
service
and
route.
Your
request
to
one
of
the
pots
right.
B
So
this
this
is
very
clear
and
useful
pattern.
When
you
have
multiple
instances,
for
example,
you
have
a
video
decoding
service,
that's
running
across
multiple
nodes,
with
Xena
within
a
local
set
up,
and
you
want
to
be
able
to
apply
the
same
code
that
micro
service
code.
That's
that's
running
on
the
cloud
and
furthermore
we
don't
want
to
stop
here.
Currently,
our
implementation
connects
nodes
between
or
within
the
same
subnet,
because
there's
ID
IP
based
in
our
bigger
design.
B
We
want
these
nodes
to
be
able
to
talk
to
each
other
cross
boundaries
and
we
want
them
to
be
able
to
talk
node
to
node
and
know
to
cloud,
and
all
these
things
requires
more
work
and
I.
Think
they're
very
interesting
because
we're
going
beyond
just
they
just
compute
orchestration,
we're
talking
we're
getting
here:
the
space
of
potential
applications
of
data
and
information
exchange
or
querying.
So
that's
definitely
one
area.
It
needs
a
lot
of
attention.
Ok,
last
I
want
to
touch
the
topic
of
a
new
component.
We
just
shaped
called
edge
sight.
B
I
mentioned
orchestration
can
run
in
the
cloud
and
in
our
current
deploy
it
doesn't
run
in
the
cloud,
but
there's
nothing
stopping
us
to
actually
run
a
lightweight
orchestration
engine
that
also
talks.
Kubernetes
good
example
would
be
a
case
ray
as
right
now.
I
hope,
I
said
that
name
right
or
yet
another
orchestration
engine.
In
this
case
we
developed
something
on
our
own
called
edge
site.
So
the
architectural
decision
helped
us
in
this
case
that,
because
of
the
separation,
we
can
fulfill
multiple
business
scenarios.
B
Some
customer
will
say:
I
only
have
the
small
box,
which
is
ARM
chip
with
limited
memory.
I
want
this
to
just
be
able
to
run
a
container
right
or
three
containers
to
finish
my
business
logic.
I
don't
want
an
orchestration
engine,
we
can
do
that,
that's
what's
already
there
and
some
will
say:
hey
I
just
wanted
a
private
buildup,
we'll
say.
Yes,
you
probably
won't
be
able
to
use
the
great
things
from
the
cloud,
but
yes,
that's
possible
right.
B
We
could
use
this
approach
and
just
hook
to
a
local
deployed,
orchestration
engine
or
there's
even
fancier.
Things
like
you
could
do
a
backup
generator
type
of
thing
where
you
would
be
running
most
of
the
things
in
the
cloud
when,
when
everything's
perfectly
fine
and
when
there's
a
harsh
or
extreme
situation,
you
would
bring
up
the
backup
generator
and
the
things
will
still
work.
So
that
is
the
topics
I
want
to
cover
today
began
tomorrow.
B
We're
gonna
have
this
deep
Diet
session
and
I
will
dive
into
some
of
the
more
detailed
discussions
and
how
exactly
we
do
these
things
so
you're
welcome
to
come.
Join
us
roadmap
is
I,
don't
want
to
talk
too
much
about
it
because
from
a
description
you
will
see
there's
ton
of
working
every
area
area
in
the
scalability
and
security
and
functionality
in
usability
just
unlimited.
All
we
need
is
people.
We
have
a
limited
list
here
because
we
want,
because
of
the
resource
restraint
now
last
scan
this
get
on.
Twitter
follow
us.
B
We
have
a
Twitter
account,
we're
going
to
start
using
it
more
and
more,
and
then
you
can
find
the
rest
of
the
information
here.
You
can
go
to
github
go
to
the
select
channel.
We
have
a
lot
of
discussions
here
and
talk
to
us
about
your
business
scenarios,
how
you
want
things
to
happen
and
let's,
let's
make
it
happen.
Thank
you
very
much.