►
From YouTube: KubeEdge Deep Dive - 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 Deep Dive - Sean Wang, FutureWei
KubeEdge is an open source project extending native containerized application orchestration and device management to from central cloud to Edge. It is built upon Kubernetes and provides core infrastructure support for networking, application deployment and metadata synchronization across cloud and edge. In this session, Kevin will deep dive details of KubeEdge architecture and some advanced features. The future roadmap and current pain points will also be discussed.
https://sched.co/Uafu
A
So,
thanks
to
everyone
for
making
effort,
I
I
was
myself
was
thinking,
should
I,
take
all
the
walking
and
come
here,
but
okay,
let's
get
started
thanks
to
the
session
of
coop
edge
deep
dive.
My
name
is:
is
Sean
Sean
Wong,
I
I've
been
working
on
the
edge
computing
area
for
the
past
two
plus
years,
so
cube
edge
is
like
many
other
open
source
project
has
its
roots
from
a
commercial
product.
A
So
that's
we
went
all-in
for
it
and,
as
a
result,
in
April
of
2018,
we
shipped
our
first
cloud
edge
computing
platform
in
China.
It's
a
product
called
intelligent
edge
fabric
or
IEF.
So
this
this
product
has
been.
The
service
has
been
pretty
successful
as
an
evidence.
I
want
to
share
that
in
one
of
the
deal
that's
already
being
sign
in
under
deployment.
A
Now
we
are
going
to
be
running
close
to
a
quarter
million
of
containers
on
edge
nodes
across
China
in
the
next
few
years,
so
I
think
for
a
edge
computing
platform
nowadays,
as
a
start,
that's
a
pretty
good
result,
and
that
certainly
also
gave
us
some
confidence
and
also
because
of
our
love
for
open
source.
We
pushed
this
out
end
of
last
year
to
CN,
CF
I,
believe
it's
also
one
of
the
first
edge
computing
platform.
It's
called
curb
edge,
I.
A
Think
I,
see
some
familiar
faces
here
so
today
we'll
be
covering
some
of
the
functionality
aspects
of
deep
dive
and
also
look
at
two
typical
application
scenarios.
So,
let's
get
started
actually
one
more
thing.
I
want
to
acknowledge.
Today's
session
was
supposed
to
be
a
joint
session
between
me
and
Kevin.
Kevin
has
being
our
open
source
front
guy
since
the
beginning
of
Quebec,
and
unfortunately
he
couldn't
be
here
today,
but
I
want
to
acknowledge
his
contribution
and
help
with
putting
the
content
together.
A
So
we
we've
had
some
basic
ideas,
but
the
main
drivers
for
edge
computing
to
become
mainstream.
These
couple
things
it's
about
reduced
latency
and
in
this
area
the
the
major
application
types
are
first
like
machinery,
industrial
machineries
that
needs
very
fast
and
very
reliable
response,
or
the
other
type
is
actually
app.
That's
getting
very
popular
nowadays
as
tik-tok
type
of
things
where
video
sharing
and
video
processing
happens
a
lot
on
edge
front.
A
So
that
was
the
example
of
that
and
the
other
type
is
the
massive,
a
massive
amount
of
data
that
even
with
5g
and
all
that
future
infrastructure.
There's
no
reason
to
send
this
ton
of
non
structured
data
to
cloud
to
be
processed
in
the
stored.
So
that's
the
data
aspect
and
the
third
one
we
actually
do
in
our
practice
fund.
A
Being
a
major
consideration
from
a
lot
of
customers
is
actually
privacy
and
security,
where
individuals
or
businesses
or
government,
don't
want
to
send
their
store
their
information
in
public
cloud
or
want
to
keep
their
eyepiece
to
themselves.
So
those
those
are
the
major
application
areas.
Here's
a
overall
diagram
we've
touched
this
yesterday.
I
want
to
just
give
a
quick
walkthrough.
So
we
we
have
the
background
to
start
cube
edge
is
a
kubernetes
application.
We
build
100%
on
top
of
kubernetes.
A
One
decision
we
made
is
to
separate
the
orchestration
of
kubernetes
from
the
computing
side
of
edge
and
that
separation
gives
us
more
flexibility,
flexibility
later
on
to
meet
different
business
scenarios
I'll
get
into
that
later
on
and
on
the
edge
side,
two
main
functionality,
one
is
compute
that
is
get
a
container
down
and
start
running.
There's
more
detail
of
that,
and
the
other
part
is
about
connectivity,
kiss
edge
computing.
Two
major
scenarios,
one
is
compute
like
we
said,
video,
transcoding
and
so
on.
A
The
other
application
type
is
IOT
where
sensors
sensors,
that
generates
magnitude
higher
level
of
data
than
the
traditional
IOT
is
we're,
seeing
more
and
more
more
and
more
of
that,
and
also
there's
a
being
able
to
connect
all
these
different
sensors
is
one
of
the
big
burden
in
all
this
IOT
or
edge
computing
type
of
development
effort.
So
we
have
a
full
flow
of
solution
for
that.
A
Start
from
the
basics,
how
we
build
it,
we
have
this
in
mind
that
we
want
to
build
a
modulized
framework
that
is
open
and
expandable
for
future
scenarios
and
technologies.
So
that's
that
applies
to
both
our
core
and
our
application
model.
On
the
core
side.
This
whole
app
is
build.
On
top
of
this
thing,
called
beehive
R,
there's,
probably
100
different
beehives.
This
is
yet
another
one.
A
It
uses
co-channel
it's
under
it's
in
the
same
github
under
coop
edge,
so
it
is
a
messaging
framework
and
the
basic
module
of
that
is
module
and
modules
can
be
put
into
groups
and
any
new
modules
or
new
functionalities
can
be
implemented.
By
here
into
this
interface.
You
have
a
name
group
start
and
clean
up.
Then
you
will
be
able
to
get
onto
the
platform
and
start
running
and
talk
to
others.
The
other
approach
we've
taken,
we've
seeing
other
open-source
projects
also
start
to
do
the
same.
A
To
start
with,
you
would
package
your
logic
into
one
container
and
push
it
down
to
the
edge
side
and
start
up
stop
running
then
then,
gradually,
you
would
say:
I
want
different
functionalities.
You
would
have
multiple
containers
running
on
the
same
node,
then
in
areas
you
would
have
multiple
nodes
to
support
a
bigger
area
or
a
campus
or
multiple
things
on
a
long
road.
All
these
different
scenarios,
then
you
would
all
start
and
realizing
you
in
a
micro
service
situation,
and
for
that
reason
we
lived
one
level
up
from
just
containers
to
services.
A
A
There'll
be
a
couple
of
topics
I'll
be
jumping
through
on
each
one
of
them.
I'll
try
to
make
them
clear.
So
this
slide
I
want
to
clear
some
air
there's
some
discussions
in
for
and
others
talking
to
us
asking.
What's
the
difference
between
just
a
couplet
right,
I
think
it's
pretty
clear
with
the
overall
architecture
already
I
just
want
to
emphasize
that
what
we
do
here
is
a
full
fledge
platform
for
edge
computing.
It
it's
overlap
with
couplet
is
actually
in
this
box
in
the
center
marked
as
edge
D.
A
If
you
look
at
the
code,
it
is
actually
taking
the
couplet
code
and
get
rid
of
the
part.
We
don't
need
and
plugging
our
code
to
make
it
work.
So
then,
on
top
of
that,
we
build
local
persistency
for
reliability.
We
build
edge
called
communication
channel
for
management
and
application
data
bus.
We
build
device,
trains
and
device
modeling
for
connectivities
and
device
management
and
so
on.
So
it
is
more
than
just
a
client
all
right,
so
this
is
the
next
topic.
I
talked
about
separating
orchestration
and
so
in
in
a
first
diagram.
A
Let
me
jump
back
a
couple
here.
You
see
a
clear
line
where
we
see
orchestration
or
the
upper
part
which
we
said
is
in
the
cloud
and
the
bottom
part
is
a
jacuzzi.
Now
the
reason
for
that.
We
want
to
make
this
clear
separation
of
orchestration
capability
versus
compute
functionality,
because
in
a
lot
of
scenarios
we
see
it's
actually
a
box,
this
small
or
even
smaller
than
that.
That's
actually
running
all
this
modern
software
stacks.
A
So
we
want
to
have
a
capability
to
manage
really
large
number
undreds
of
millions
of
such
nodes
in
the
cloud
and
be
to
save
as
as
much
resource
as
possible.
So
we'll
talk
about
a
couple
of
variations.
This
architecture
can
actually
support,
but
since
we
separate
computer
and
orchestration,
some
of
the
technical
details
emerges,
for
example,
how
to
create
a
persistent
volume
becomes
one
write
in
a
kubernetes
world.
All
these
things
happens
in
the
same
data
center,
where
you
make
a
call
the
persistent
of
the
PVC.
A
The
claim
actually
is
a
synchronous
call
which
the
external
provisioner
will
call.
The
local
drivers
and
period
gets
the
item
provision
it
will
return.
But
for
our
case
we
have
to
do
it
differently.
So
in
this
flow
you
see
that
starting
from
step,
1,
2
3,
our
typical
crew
Benetti
operations,
then
from
step
4,
it's
actually
calling
into
a
proxy
driver
we
provide,
and
the
function
of
that
is
to
take
this
call
Senate.
A
If
you
look
at
step,
5
and
6
send
it
to
the
cloud
hub
then
push
down
through
our
build
channel
with
WebSocket,
all
quick
through
that
channel
to
the
edge
node
and
there.
It
follows
down
to
HD
HD,
which
is
the
computer
provision
module
where
it
calls
the
kubernetes
building
volume,
plugging
and
then
cost
the
local
store
party
driver
to
actually
provision
this
storage,
and
it
goes
all
the
way
back
up
and
to
step
16
or
17
that
finished
the
full
synchronous
loop.
A
So,
similarly,
for
it
delete
it
happens,
roughly
the
same
I
think
other
than
the
name
is
the
delete
versus
create.
Everything
is
almost
the
same,
so
I'll
skip
that.
So
that
just
shows
the
effort
we
have
to
do,
but
once
app
we
have
that
a
clear
separation.
Good
things
can
happen
because
we
now
have
the
capability
of
not
only
running
a
cooperage
local
deployment
scenario.
We
can
easily
put
the
orchestration
party
in
the
cloud
and
the
compute
miles,
hundreds
of
hundreds
of
miles
away
or
we
could
have
them
moved
or
in
different
scenarios.
A
I
have
a
slide
to
talk
about
that.
The
next
thing
I
want
to
talk
about
is
edge.
Device
management.
I've
talked
about
the
importance
of
it.
We
can
do
full
fledge
device,
connectivity,
modeling
shadowing
and
sync
up
to
kubernetes
the
full
flow,
and
we
use
the
equipment
as
kubernetes
crd,
to
do
this,
so
it's
100%
compatible.
Basically,
there
are
two
object
models
we
use.
One
is
the
device
model
which
describes
what
two
device.
What
a
device
is
like
right
once
you
have
that
it's
an
object
model.
A
You
can
inherit
that
and
build
a
device
instance,
and
that
instance
is
used
to
store
the
each
device
specific
information.
So
a
flow
of
creating
a
device
from
the
cloud
is
clear.
You
would
use
the
CRT,
create
your
own
definition
of
a
device,
speed,
a
thermometer
or
a
camera
or
anything
else
and
push
that
into
kubernetes
and
that
will
get
propagated
down
to
the
edge
side
edge
side.
We
do
a
couple
of
things.
A
We
build
a
device
tree
model
where
we
actually
shadow
the
device
itself
as
a
digital
digital
copy,
and
then
we
build
a
full
flow
of
connectivity
through
a
containerized
mapper.
This
mappers
use
is
from
the
bottom
device
up.
The
mapper
is
used
as
connectivity
module
to
convert,
to
connect
and
convert
the
thousands
of
different
protocols
into
MQTT,
and
you
could
actually
even
do
some
additional
logic
on
top
of
that
and
filtering
and
other
things
and
then
pass
this
through
and
a
MQTT
broker
into
a
event.
A
A
The
protocol
conversion
plugins
OPC
UA
for
industrial
scenarios,
it's
a
standard
there,
there's
Bluetooth
and
it's
Modbus
so
and
the
mapper
itself
is
in
a
demon
Sat
container,
and
we
wanted
to
do
it
this
way,
because
eventually
we
want
this
to
be
a
secured
and
fully
isolated,
using
cotton
or
other
containers
so
because
edge
itself
is
already
outside
outside
of
data
centers.
And
then
these
device
connect,
plugging
becomes
another
layer
of
security
exposure
so
that
these
separate
secured
containers
eventually
we'll
be
providing
good
security
to
all
these
safety
scene.
A
Attack
scenarios
now
I
talked
about
device
strain
a
device
strain
in
our
case
we
actually
referenced
and
borrowed
the
the
Mozilla's
web
of
things,
the
definition
of
device
string.
It
has
three
basic
components:
a
device
is
similar
to
what
a
device
is
a
device
attribute
which
is
a
property
bag
of
each
attribute,
its
value
and
its
version,
and
so
on
and
a
device
string
which
is
also
a
property
bag.
But
the
difference
is
for
a
device
strain.
A
You
have
to
changing
updatable
state
in
an
expected
state
and
a
actual
state
and
the
flow
of
how
this
works
is
actually
asynchronous.
So,
on
the
right
side,
we
have.
This
diagram
shows
how
a
typical
operation
to
set
the
device
status
from
the
cloud
happens.
For
example,
if
you
want
to
change
a
device
from
a
sleep
to
a
active
state
right
that
happens,
we're
setting
up
the
status
in
kubernetes
and
that
gets
put
down
to
our
cloud.
A
The
device,
manager
and
device
manager
then
send
this
information
down
to
the
edge
side
where
it's
get
pushed
into
device
train
that's
step
four,
and
after
that,
this
operation
is
considered
complete.
Now
we
know
that
devices
are
operating
on
a
totally
different
pace.
Some
of
them
are
always
online,
but
some
of
them
are
not
frequently
online.
They
can
be
online
for
every
second
minute
or
even
days.
Right
so
then
happens
is
move
to
the
right
side.
You
see,
device
connects
to
mapper
and
on
step.
A
5
mapper
would
goes
through
a
mqtt
pub/sub
model
and
try
to
get
the
new
expected
state
change
from
device
string.
So
that's
step
5
to
a
broker
6
to
the
event,
bus
and
event,
bus
pulls
from
the
device
string
and
that
information
then
comes
back
and
the
subscriber
gets
us.
Information
is
through
mapper
and
by
this
point
device
knows
it.
It's
expected
to
be
in
an
active
state
and
that's
when
it
happens
so
definitely
pay
attention
to
the
asynchronous
nature
of
this
operation
and
similarly
for
a
set
of
actual
status.
A
A
What
we've
implemented
is
actually
something
that
will
enable
you
to
first
of
all,
write
in
ways
of
fully
called
native
programming,
where
you're
talking
to
services
in
a
micro
service
infrastructure
right,
a
node
from
a
pod
or
a
application
instance
from
one
pod
could
talk
to
a
service.
That's
distributed
the
rest
of
the
deployment,
so
here's
a
flow
of
how
this
works.
A
The
blue
side
is
actually
the
control
flow.
Basically,
you
would
config
a
service,
a
criminality
of
service
and
associated
parts
with
that
service,
and
that
information
is
passed
from
the
top
into
the
edge
node
and
persisted
there
right
with
this
information.
If
in
case,
a
application
wants
to
reach
a
service
like
here,
there's
a
little
bit
confusion.
This
HTTP,
slash,
B,
slash
resource
B
refers
to
another
service,
but
then
there's
a
pot
B
so
ignore
the
pot
B
just
consider
B
as
a
service,
then
what
happens?
A
Is
we
actually
on
a
pot
level
set
up
a
proxy
which
hijacks
the
traffic
and
do
a
we
maintain
DNS
service
internally
of
our
own
and
that
resolves
al7
or
l4
name
namespace
to
a
service
name
and
which,
in
turn,
hooks
up
with
the
servicing
information?
That's
passed
down
to
land,
some
rotation
rule
on
a
pod,
and
so
you
can
finish
the
logic.
And
similarly,
we
don't
want
to
limit
this
to
edge
nose-to-nose.
A
Only
currently
the
code
works
for
the
thing,
for
it
knows
within
the
same
subset,
different
notes,
but
eventually
we
want
this
to
be
able
to
be
a
protocol
or
practice
that
can
be
used
for
notes,
cross
domains
or
notes
and
cloud
services,
the
type
of
communication.
So
in
this
case
you
can
see
that
with
a
router,
the
same
logic
can
be
helped
can
be
used
to
go
through
the
edge
card
boundary
and
actually
reach
a
service
in
the
cloud,
which
is
a
very
typical
scenario
we
will
see
later
on
in
the
application.
A
Okay,
so
time
wise
have
twenty
one
couple
minutes
on
application
scenarios.
So
through
the
practice
we
talk
to
all
the
cost
of
different
type
of
customers
and
understand
their
needs.
What
we've
found
customer
has
a
lot
of
ideas
right
and
it's
really
based
on
reality
of
what
they
have
and
what
they
want
to
achieve.
A
The
left
side
is
very
typical,
cubanelle
implementation
that
you
have
all
constriction
fully
on
the
cloud
and
then
you
have
just
a
very
tiny
boxes,
running
specific
logic
at
each
location,
for
example,
a
convenience
store
a
campus
roadside
box
and
so
on
right.
So
that
that's
a
typical
crash
scenario,
the
other
one
is
the
one
in
the
middle,
where
you
pretty
much,
don't
want
to
deal
with
cloud
component
at
all.
You
just
won't
have
a
deployment,
that's
local
right,
but
kubernetes
itself
may
be
too
big
for
it.
A
So
we
see
some
applications
such
as
Kayseri
as
kik.
Seeing
this
scenario
that
also
works,
but
it's
a
completely
private
deployment
without
utilizing
the
cloud
power
and
then
customer
will
say:
hey
I
have
I,
have
a
business
where
there's
treat
structures
of
organizations
and
headquarters
and
so
on,
and
how
do
I
deal
with
that?
I
think
cooperage
by
the
way
can
deal
with
all
these
scenarios
easily,
because
we
have
this
clear
separation.
We
can
just
plug
the
computing
modules
to
a
different
orchestration
engine
right,
so
we've
we've
seen
requirements
in
reality
for
all
these
scenarios.
A
So
that's
why
we.
We
think
that
the
the
architecture
is
is
a
good
one.
It's
open
and
it's
very
flexible
now
to
real
application
scenarios.
I
want
to
talk
about.
One
is
a
IOT
scenario,
in
this
case
a
smart
city.
Would
this
is
actually
a
more
of
a
traffic
control
type
of
scenario
where
a
couple
of
edge
nodes
will
actually
form
a
small
cluster?
A
Sometimes
a
single
node
actually
connects
to
multiple
cameras,
a
specialty
camera
to
read
the
license
plate
or
just
a
car
outlying
of
a
car
and
there's
cameras
that
we
take
video
of
a
road
condition
of
traffic.
How
many
cars
are
there
doing
stats
on
that
and
then
there's
same
maybe
the
same
algorithm
sitting
on
the
same
stream,
but
trying
to
detect
if
there's
any
illegal
crossing
any
other
situation,
dangerous
situations.
So
this
kind
of
app
is
getting
more
and
more
popular.
A
For
example,
you
want
to
search
a
national
database
or
some
registration
about
the
license
plate
if
it
matches
the
car
description,
if
it
there's
additional
issues
with
that
license
plate
and
so
on,
or
connect
to
multiple
such
edge
nodes
and
find
out
the
traffic
pattern
and
find
a
congestion
trends
and
so
on.
So
this
is
a
very
typical
of
and
very
useful
scenario.
It
cuts
down
dramatically
the
amount
of
data
that
needs
to
be
sent
to
a
central
cloud
and
also
because
it's
on
site,
it's
a
very
fit
efficient,
cost
wise.
A
The
network
bandwidth
is
a
major
cost
in
many
of
the
scenarios
and
we
see
a
clear
pattern
of
edge
and
cloud
Court
coordinating
and
working
together.
We
actually
have
a
term
for
it
called
edge
called
synergy,
and
another
aspect
of
this
is
even
though
it's
behind
the
curtain,
but
there's
a
heavy
training,
as
you
all
see
that
for
all
these
scenarios
to
actually
happen
on
the
card
with
the
limited
computer
resource
before
you
could
actually
implement
all
these
things
and
keep
improving
them.
So
the
loop
is
continuous,
improve
training
feedback
and
improve
right.
A
Second
scenario:
I
talked
about
tik-tok
right,
we
we've
been,
we've
talked
to
customers
in
China
and
worked
on
prototype
prototypes
and
PLC's
with
them.
It's
actually
popular
in
Asia,
now
getting
more
and
more
popular
here
as
well.
So
the
challenge
here
is
this:
large
data
centers
have
unlimited
computer
resource,
but
it's
also.
It
also
has
a
network
connection,
even
though
very
large
already
it's
precious
right.
So
you
don't
want
to
spend
seventy
percent
of
that.
A
So
what
happens
is
more
and
more
business
of
a
video
sharing
type
of
application
moves
such
logic
onto
CDN
or
edge
sites
where
you
have
edge
network
calls,
that's
1/5
of
or
even
less
than
the
large
data
centers
and
you
have
computer
resources
there,
that's
very
close
to
where
the
content
provider
the
are
this
there's
a
clear
pattern
here,
for
example,
metropolitan
cities
will
have
a
lot
more
content
providers
and
viewers.
Then
then
the
rural
areas
right
so
there's
a
concentration.
A
So
if
you
have
more
computer
resources
in
those
edge
nodes
that
solves
the
problem
locally-
and
in
this
case
you
could
also
add
additional
value-added
services
such
as
content
detection
to
make
sure
things
are
legit
legal
and
at
least
appropriate
right
and
edge
coupe
edging
in
this
scenarios
works
well
because
in
this
case
one
of
the
benefit
to
coverage
is
there's
a
very
strong,
constant
connection
and
there
is
resources
there.
So
when
something
happens,
the
connection
even
fails.
A
Those
nodes
can
still
work
on
its
own
because
it's
not
hard
to
bring
up
a
backup
orchestration
engine
and
keep
the
keep
the
business
running
so
I
think
that's
the
that's
that
wraps
up
the
talk.
We
want
this
project
to
get
more
participation,
so
follow
us
on
Twitter
and
scan
that
and
there's
a
lot
of
information
you
can
find
out
only
all
these
different
channels.
A
A
So
right
now
we
can
run
as
small
as
70
megabytes
to
start
the
engine
right
and
because
right
now
we
only
support
container.
That's
we
could
potentially
even
cut
it
that
smaller.
If
you
just
want
to
run
a
process,
we
have
plans
to
run
either
process
or
VMs
through
the
orchestration
engine,
so
that
can
to
a
current
day
arm
or
Intel
box.
Even
if
it
looks
very
small
normally
it
would
have
a
couple
gig
of
memory,
so
that
footprint
is
pretty
small
already.
But
then,
once
you
start
running
sorry,
I'll
just
add
a
little
bit.
A
A
A
A
This
slide.
1
&
2
are
very
simple.
The
one
on
the
Left
says:
I
want
orchestration.
Simply
in
the
cloud
write
a
scenario:
I
want
everything
all
together
in
a
private
setup,
but
customers
sometimes
say
hey
well.
I
have
no
problem,
provide
the
internet
connection,
but
what?
If,
in
cases
the
connection
will
fail
right
in
this
case,
kuba
already
provides
the
capability
to
keep
the
business
running
continuously
without
interruption,
because
with
the
local
data
cache
and
everything
we
can
bring
up
a
container
if
it's
crashed
or
restarted
anything.
A
So
that's
no
problem,
but
customer
one
more
and
they
say
well
if
I
still
want
some
orchestration
capability,
because
they
now
I
have
four
machines
here
and
sometimes
I
need
to
take,
go
to
task
a
little
bit
so
I
think
in
that's
scenario.
There
is
a
chance
we
can,
because
we
have
the
separation
between
call
hub
and
edge
hub.
A
So,
on
the
interface
level,
it
we
only
need
to
direct
to
this
edge
hub
to
another
orchestration
end
point,
certainly
the
more
work
behind
that
is,
how
do
you
think
the
data
and
so
on
so
that
needs
to
be
solved?
I
think
it's
a
completely
solvable
because,
as
you
can
see,
we
have
a
channel
there.
So,
while
the
channel's
open,
you
can
actually
have
that
data
down
and
kept
it
as
a
backup
and
then
when
it
needs
to
switch,
you
can
just
switching.
A
A
A
A
Yeah
I've
seen
people
actually.
Yesterday
I
went
to
a
talk.
There's
a
guy
actually
use
a
plan.
Oh
and
I
personally
tried
it
on
AWS
with
AWS
Network
support
so
and
there's
a
list
of
supports,
because
these
things
actually
is
part
of
kubernetes.
So
well
at
least
the
I
tried
they
all
work,
so
I
would
assume
other
things
shouldn't
be
too
hard
yeah,
but
I
could
be
wrong.
So
send
me
information
if
you
try
something
and
found
there's
a
problem.
A
A
Sure
sure,
so
the
question
is
what
kind
of
load
balancer
you
use
internally.
If
you
drill
down
the
code,
it
actually
uses,
another
component
called
go
chassis.
That's
a
that's!
Also!
A
open
source
project
you
can
find
out
on
github
go
chassis,
implements
a
couple
of
basic
round-robin
and
other
algorithm,
but
this
part
is
basically
pluggable.
We
actually
have
plans
to
integrate
with
SEO
so
that
you
could
actually
be
controlled
by
your
steel
as
well.
A
A
Okay,
the
question
is:
how
do
you
keep
the
connecting
connectivity
between
agent
cloud
so
eat
all
the
connection
are
issued
from
edge
because
the
network
situation,
the
best
you
can
do-
is
start
a
eggs
external
facing
outgoing
connection
right.
So
we
implement
a
WebSocket
implementation
for
the
connectivity
or
quick.
Both
are
there
qu
IC
they're,
all
they're,
both
bi-directional,
so
you
can.
You
can
pass
on
different
message
types
or
implement
different
protocols
on
it.
A
A
A
You're
right
conceptually,
a
node
is
a
very
powerful
device
yeah.
So
as
a
modeling
as
a
concept,
that's
a
that's
a
hierarchy.
We
make
them
separate,
so
people
are
easily
and
understand
this
and
work
on
this
concept.
So
because
often
cases
what
you're
dealing
with
is
a
compute
module
connecting
to
a
bunch
of
sensors.
Those
are
called
devices
and
they
will
be
managing
the
state
and
retrieving
data
and
processing
them
to
finish
the
business
logic.
So
you're
right
it
logically
that
a
node
is
a
device
yeah.
A
A
A
A
A
A
A
So
what
we
do
is
in
current
setup,
a
device
will
actually
have
a
link
reference
back
to
which
compute
module
it
belongs
to
right,
but
then
there
certainly
comes
with
the
question
of
what,
if
this
computer
module
dies
down
and
you
can
still
access
a
device
through
the
network
right
so
currently,
we
would
be
pointing
that
pointer
to
another
computer
node
and
to
reach
the
the
balance,
but
similar
thing
can
be
done
with
the
load
balancing
to
consider
some
of
the
vicinity
factors
to
see.
Let
me
choose
the
one
that's
closest
to
me.
A
A
Good
point,
crustiness
is
each
node,
as
edge
is
edge
mesh
within
the
node
answer.
Yes,
it's
different
from
the
sidecar
concept,
so
we
maintain
a
module.
So
all
these
concepts
of
the
whole
edge
point
is
inside
a
note,
so
it's
edge
mesh,
so
they
actually
takes
hijacks
all
the
traffic
for
that
node
and
process
from
there.
A
You
you
would
have
the
concept
of
service
and
a
service
would
group
these
parts
together.
They
would
be
able
to
tell
this
service
runs
on
this
one.
Two
three
parts
on
these
one:
two
three
nodes,
and
once
you
have
that
information,
what
you're
doing
is
actually
finding
what's
a
service
that
is
trying
to
call
get
the
three
nodes,
get
the
three
parts
and
try
to
find
the
next
one
or
the
proper
one,
and
send
that
hook
that
up
yeah.
A
A
Oh
I
was
I
was
explaining
this.
This
is
module
is
a
framework
we
use
cut
beehive,
we
have
our
own
beehive,
that's
a
go
channel
based
communication
mechanism,
the
basic
function
block
on
that
is
a
module.
So
let's
say
I
want
to
build
a
hedge
mesh
I
want
to
build
a
IP
lookup
or
something
each
one
will
be
defined
as
a
module
and
that
module
needs
to
implement
these
four
interface.
And
then
you
can.
A
A
A
A
Inside
edge
core,
we
also
have
a
device
controller
which
actually
subscribes
to
all
this
different
topics,
and
the
itself
also
holds
a
list
of
topics.
So
it
will
constantly
look
for
information
status,
change
in
everything
and
facilitate
the
information
passing
either
to
the
cloud
or
to
the
device.
So
is
there
a
aspect
to
you,
you're
thinking
of.
A
Okay,
so
status
change
of
a
resource
needs
to
be
reflected
right,
yeah,
I
think
that's
that's
what
we
do,
because
on
the
kubernetes
level,
all
these
objects
with
list
and
watch
you
will
be
able
to
sense
any
of
the
status
change
right
for
other
objects
as
well.
So
I
believe
you
can
do
that.
This
shouldn't
be
a
problem
similar
thing.
A
Yeah,
in
this
case
bottom
line,
all
functionality
continues.
Even
if
a
module
or
a
pod
crashes,
you
would
still
be
able
to
use
the
local
cache
and
metadata
and
the
local
cache
the
image
to
bring
it
back
up.
So
that's
the
minimum,
so
business
will
keep
running
and
eventually
we
would
need
you
to
come
back
or
we
have
a
component
called
edge
site,
which
is
a
orchestration
engine
just
like
Kayseri.
Yes,
you
can
run
that
and
that'll
give
you
the
orchestration
capability.