►
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: KubeEdge - Cindy Xing, Futurewei & Dejan Bosanac, Red Hat
Recently KubEdge was accepted as a CNCF sandbox project. As one of the reference architecture, KubeEdge provides customers a way to manage Edge nodes from cloud and build fundamental infrastructure targeted for IOT/Edge.Developers and end users can be empowered to build & run all kinds of potentials through KubeEdge. We welcome communities to join us and make innovations in IOT/Edge computing. In this talk, Dejan Bosanac from Redhat will share background and design principles for KubeEdge. The technical challenges in IOT/Edge computing and how KubeEdge tackle the problems will be discussed. Through real life use cases, Dejan Bosanac, the lead of Kubernetes IOT/Edge workgroup, will share the WG vision and how KubeEdge aligns.
https://sched.co/Ngpl
A
I
think
we
can
start
good
afternoon
everybody.
My
name
is
Cindy
Singh
I'm,
a
software
architect
for
future
away
and
then
specialized
for
public
cloud
service
infrastructure.
My
interest
area
is
in
the
at
computing
currently
I'm
leading
the
Q
badge
project
I'm
also
co-chair
in
with
Stan
and
the
kubernetes
I.
Would
he
add
what
group.
A
C
B
So
before
we
go
to
the
project
itself,
we
you
know,
let's,
as
you
said,
try
to
frame
a
problem
a
little
bit
and
you
know
what's
what's
the
edge
computing
in
general
and
and
what
are
the
challenges
of
doing
edge
computing.
So,
basically,
as
one
of
our
colleagues
Steve
said,
edge
computing
is
everything
edges
everything
that's
not
in
the
cloud
right,
so
the
idea
is
is
to
try
to
put
the
workloads
as
close
to
the
users
and
the
devices
that
that
are
using
those
workers
as
possible.
B
B
So,
with
those
thoughts
in
mind,
we
started
the
kubernetes
IOT
edge
working
group,
just
a
quick.
We
have
a
session
on
that
working
group
on
Thursday
I,
think
4
p.m.
so.
If
anybody
is
more
interested
in
that
general
topic,
I
would
advise
you
to
to
join
us
there,
and
we
started
the
working
group
as
a
way
to
try
to
actually
frame
this
problem
to
see
to
see
how
to
to
to
go
there
and
provide
some
basic
reference,
architectures
and
implementations
for
this.
B
This
is
where
the
the
Cindy
and
the
and
the
cubit
project
came
in
as
well
and
providing
our
basically
reference
implementation
for
one
particular
use
case
and
that's
IOT,
III,
th
and
basically
solution
for
the
device
edge.
So
it's
now,
since
you
have
sandbox
projects
and
Cindy,
will
go
on
and
give
you
more
details
about
it.
Okay,.
A
So,
as
what
Dan
mentioned
here,
we
are
talking
about
edge
computing
as
computing
brought
enterprise
and
customers
a
lot
of
benefits.
Meanwhile,
it
has
a
lot
of
challenges.
So
what
exactly
qubit
is
about
it's
about
the
mission
we
are
trying
to
enable
is
to
enable
enterprise
or
customers
manage
their
resources
at
edge
and
also
be
able
to
orchestrate
their
applications
at
edge.
A
A
Kubik
will
use
the
will
follow
our
support,
the
kubernetes
primitives,
nothing
will
be
changed
and
then
they
were
like.
We
want
to
address
all
the
at
workload.
Technical
challenges
think
about,
for
example,
your
work
node,
my
behind
the
fare
wall
and
also
your
worker
nodes.
The
network
connectivity
between
the
worker,
node
and
the
cloud
might
not
be
reliable
and
also
the
scalability
of
the
worker
nodes
can
be
much
bigger
than
the
data
center.
A
We're
talking
about
fleet
of
edge
nodes
and
fleet
of
edge
devices,
and
there
are
everything
integrated
together,
imagining
in
the
end,
you're
running
a
kubernetes
space,
the
infrastructure
to
manage
data
center
machines
and
also
machines
at
edge
and
nodes
freely
in
the
sense
of
network
storage
and
compute.
That's
what
the
end
goal
we're
trying
to
achieve.
A
Then.
Let's
talk
about
the
current
architecture,
as
you
can
see,
Kubik
currently
is
open
sourced,
both
the
cloud
section
and
the
edge
section
in
the
cloud
part:
it's
basically
a
kubernetes
control,
plane,
plus
a
cup
of
components,
edge,
controller
and
claw
hub
and
then
on
the
edge
side,
because
the
in
the
consideration
of
H
nodes
are
resource
constraint.
A
You
can
register
your
node,
deploying
applications
and
later
on,
we
are
also
planning
to
support
service,
endpoint,
etc.
Okay,
so,
as
I
mentioned,
also
on
the
on
the
agent
side,
there
you
can
see
multiple
boxes.
There
are
modules
we
have
a
pretty
cool
infrastructure
which
I'm
gonna
deep
dive
on
Thursday.
The
infrastructure
is
called
big
beehive
so
that
you
can
plug
your
modules,
for
example,
for
my
edge
workload,
I'm
not
gonna,
support
the
device,
then
you
don't
need
to
run
those
or
configure
those
modules
so
that
your
agent
can
be
even
smaller.
A
Another
special
thing
I
want
to
share
with
you
about
Kubik
is
the
concept
of
cubed.
Is
that
you
run
your
control
plane
on
the
cloud
and
then
your
edge
node
is
close
to
your
data
or
close
to
your
customers.
So
this
way
the
management
overhead
is
much
smaller.
Comparing
to
you,
if
you
run
a
whole
cluster
at
the
edge
side
and
then
the
other
part
I
mentioned
the
edge
node
network
connection
with
the
cloud
might
not
be
reliable.
A
A
So
when
the
edge
node
is
connected
to
the
cloud
when
it's
linked,
then
other
customers,
metadata
like
say
no,
the
pod
or
the
information
will
flow
down
through
cloud
hub
and
add
hub
to
the
add
node,
as
specifically
for
that
edge
node
after
that
in
case,
the
edge
node
is
disconnected
from
the
plow
the.
Since
the
data
is
cached
persisted
on
the
outside,
then
even
without
the
network
connection,
everything
the
business
can
continue
running.
So
that's
the
beauty
of
this
architecture.
The
other
one
I
want
to
mention
is
I.
A
As
I
said,
it's
targeted
specifically
for
that
node
think
about
currently,
when
Coolidge
connects
to
API
server,
it
watches
all
the
part
for
the
cluster
and
then
applying,
and
then
collate
will
figure
out
which
part
bound
to
that
node
and
do
the
business
with
this
architecture.
The
cloud
hub
trying
to
flow
down
or
send
message
to
the
add
node.
They
only
send
the
messages
specifically
for
that
node.
So
in
that
sense
we
make
sure
the
we
can
Geneva
larger
scalability,
because
in
that
sense
the
API
server
supposedly
can
support
more
notes
than
current
a
couplet.
A
A
kubernetes
has
the
other
thing
from
a
feature
perspective
I
want
to
mention
is
currently
cubic,
supports
device
management
and
also
you
can
run
it
also
supports
device
tree
on
the
edge
site,
so
that,
like
you,
can
deploy
your
IOT
applications
to
the
edge
node.
We
also
supports
the
mqtt,
so
I'm
going
in
the
zero
point
three
release.
We
also
enable
the
device
CRD
so
that,
like
you,
can
even
deploy
your
devices
through
the
cloud
to
that.
A
So,
what's
next,
as
I
mentioned,
like
a
qubit
currently
support
most
of
the
kubernetes
primitives,
then
there
are
more
challenges.
As
I
mentioned,
the
uber
vision
we
want
to
enable
is
like
micro
service,
our
service
mesh,
so
that
when
you
deploy
micro
services
on
the
edge,
a
workload,
things
can
just
work
as
it's
in
data
center.
So
the
next
we
are
investigating
or
innovating
is
around
the
service
mesh
area.
A
If
you
look
at
Envoy,
linker,
D
or
network
service
mesh,
the
bunch
of
innovations
in
the
in
the
community,
so,
for
example,
alloy
is
running
the
sidecar
continue
within
the
pod.
A
linker
D
is
running
a
network
proxy
per
node
and
then
network
service
mash
is
allowing
customers
to
configure
their
layer,
2
layer,
3
network,
so
for
cool
badge.
What
we
plan
to
do
is
on
each
node.
We
are
going
to
run
network
proxy
and
then
on
the
cloud.
We
are
also
gonna
run
another
middle
middle
bridge,
prog
network
proxy.
A
A
The
next
feature
I
want
to
address
is
edge
side,
as
I
mentioned
the
cube
and
before
we
were.
The
original
customer
scenario
we
want
to
address
is
customer
have
their
control
plane
on
the
cloud
and
worker
node
on
the
edge.
But
meanwhile
there
we
got
to
the
from
Cuba
gum
Seattle,
which
we
heard
customers.
They
want
to
run
clusters
at
their
edge
side,
so
the
edge
side
design
is
basically
for
that
propose.
A
A
Again,
this
is
in
progress
feature.
It's
all
the
design
dock
is
in
github.
All
of
you
are
welcome
to
provide
your
feedback
contribute.
Even
the
third
one
I
want
to
share
is
like,
as
I
mentioned,
at
computing,
comparing
with
data
center,
the
scalability
can
be
much
bigger
with
the
design
of
cubic
we
in
implemented
design
implemented.
The
performance
measurement
framework
is
based
on
cool
mark,
but
it's
targeted
for
cube
cubic
and
then
we've
already
finished.
The
implementation
collected
some
performance
data,
but
this
this
effort
is
ongoing.
B
And
finally,
the
the
future
releases
will
include
all
the
all
the
all
the
features.
That
Cindy
also
also
mention
before,
like
like
a
service
mesh
and
edge
sites,
and
and
and
things
like
that,
so
we
can
now
talk
a
little
bit
about
how
the
qubit
stands
in
the
whole
community,
so
the
the
qubits
community,
but
also
other
open-source
IOT
communities.
So
first
and
the
foremost
the
the
kubernetes
IOT
and
edge
working
group
is
the
place
where
we
basically
discuss
all
the
the
basic
designs
and
principles
and
challenges
around
around.
B
All
these
so
I
think
that
work
is
gonna,
get
going
for
a
while,
and
also
one
of
the
things
that
that
qubit
doesn't
doesn't
solve.
All
on
its
own
is
is
that
layer
of
application
layer
of
the
of
the
IOT
solutions,
and
that's
where
the
Eclipse
IOT
community
can
can
come
in
hand
because
there's
a
lot
of
projects
there
that
that
can
provide
you
with
a
lot
of
tools
to
put
put
and
develop
and
IOT
IT
solutions
in
in
in
in
kind
of
a
cloud
native
ways.
B
So,
first
one
I
would
mention,
is
Eclipse
horno,
which
is
connectivity
layer
for
the
IOT
messaging.
If
you
go
couple
slides
back
and
showing
the
basic
are
hit
architecture
of
the
of
the
qubit.
We
have
these
things
here
where
the
event
bus
connects
to
the
MQTT
broker.
So
that
is
what
one
one
way
one
integration
point
we
can
do
for
the
for
the
cube
asian
and
eclipse
horn.
Oh
we're
basically
connecting
connecting
cube,
cube,
edge
applications
running
on
the
edge
to
the
to
the
cloud
connectivity
platform.
B
Additionally,
in
the
Eclipse
community,
we
have
a
clip
side,
IOT
fork
project
which
focuses
on
developing
micro
services,
developing
a
micro
service
framework
for
for
the
edge
computing
and
I
think
there's
a
lot
of
possibility,
possibilities
for
collaboration
in
that
area,
but
even
even
edge
computing
is
becoming
like
interesting
topic.
So
so
there's
a
they're
working
groups
popping
up
everywhere.
A
kirino
is
one
of
the
interesting,
the
working
group
within
the
linux
foundation.
B
A
So
all
the
cubic
information
can
be
found
here.
We
also
have
a
cubic
computation
if
you
participate
and
then
you
can
even
potentially
get
a
free
ticket
to
cook
on
Shanghai
this
year
so
again
like
in
the
end,
no
matter
kuba
itself
or
the
kubernetes
edge
iot
workgroup
many
is
to
meet
all
the
enable
the
community
and
meet
our
your
needs.
So
you
are
all
welcome
to
participate
and
contribute.
D
D
A
Okay,
so
from
an
architectural
design
perspective
theoretical,
a
cubit
should
have
better
scalability,
comparing
to
the
current
kubernetes
the
reason
as
I
mentioned,
because
for
each
in
kubernetes
each
couplet
needs
to
maintain
multiple
watches
against
API
server.
But
with
this
design,
only
the
ad
controller
is
doing
the
watch
and
then
they
use
message
flow
to
send
down
all
the
metadata
to
add
workloads.
So
that's
a
theory.
We
are
still
measured
measuring
the
data
so
far,
we're
still
like
validating
the
concept.
The
goal
would
be
back
to
your
question
about
the
goal.
A
E
A
Okay,
so
in
kubernetes
the
node
is,
is
a
logic
concept
right.
So
basically
you
create
a
Yama
file.
Then
you
can
register
the
node.
So
then,
from
that
perspective,
cooperage
agent
is
the
same.
So
for
the
Kubiak's,
once
you
install
the
agent
and
then
on
the
cloud,
you
do
you,
author,
a
node
llamó,
and
then
you
register
the
agent.
Once
the
agent
connects
to
the
little
cloud,
then
it's
just
working
and
then
meanwhile
for
the
cubic
agent,
we
just
rewrite
cubelet,
remove
all
the
unnecessary
code.
For
example,
we
are
not
statically
linked
to
the
dr.
A
A
Okay,
I'll
first
share
and
then
can
add
if
I
miss
anything
so
tomorrow
or
Thursday
afternoon,
there
will
be
a
kubernetes
IOT
at
computing
workgroup
presentation.
We
will
talk
more
about
this,
but
the
short
answer
is:
there
are
two
points.
First
of
all,
for
cube
edge,
the
original
design
is
the
claw.
The
control
plane
is
on
the
cloud
and
then
edge
node
is
on
the
edge
and
then
Ford
Ranger
k3s.
A
The
targeted
customer
scenario
is
to
run
the
whole
cluster
at
the
edge.
So
from
a
customer
scenario
perspective
they
are
targeted
different
things,
that's
first.
Secondly,
as
I
mentioned
in
the
slide
slide
deck
for
the
edge
site
design,
we
are
also
covering
or
enabling
cube
edge
to
run
cluster
on
the
edge
so
and
then
plus
the
agent
talked
to
the
cloud
using
the
same
community's
API
protocol.
So
in
that
sense
the
cube
edge
agent
can
talk
to
a
k3s
server
without
problem.
A
F
A
So,
as
I
mentioned
earlier,
because
in
the
kubernetes
control
plane,
you
have
a
API
server,
I'm
back
in
the
etcd
right,
so
etcd
store
or
the
customer
deployment
metadata
and
then
through
the
qubit
architecture,
all
the
metadata
data
flow
down
to
the
edge
side
and
persisted
to
the
local
store.
So
all
the
customer
deployment
need
is
already
there
and
it's
already
scheduled
to
that
node.
A
Once
the
network
is
disconnected,
the
cooperage
agent
will
just
watch
to
the
local
store
and
then
take
all
the
action
orchestrate
with
starter
or
whatever
continue
renting.
That's
how
we
so
basically
through
the
mirroring
of
the
two
data
store,
as
well
as
the
message
channel.
We
achieved
the
autonomy
and
network
at
this
connection,
our
reconnection
scenario,
yeah.
A
Yeah,
that's
an
excellent
question.
So
if
you
go
to
github
right
now
for
Cuba
edge,
we
are
using
docker
host
network
right
now.
The
assumption
is
because
the
edge
node
is
resource
constraint.
We
don't
foresee
people
run
a
lot
of
parts
on
the
edge
node.
That's
why
we
use
the
host
network
on
the
edge
side.
Then
we
are
also
assuming
all
the
edge
nodes
are
in
on
the
same
subnet,
because
from
a
kubernetes
perspective,
the
network
assumption
is
it's
a
flat
network
right.
A
So
that's
the
current
stage,
but,
as
am
I
back,
there
is
a
service
mesh
design
right
so
later
on
using
the
the
per
node
network,
proxy
and
the
cluster
level
proxy
on
the
cloud
we
want
to
enable
or
cover
all
the
possible
network.
Topologies,
for
example.
In
case
your
edge
node,
is
behind
the
fair
wall.
Are
we
going
to
enable
a
VPN
or
tunneling
and
then,
in
case
of
network,
disconnected
the
the
west-east?
A
B
A
H
A
So
if
I
understand
your
question,
you're
saying
I
can
select
different,
as
you
know,
to
deploy.
My
application
is
all
right,
so
it's
it's
gonna
be
philosophically
it's
gonna
be
the
same
as
existing
kubernetes
cluster.
We
can
use
the
label
selector
just
label
your
node
and
then
deploy
your
it's
the
same.
So
the
beauty
of
this
architecture
is
to
cover
all
the
technical
challenges
for
edge
computing,
but
maintaining
the
same
principles
for
kubernetes
same
primitive,
same
API.
Everything
works.
The
same
you
just
not
transparent
off
the
location
of
your
notes,
so
you.