►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://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 - Zefeng Wang (Kevin), Huawei
KubeEdge is an open source edge computing framework that extends the power of kubernetes from central cloud to edge. It provides edge autonomy, application management and service communication across cloud and edge sites, device management for multiple IoT/Edge device communication protocols with lightweight implementation. During this talk, Kevin will review KubeEdge motivation, architecture; then go through latest updates on new features and user adoptions. After that Kevin will introduce where the project is heading to, new SIGs formed recently and how new contributors to get involved. There will be an open Q&A for attendees to ask questions.
https://sched.co/ekGU
A
Hello
welcome
to
the
qbh
introduction
session,
I'm
kevin
wong,
the
maintainer
of
kubernetes
project.
Today
I
will
go
through
the
cubic
briefs,
including
the
background,
motivation,
major
design,
consideration,
architecture
and
also
community
updates,
including
new
sigs
and
new
features,
and
then
I
will
quickly
go
through
the
use
case
and
the
future
plan,
and
hopefully
we
can
have
time
for
the
q
a
so.
We
know
that
the
network
is
becoming
more
and
more
powerful
today
and
more
and
more
people
start
to
build
business
at
the
on
the
age.
A
A
While
in
the
h
cloud
it
becomes
a
bit
different
because
the
the
hash
rates,
the
computing
power,
is
less
than
the
central
cloud
and
it's
much
more
closer
to
the
end
user.
So
it
typically
consists
more
of
transcoding
code
and
including
a
few
ai
inferencing
and
while
on
the
iot
age,
it's
actually
very
very
close
to
the
data
source
and
end
user.
A
So
it's
almost
running
the
ai
inferencing
workload
there
so
basically
from
the
cloud
to
the
edge,
the
closer
to
the
edge,
the
lower
latency
and
while
the
the
underlying
hardware
are
very
different.
So
in
the
central
cloud
we
know
that
we
we
have
a
kind
of
a
very
standard
physical
servers,
but
the
underage
they
are
very
different,
like
10
servers
and
iot
gateways.
So
the
the
hardware,
the
and
the
hashtag
types
are
very
different.
A
We
know
that
the
kubernetes
and
the
cloud
native
technology
are
very
successful
in
the
ecosystem,
especially
define
the
containerized
application
model
which
make
it
really
easy
to
build
ones
from
everywhere,
and
also
the
layering
container
image
mechanism
makes
it
very
easy
to
optimize
the
the
whole
image
size
and
also
kubernetes
provide
a
very
good
application
obstruction
and
already
becomes
the
defective
standard
in
the
central
cloud.
If
we
build
with
the
same
technology,
it's
very
easy
to
achieve
same
experience
across
cloud
and
age
and
also
for
kubernetes
itself.
A
The
architecture
is
very
accessible,
including
the
api
machinery,
the
crd
mechanism
and
also
for
kubernetes
itself,
it's
very
easy
to
add
customized
components,
customized
controllers
and
or
operators,
but
there
are
also
some
challenges.
So
we
know
that
the
age
one
of
the
difference
to
the
central
cloud
is
that
the
resources
are
quite
limited,
especially
in
the
iot
and
the
industry
cases
the
the
can
servers
can
be
down
to,
for
example,
512
megabytes
and
maybe
even
less,
but
for
vanilla,
kubernetes.
A
Almost
the
smaller
deployment
need
one
gigabyte
right
and
even
just
the
kubelet.
It
takes
a
lot
of
memory
and
also
the
network
between
cloud
and
h
are
quite
different.
Some
of
the
age
locates
behind
a
firewall
or
inside
a
private
network
doesn't
have
a
public
ip
and
also
the
bandwidth
are
very
limited
and
also
the
latency
is
very
different
compared
to
the
the
network
inside
a
data
center
and
if
we
want
to
run
the
applications
on
the
age
really
really
in
a
good
experience.
A
In
that
case,
we
should
not
evict
or
migrate
the
applications,
because
the
we
just
lost
the
connection
not
lost
the
physical
servers
and
the
instances
there
and
the
another
big
challenge
is
that
in
the
iot
and
the
industrial
cases
there
are
a
lot
of
each
device
use
different
device
protocols.
So
how
to
simplify
that,
for
the
application,
developer
is
also
a
very
big
challenge.
A
Mechanism
across
cloud
and
age,
especially
cuba,
provides
a
seamless
cloud
and
age
coordination
by
implementing
a
biodirectional
communication
channel
and
making
able
to
to
communicate
even
even
going
through
a
private
subnet.
So
I
want
to
also
highlight
that
q
major
starts
with
the
putting
the
no
kubernetes
node
in
onto
the
edge,
because
that's
much
easier
for
lowercase
low
resource
use
cases
and
also
cuba
introduced
that
load
level.
A
Metadata
persistency,
which
reduced
the
disaster
recovery
time
to
make
the
node
get
ready
even
more
faster
and
also
we
did
some
optimization
to
reduce
the
memory
framework
footprint
on
the
on
the
age
components.
So
itself
takes
around
70
megabytes
and
also
we
support
the
oci
conformant
run
times.
For
example,
we
integrate
with
cryo
the
total
memory.
A
So
this
is
a
very
high
level
view
of
the
qbh
architecture.
So,
on
the
top,
let
me
start
on
the
top.
You
can
find
out
actually
it's
a
vanilla,
steel,
vanilla,
kubernetes,
cluster
and
cubic
just
added
a
few
aj
notes
so
to
the
kubernetes
and
master,
because
we
understand
the
mechanism
of
kubernetes
work.
So
it's
actually
treating
the
each
node
same
as
the
cloud
nodes.
A
As
I
mentioned,
that
we
support
the
oc
or
the
oci
conformant
container
runtime,
and
also
we
support
the
c9
and
the
csi
storage
on
the
age
and
for
the
part
mod
to
product
communication,
because
the
network
environment
might
be
different
in
the
data
center
or
in
the
cloud.
So
we
introduced
a
hms
layer
to
resolve
the
all
the
communication
things
and
for
the
devices
so
so
cubah
today
is
actually
relying
on
mqtt,
because
mqtt
is
a
bit
more
popular
than
the
other
industrial
protocols.
A
So,
basically,
for
the
device
developers
they
can
develop
a
protocol
converter
to
integrate
with
the
device
using
the
its
actual
device
protocol,
while
converting
the
all
the
message
contender
to
mqtt.
So
for
the
application
developers,
they
are
much
much
more
easier
to
develop
their
own
applications.
They
just
need
to
deal
with
the
communication
through
mqtt
instead
of
the
all
the
other
actual
device
protocol.
A
So
for
the
cloud
core
here,
I
just
want
to
highlight
that
it's
actually
dealing
with
the
shutter
management
for
the
notes
on
the
age
and
also
the
devices
so
for
to
the
kubernetes
cluster.
All
the
the
node
object,
and
also
the
application
object
life
cycles,
life
cycle
actions
are
are
reflected
so
the
to
the
kubernetes
master.
You
just
treat
all
the
things
in
the
same
so
inside
cloud
core.
A
We
have
each
controller,
so
this
one
is
the
shutter
management
for
actually
the
core
apis,
including
the
the
nodes
parts,
config
map,
etc,
and
also
for
the
iot
and
industry
device
management.
On
the
age
we
introduced
a
instead
of
device
api,
including
the
device
model
and
the
device
instance,
and
we
also
added
a
device
controller
to
reflect
the
lifecycle
updates
and
it's
basically
the
shutter
management
for
the
devices
on
age.
A
The
cuba
csi
driver
is
actually
a
plugin
to
trying
to
hook
the
the
requests
like
storage
provisioning
requested
to
the
age
so
with
cuba,
hcsa
driver
it's
very
easy
to
integrate
third
party
csi
drivers
on
the
age,
so,
basically
you
can
export
any
existing
third-party
csi
driver
implementation
to
qh.
You
don't
need
to
worry
about
the
the
communication
between
cloud
and
age.
A
Enforcement
for
for
the
edge
computing
use
cases,
for
example,
we've
noted
become
offline
for
a
period
of
time.
We
may
not
evict
the
part
in
the
default
period
of
time,
so
how
can
cuba
works
so
so
this
one
where
you
might
be
familiar?
It's
actually
a
lifecycle
of
a
of
a
application
running
in
a
vanilla,
kubernetes
cluster.
So
so,
actually
what
qhd
is
a
equivalent
replacement
of
a
vanilla,
coolant
behavior.
A
So
in
the
vanilla
kubernetes,
we
know
that
after
a
scheduler
find
the
proper
node
for
part,
it
will
update
the
parts
back
to
fill
up
the
part
node
name
and
then
the
cubelet
will
guide
the
notification
and
then
spin
up
the
part.
The
containers
on
that
note
right
so
in
cubase
how
to
make
it
possible
to
spin
up
a
container
on
the
edge
so
actually
after
scheduler
run
the
positive
node.
A
So
what
are
inside
the
a
h
chord
so
so
each
hub
is
actually
a
equivalent
implementation.
Comparing
to
the
cloud
hub.
It's
actually
dealing
with
the
communication
between
cloud
and
age
and
also
make
it
possible
to
talk
across
firewall
or
or
even
the
edges
behind
a
even
if
the
agency
located
inside
a
private
network,
so
the
meter
manager
will
do
the
basically
provide
the
load
level,
metadata
persistence.
Functionality.
A
It's
syncing
the
device
status
between
cloud
html
and
the
device
so
the
hdbus
event
bus
is
a
mqtt
to
to
to
to
to
talk
between
the
device
swing
and
the
the
device
mapper
actually,
and
also
the
age
measures
mentioned
in
the
previous
slides.
It's
dealing
with
the
part
part
and
also
the
service
load,
balancing
and
also
the
node
level.
Local
dns
resolution
resolution.
A
A
A
So
for
code
we
know
that
we're
just
coding
the
ide
and
for
building
we
have
the
first
building
and
for
testing.
We
have
architecture
special
tests
and
also
we
in
our
ci.
We
have
full
arm-based
cia
tests
and
also
the
x86
verifications
so
for
qbh
community.
Very
big
new,
exciting
news
to
share
here
is
that
we
moved
to
since
incubation
in
september
this
year.
A
And
another
thing
I
want
to
highlight
here
is
that
we
we
are
currently
moving
to
the
sig
based
japanese
model,
so
we
enforce
the
iot
device
sqlt
device,
so
this
one
is
focusing
on
the
iot
and
the
industrial
internet
relevant
work
to
improve
qbh
and
also
provide
a
better
user
experience.
Developer
experience
for
the
iot
and
in
the
industry.
A
Internet
and
another
thing
is
the
mec,
so
this
one
is
to
basically
leverage
coverage
in
the
leveraging
mvc
platform
development
with
the
keyboard
inside
and
another
thing
the
discussion
is
about
is
the
aic.
This
thing
is
trying
to
provide
better
fundamental
functionality
for
the
ai
workloads,
coordinating
between
cloud
and
age
like
federated
learning,
and
also
the
the
incremental
trending
incremental
inferencing.
A
A
So
basically,
this
one
is
trying
to
expose
more
telco
capabilities
to
the
container
network
or
to
the
to
the
service
level,
so
make
the
applications
able
to
benefit
more
from
the
underlying
network
information
locations
and
also
the
security,
functionalities,
etc,
and
also
for
the
mec
infrastructure.
So
this
one
is
actually
basically
trying
to
support
various
hardware
acceleration
and
also
the
multi-mec
and
the
multi-kinesis
cluster
management,
and
there's
also
to
support
various
kind
of
workloads
on
the
age
so
like,
for
example,
the
updf.
A
A
So
actually,
we
are
borrowing
a
lot
of
concepts
already
defined
by
the
gsma
operator
platform,
so,
for
example,
the
northbound
interface
and
also
the
the
user
network
interface,
and
also
the
east,
west,
east,
west
broadcasting,
east
west
boundary
interface
and
also
the
southbound
interface.
So
basically,
it's
it's
defining
how
the
the
services
and
the
components
to
how
they
communicate
with
the
other
part.
A
So
the
blue
boxes
are
components
that
will
be
provided
by
qh.
So
actually
you
will
find
out.
There
are
some
of
the
boxes
new
to
the
curbage
architecture,
so
cubah
would
basically
focus
on
the
following
features
like,
for
example,
the
cross-age
cloud
service
discovery
and
also
the
nearby
access
that
basically
means
the
making
it
possible
for
the
application
to
know
the
network
location
of
itself
and
better
serve
the
the
end
user
terminals.
A
So
the
so
the
end
user
terminal
they
can
get
access
to
the
to
a
nearby
application
and
also
the
when
any
cross
application
cross
container
communication
happens.
It
will
try
to
deal
with
the
network
locality
to
save
the
to
save
the
global
network
bandwidth
and
also
the
srm
based
on
5g
network
events
and
and
the
service
discovery.
A
A
So
the
c
device
iot
is
responsible
to
simplify
and
develop
and
maintain
the
extensible
device
protocol
framework
and
also
in
the
qh
community.
We
will
provide
some
of
the
the
device
protocol
converter,
implementations
and
also
make
it
make
it
very
easy
for
the
other
developers
to
develop
their
own
device
protocol
converters
to
integrate
to
qh.
A
So
some
of
the
items
here
are
the
common
api
obstruction,
basically
the
device
model
and
the
device
instance
apis,
and
also
the
the
device
controller
device
training
device
mapper
framework.
That's
we
need
to
keep
improving
the
extensibility,
make
it
much
more
easier
for
the
lt
cases.
So
the
first
thing
we
want
to
include
more
integrate
more
and
more
diverse
protocols.
A
Second
thing:
we
want
to
include
more
integrate
more
functionalities,
like
data
pipeline
data
workflow
on
the
age,
to
to
make
user
able
to
specify
some
of
the
hardware
filter
software
filter,
to
reduce
or
convert
from
raw
data
to
meaningful
data
and
then
send
forward
to
the
business
applications,
and
another
thing
is
about
the
data
management,
so
we
know
that
the
devices
are
producing
a
lot
of
especially
the
time
stereo
data.
So
even
it's
very
expensive
to
to
send
all
of
them
to
the
central
cloud.
A
A
So
a
few.
Some
of
the
recent
work
done
by
device
iotc
are
the
improvements
of
device
api,
so
we
basically
simplify
the
the
definition
of
adding
a
specific
customized
industrial
protocol
and
also
added
new
fields.
Collapsed
life
cycle
cloud
collect
the
cycle
and
the
report
cycle
for
different
property
visitors.
A
A
A
So
basically
we
we
added
the
kubernetes
style
api
to
to
simplify
the
component
configuration
and
also
added
the
two
commands
to
generate
config
with
different
values
and
for
the
node
notice
that
we
basically
deal
with
the
automation
of
the
registration
and
the
trs
enforcement,
and
also
the
certificate
rotation
and
for
the
installer,
the
key
enemy
we
added
support
with
central
west,
raspberry
and
also
debian,
and
this
year
we
added
the
hi
support
of
cloud
core.
It's
active
standby
mode,
but
actually
it
can
serve.
A
One
cloud
core
active
cloud,
for
instance,
can
support
one
thousand
notes,
so
the
community,
currently
under
design
and
discussion
to
design
the
scale
out
model
for
the
cloud
core
and
also
we
improved
the
the
message-
delivery,
reliability
between
cloud
and
age.
So,
basically,
I
introduce
the
application
layer
access
the
verification
to
make
sure
the
there's,
no
message
lost
when
communicating
between
cloud
and
age
so
runtime
and
the
observability
updates.
We
this
year
we
finished
the.
A
We
actually
supported
more
almost
already
the
mainframe
oci
confirmation
on
time,
including
cryo
cut
cutoff
we
supported
last
year
and
both
x86
and
arm
architecture,
including
armv,
v7
and
v8,
are
verified
and
for
their
observability.
We
added
support
to
use
two
color
locks
to
fetch
logs
from
pods
on
the
age
and
also
added
support
to
to
use
metric
server
to
collect
the
magic
metrics
from
nodes
in
the
both
in
the
cloud
and
under
the
age,
and
also
in
1.5.
A
We
added
support
of
using
kubecon
exec
to
access
a
port
on
the
edge
from
the
from
the
cloud
from
the
api
server
in
the
cloud,
so
that's
very
useful
for
the
application
developers
to
to
debug
their
applications
on
the
old
on
the
agent
while
not
going
to
the
to
the
actual
place
of
the
server
there.
So
for
the
use
case,
I
will
just
share
one,
the
largest
so
in
the
china
highway.
The
previous
totaling
mechanism
is
actually
by
manual.
A
So
in
the
end,
the
benefits
are
improved.
The
traffic
efficiency
with
10
times
more
so
for
the
cars
going
through
the
tow
tow
station,
it's
down
from
optimize
the
down
from
15
seconds
to
10
and
also
the
time
constitution
of
truck,
also
improved
a
lot.
The
highlights
here
are:
they
achieved
a
very
low
end-to-end
latency,
because
it's
very
distributed
system
all
over
the
tow
stations
in
different
cities
of
china,
it's
very
highly
distributed,
so
the
the
whole
system.
A
Currently,
there
are
100
000
age
nodes
and
around
one
million
applications,
so
with
kubernetes
and
the
qh
the
the
operating
team,
they
are
benefiting
from
the
unified
management
experience
and
can
upgrade
or
scale
out
the
applications
on
the
age
in
a
very
easy
way,
and
also
on
top
of
the
infrastructure.
We
mapped
added
the
support
in
the
application
layer
to
map
the
hierarchy,
management
to
the
different
departments
of
the
traffic
controlling
and
the
traffic
management.
A
So
from
the
community-wide,
we
will
try
to
provide
better
contributor
experience
and
also
host
more
contributing
events
and
also
more
cross-community
collaboration
all
right.
These
are
a
few
useful
community
resources,
so
we
have
a
website
and
the
most
of
the
work
actually
are
done
on
github
and
slack.
A
So,
if
you
have
any
questions,
we
welcome
you
to
open
an
issue
on
the
github
or
just
a
send
message
in
the
select
channel.
We
also
have
the
the
mec
and
the
device
iotc
channel
link
here.
If
you
are
interested
in
the
the
works
they
are
working
on,
please
feel
free
to
join
and
we
currently
are
hosting
the
community
meeting
every
week
alternate
between
europe
friendly
time
and
the
pacific
friendly
time.
A
You
can
check
out
with
the
check
out
the
details
with
the
meeting
calendar
and
also
we
are
recently
working
on
the
community
documentation
to
support
multiple
releases
and
also
multiple
languages.
If
you
are
interested
in
improving
the
document,
please
feel
free
to
join
all
right.
Let's
worry
about
the
presentation,
so,
if
you
have
any
questions,
please
feel
free
to
ask
in
the
zoom
meeting
or
join
the
cubed
community
to
ask
questions
there.
Thank
you.