►
From YouTube: Intro to KubeEdge: Kubernetes Native Edge Computing Framework - Kevin Wang (Zefeng) & Yin Ding
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Intro to KubeEdge: Kubernetes Native Edge Computing Framework - Kevin Wang (Zefeng), Huawei & Yin Ding, Pure Storage
KubeEdge is an open source edge computing framework that extends the power of kubernetes from central cloud to edge. Since moved to incubation level, KubeEdge made big progress on user adoption, community development, cross-community collaborations. In this talk, Kevin and Yin will review KubeEdge motivation, architecture; then go through latest updates on new features, user adoptions, SIG updates and new subprojects. After that Kevin and Yin will introduce where the project is heading to, updated project roadmap and how new contributors to get involved. There will be an open Q&A for attendees to ask questions.
A
B
B
So,
first
we
are
going
to
talk
about
why
we
need
edge
cloud
computing.
First,
it's
a
low
latency
because
normally
the
edge
is
on
the
remote
side
and
the
tr,
the
latency
back
to
the
cloud
will
be
high.
That's
why
we
want
a
solution
that
application
running
on
the
edge
side
to
reduce
this
latency
and
also
because,
especially
with
lte
edge,
a
lot
of
led
data
will
generate
it
on
the
edge
side.
B
If
we
want
to
migrate
all
this
raw
data
back
to
the
cloud
will
be
a
really
high
cost
and
during
our
balance
to
save
the
bandwidth,
we
want
to
generate
a
solution
running
on
the
edge
and
also
we
are
really
concerned
of
this
privacy
and
security.
A
lot
of
outside.
We
are
running
using
the
data
generated
on
the
other
side.
It's
including
the
personal
data
business
data.
B
That's
why
we
want
to
pre-processing
and
mask
some
data,
especially
sensible
data
on
the
edge
to
protect
the
production
and
business
security,
the
last
and
not
the
least,
we're
talking
about
the
local
autonomy
so
because
the
edge
the
naturally
will
run
on
the
remote
the
intel.
The
connection
through
internet
could
be,
I
mean,
interrupt
in
the
middle,
so
we
need
a
offline
solution
for
the
edge
side
and
make
it
a
self
recovery.
When
the
connection
restored.
B
B
It's
graduated
from
the
sandbox
into
a
sincere
incubation
in
september
2020
for
now,
since
the
release
since
the
launch.
Until
now,
we
already
got
more
more
than
five
thousand
five,
four
thousand
five
hundred
stars
on
github
and
one
thousand
three
hundred
forks
on
github
and
this,
including
more
than
800
contributors
more
than
220
code
custom
meters.
All
these
people
are
from
more
than
60
thousand
organizations
within
our
community.
We
already
set
up
a
d6
sig
ai
sig
device,
iot
seek
mac,
focusing
on
tele
communication
telecoms,
and
we
have
a
work
group
wireless.
B
B
B
Now
we
are
talking
about
why
we
pick
communities
at
our
platform
to
build
on
and
then
the
challenge
we
met
the
benefit.
So
if
we
want
to
use
a
canalized
application,
it
will
be
easily
migrated
and
build
once
run
anywhere.
It's
already
recognized
by
the
industry
and
based
on
the
kubernetes
there's
already
the
cycle
standard
kubernetes
for
the
container
optimization
observation
platform.
B
So
if
we
build
on
kubernetes,
the
developer
will
have
the
same
experience
across
cloud
and
edge.
They
will
have
the
same
experience
and
this
to
developer
the
application
and
also
kubernetes,
have
this
extendable
architecture
for
us
to
easily
extend
the
apis
to
build
on
kubernetes.
Of
course,
we
have
these
challenges.
B
It
may
not
be
enough
to
kubernetes
component
to
run
on,
for
example,
kubelet,
cooper,
proxy
and
other
components,
and
we
already
talked
about
unstable
network.
The
connection
between
the
cloud
and
the
edge
through
the
internet
may
not
be
stable,
so
it's
different
from
the
network
running
in
the
data
center.
Also,
the
bandwidth
will
be
limited.
Latency
will
be
high.
That
will
be
hard
problem
for
us
to
conquer
and
also
we
need
autonomy
at
the
edge
because
of
this
unstable
network.
B
B
A
All
right
so
for
qubit
you
actually
to
resolve
the
challenges
we
observed
in
in
the
last
slides.
We
are
actually
choosing
the
remote
node
architecture.
So
basically,
we
are
putting
the
node
component
on
the
edge,
because
that's
much
easier
to
optimize
for
the
resource,
control,
constraint
devices
and
also
actually
the
component.
The
age
core
running
running
on
the
agenda
is
just
the
only
one
component.
A
A
We
did
a
lot
of
verification
and
test
that
it's
very
stable
and
can
work
on
very
low
network,
including
high
package
lost
weights
and
the
low
the
high
latency
network,
and
also
quick,
is
introduced
as
an
alternative
online
protocol
to
provide
the
support
for
from
corner
cases,
and
we
are
expecting
some
performance
improvement
in
the
longer
future
to
simplify
the
device
management
management
on
the
age.
Actually,
cuba
age
provided
a
framework
to
decouple
the
application,
application
development
and
the
device
protocols
so
mappers.
A
B
A
A
Okay,
so
let
me
just
first
introduce
a
little
bit
more
details
about
how
cuba
to
run
applications
onto
the
agent
nodes
so
as
we
know
that
in
vanilla,
kubernetes
after
a
scheduled,
scheduler
made
decision
for
each
part
to
find
a
node,
the
pivot
on
the
corresponding
node
will
spin
up
the
the
containers
of
that
part
while
in
cuba
age.
Actually,
the
protocol
will
get
all
the
watch.
A
Events
of
the
pod
and
the
notes
that
should
be
running
on
the
age
and
then
send
sending
through
the
channel
between
cloud
and
h
to
the
right
age,
node
and
the
meter
manager
on
the
agent
node
will
persistent
the
the
pod
information
on
to
the
into
the
local
lightweight
database,
which
is
a
circular
light
and
then
forward.
The
information
to
the
hd,
which
is
a
lightweight
dublin
and
the
rest,
are
of
the
same
process
comparing
to
a
standard
equivalent.
A
B
A
Other
components
talk
to
each
agent
nodes,
even
though
they
are
located
in
the
private
network,
and
the
each
controller
is
focusing
on
the
shadow
management
for
the
the
guides
of
humanities.
Actually,
the
the
the
nucleus
guys,
including
the
nodes,
arts,
config
and
config
maps
and
the
secrets,
etc,
and
also
the
device
controller,
is
rely
responsible
for
providing
the
device.
A
A
A
Which
is
a
symmetric
implementation
of
cloudhub?
The
meter
manager
is
one
of
the
most
important
parts
inside
the
cloud
core
which
focuses
on
managing
the
node
level,
metadata
consistency
and
also
provide
the
lightweight
kubernetes
api
servers
for
all
the
applications,
especially
operators
that
are
running
on
page.
A
That
means
that
all
the
operators
and
the
applications
on
the
hr
they
are
they're
actually
getting
data
from
the
local
database,
which
less
reliability
on
the
communication
and
the
network
between
cloud
and
age
and
the
hdd
is
a
lightweight
cubelet.
We
removed
some
legacy
and
redundant
implementation
of
vanilla
cumulative
and
the
device
string
is
to
deal
with
device
status
synchronization
between
cloud
and
age.
So
for
the
overall,
it
takes
down
to
70
megabytes
memory
footprint,
which
is
quite
lightweight
you.
Can
you
are
able
to
run
on
around
the
whole
setup
on
age.
B
A
We
decoupled
the
implementation
from
the
main
repo
into
a
separated
repo
too,
to
make
it
more
focused
on
providing
the
the
data
plan,
the
network
functionalities
to
so
with
the
new
edge
mesh.
You
are
now
able
to
enable
the
applications
in
different
subnet
talk
with
each
other
using
kubernetes
service
mechanism.
Where
were
relying
on
the
on
the
cluster
iep
the
underlying
network,
they
will
automatically
rely
on
the
label
p2p
to
build
the
connections
across
different
private
network
to
make
sure
every
product
can
on
each
other.
A
Okay
for
the
six
and
seven
projects,
the
cgi
is
recently
focusing
on
the
seminar
project
development.
We
got
to
a
new
release
published
since
we
last
met
and
the
cgmec,
and
also
the
wireless
working
group
they
are
currently
focusing
on.
The
reference
architecture,
rely
relevant
to
the
alcohols
and
also
especially,
some
weak
network
situation
with
the
node
keep
changing
the
location
and
also
the
the
the
device
iot
say.
A
We
are
under
discussion
about
the
sticky
charter
to
clarify
what
to
do
and
also
to
indicate
where
we
are
and
yeah
and
the
sub
project
stedena
and
mesh.
We
already
covered
okay,
so
just
some
basic
information
about
the
sedna
project,
so
this
project
is
actually
kind
of
an
ai
toolkit
of
cuba,
age
to
provide
the
age
cloud,
collaboration
and
age
cloud
synergy
mechanism
for
ai
workloads.
A
We
know
that
the
resources
on
the
age
today
are
still
very
limited,
so
we,
while
we
have
rich
services
and
reach
hush
rates,
the
complaining
power
in
the
cloud.
So
when
don't
we,
we,
when
we
are
not
satisfied
with
influencing
accuracy
on
the
atv
and
with
the
sedina
project,
we
can
easily
fall
back
to
the
cloud
to
achieve
the
joint,
influencing
or
for
your
day-to-day
ai
workload
and
also
it's.
It
helps
simplify
the
incremental
learning
in
your
day-to-day
application.
A
Running
basically
expect
any
the
samples
for
the
the
the
hard
information
and
the
trigger
they
called
the
training
and
they
update
the
models
on
each
and
also
in
the
recent
two
releases.
We
introduced
the
live,
long
learning
model
to
to
extend
the
data,
the
sample
collection
and
also
the
model
training
upgrade
iteration,
and
also
we
enhance
the
federation
of
federated
learning
to
support
more
scenarios.
A
For
the
robotic
sig,
currently
we
are
still
under
discussion,
but
basically
we
want
to
focus
on
the
api
definition
and
the
reference
architecture,
as
well
as
implementation
relevant
to
robotics
ecosystem
to
achieve
the
age
cloud,
collaborate,
collaborative
architecture
or
robot
cloud
collaborative
architecture.
So
the
at
the
very
beginning.
We
may
focus
on
containerizing
the
some
of
the
softwares,
including
the
ios
and
the
engageable,
and
also
you
are
more
than
welcome
to
join
the
discussion
and
leave
your
comments
to
this
secret
partner.
A
Okay,
so
for
the
use
case,
I
just
want
to
update
one
of
the
adoption
that
we
are
used
on
the
world's
longest
process
c
bridge.
So
it's
a
c.
It's
actually
a
bridge
internal
system
with
a
very
low
network
quality.
They
don't
have
cables,
though
so
so
everything
needs
to
be.
Every
communication
needs
to
be
done
with
each
the
the
network
or
the
the
4g
network.
B
A
There's
any
traffic
situation
and
also
the
environment.
We
need
to
check
to
make
sure
the
bridge
is
in
a
good
situation.
So,
with
the
device
framework,
all
the
sensors
are
employment.
The
drivers
are
implemented
as
the
us
mappers
to
to
decouple
the
underlying
us
from
tokyo
with
oblique
issues,
so
the
age
applications
they
can
just
focus
in
on.
B
A
Okay,
so
for
the
longer
term,
the
data
plan
is
definitely
very
important,
so
we
will
keep
enhancing
the
hms
project
to
provide
the
to
simplify
the
cross
cybernetic
communication
and
also
to
enhance
the
story.
Storage
integration
to
to
achieve
the
edu
age,
cloud,
collaborative
storage
experience
and
also
he
enhanced
the
more
circular
age
protection,
as
well
as
providing
the
decentralized
security
functionality
for
applications
across
the
age
and
also
device
management,
is
definitely
very
important.
A
Of
the
mapper
for
the
community,
we
will
host
more
contributor
events,
as
well
as
improving
the
critical
experience
and
for
the
collaboration
with
the
other
community.
Besides
cell
of
h,
especially
hikarino,
we
are
planning
to
integrate
to
have
more
collaboration
with
ajax
foundry,
bakery
wasa,
mage
and
lips
foundation,
all
right
so
the
so4,
that's
where
about
the
introduction
to
the
project.
A
So
nowadays
we
are
updated,
really
developing
on
on
github
and
also
we
are
relying
heavily
on
slack
to
discuss
about
the
technical
stuff.
You
are
more
than
welcome
to
join
our
community
and
please
have
a
try
on
this
project.
If
you
have
not
yet
tried
that
all
right,
that's
all
about
the
introduction.