►
From YouTube: Kubernetes WG IoT Edge 20220928
Description
September 28, 2022 meeting of the CNCF IoT Edge Working Group. Discuss edge native white paper draft.
A
Hi
welcome
to
the
September
28th
meeting
supplemental
meeting
of
the
cncf
iot
edge
working
group.
This
meeting
is
intended
to
discuss
the
draft
of
the
white
paper
that
we've
been
working
on
for
some
number
of
weeks
now
so
with
no
further
Ado.
Let's
get
started
a
few
of
a
few
people.
Lamar
and
Dion
have
had
quite
a
few
edits
comments,
new
material
added
to
the
document.
So
does
one
of
you
want
to
go
first.
B
A
C
Okay,
so
most
of
my
edits
were
restructuring.
I
did
have
a
couple
of
sort
of
content,
questions
and
I'll
go
through
them,
so
the
first
one
I
I
thought
was
Edge.
Computing
is
a
paradigm
which
brings
data
processing
closer
to
the
source,
for
example
sensors
in
vehicles.
So
I
had
two
points
on
this
one.
One
is
data.
Processing
closer
to
the
source
has
been
there
since
you
know
ever
since
Computing
has
been
there.
C
So
do
we
need
to
add
additional
qualification
like,
for
example,
by
utilizing
cloud
computing
like
automation,
Etc,
something
that
qualifies
it
a
little
bit
more
than
just
saying,
data
processing
closer
to
the
source
and
the
second
one
I
thought
is
we
we
had
explicitly
sort
of
in
terms
of
scope.
We
had
said
we
are
not
going
to
the
sensors.
C
D
D
Yeah
I
think
that's
fine,
I
think.
The
reason
why
I
also
think
sensors
and
vehicles
is
fine
is
because
we
agreed
that
sensors
isn't
in
scope,
but
the
the
compute
that's
using
the
sensors
is
so
in
this
case
the
vehicle
to
me
would
be
the
compute.
So
whatever
nodes
or
servers
you
have
in
the
vehicle,
but
I
agree
that
that
might
not
be
clear
to
the
reader
and
so
using
while
Radiology
Imaging.
D
A
The
the
only
thing
I
have
with
Radiology
is
I
think
in
I've
I've
certainly
heard
of
cases
where
those
because
you
don't
need
that
low
latency
response
to
the
Radiology.
Unless
it's
a
situ
there
are
some
where
the
Radiology
is
being
a
lot
used,
live
during
surgery
to
guide.
You
know
some
instrument,
that's
being
directed
down
a
blood
vessel,
but
I
think
many
instances
of
radiology.
You
know
like
looking
for
cancer
from
static
images
by
no
means
have
that
latency
dependency,
so
they're,
often
collected
and
processed
in
batch.
C
A
C
A
Yeah
and
let
somebody
have
something
better-
I
mean
the
argument
against
would
be
that
you
know.
Hadoop
was
sort
of
the
same
thing
that
really
had
nothing
to
do
with
Edge.
Well,
you
could
use
Hadoop
in
an
edge
situation,
I
suppose,
but
I
can't
come
up
with
anything
better,
at
least
in
the
short
term.
If
I
had
an
hour
more
to
think
about
it,
maybe
I
could
but
I
don't
have
the
hour.
D
E
A
Think
what
we
have
to
go
with
here
is
to
use
an
analogy,
there's
cloud
and
then
Cloud
native,
so
Cloud
was
the
cloud
you
know
was
a
noun
of
compute
resource.
That
was
a
useful
tool
and
Cloud
native
was
structure
around
how
to
use
that
effectively
efficiency
efficiently,
with
best
practices
and
map
running
workloads
onto
the
cloud
resource,
so
I
think
Edge
native
is
about
the
big
picture
of
not
just
you
know
some
physical
compute
resource,
but
Edge
native
are
these
principles
of
how
you
best
utilize
them
best
design
them.
B
E
C
I
mean
I
Point
as
well.
I
mean
I'm,
okay
leaving
it
because
it
might
be
too
much
of
a
nuanced
point.
But
just
because
you
have
data,
processing
closer
to
the
source
doesn't
make
it
Edge
Computing
right.
We've
we've
had
data
processing
closer
to
the
source
since
the
80s,
but
the
ads
architecture,
90s
architecture
would
not
be
called
Edge
Computing,
it
just
just
be
called
on-prem
computing.
C
A
Yeah,
if
you
wanted
to
say
Source
I,
think
if
you
wanted
to
embellish
it
because
you're
right,
it's,
there
are
things
that
aren't
Edge
that
would
fit
under
that
definition.
But
it's
the
source
of
what
and
the
what
I
would
contend
is
events
and
original
data
generation.
You
know
Hadoop
often
is
going
to
process
as
a
batch
data
that
was
collected
and
moved
from
elsewhere.
A
Yet
the
compute
is
near
where
the
data
is
now
but
Edge
is
about
moving
the
data
processing
close
to
the
original
point
of
origin
for
data,
and
it
isn't
just
data,
but
I
would
contend
events
because
in
something
like
that
robotic
control.
You
know
there
are
Edge
triggers
or
events
that
are
they're
hard
to
characterize
as
data
other
than
the
fact
that
some
some
event
happened
and
it
was
detected.
C
So
I
was
thinking
slightly
differently.
In
my
mind,
Edge
Computing
is
data
processing
closer
to
the
source
using
cloud
computing
like
principles,
so
I
had
sort
of
assumed.
Look
in
my
mind
that,
because
you
do
have
I,
don't
know
what
are
those
things
called
as
there's
a
lot
of
compute
that's
closer
to
the
source,
but
we
wouldn't
call
it
Edge
Computing
I
mean
I'm
sure
factories
have
all
kinds
of
pneumatic
machines
and
what
are
those
I
forget?
What
they're
called
computer
driven
machines
and
things
like
that?
But.
A
Would
not
you
even
have
things
the
world
is
moving
to
smarter
cameras
that
maybe
have
image
classification
that
has
literally
moved
into
the
camera
itself.
Right
I
would
still
actually
call
that
edge
Computing
now
it
might
not
be
Edge
Computing
in
the
sense
that
the
cncf
is
going
to
be
able
to
wrap
around
a
large
amount
of
infrastructure
on
that,
but
I
I
think
that
that
actually
is
Edge
Computing.
It's
just
sort
of
edge
computing
packaged
into
modules,
so
that
you're
running
it
on
a
different
tier.
A
C
C
The
rest
is
a
lot
of
language.
Cleanup
I
mean
I,
won't
go
through
it,
I
think
people
can
just
go
through
it
yeah.
Some
word
I
think
this
someone
who
meant
Downstream
not
Upstream,
because
Upstream
is
showed
up
two
times
and
instead
of
enable
that
or
uninterrupted
might
be
better,
so
maybe
I
mean
we
don't
need
to
do
this
here
right
people
can
do
it
offline,
just
language,
edits
and
minor
tweaks
I.
D
D
A
E
C
E
C
Actually,
it
has
two
purposes
right,
so
when
you
have,
if
you're
in
a
stadium-
and
you
have
that's
a
very
common-
or
it
was
a
very
popular
Edge
Computing
use
case
two
three
years
ago
and
you
have
hundreds
of
cameras,
then
you
have
tremendous
Downstream
bandwidth
which
cannot
be
served
from
the
cloud.
So
therefore,
you
needed
Edge
Computing
to
aggregate
all
these
camera
streams,
and
then
viewers
in
the
stadium
could
choose
any
camera
angle,
so
they
could
like.
C
If
there's
a
soccer
goal
penalty
being
gold,
they
could
like
watch
it
from
the
from
the
Striker's
point
of
view.
So
they
were
all.
So
that's
one
bandwidth
use
case.
The
other
one
is
reducing
Upstream
bandwidth
so
again,
a
very
popular
so,
for
example,
the
Radiology
one
which
which
we
removed,
but
it's
it's
also
a
popular
example
for
Edge
Computing,
because
you'd
have
to
send
I
forget
how
many
petabytes,
but
per
Hospital
you'd,
have
to
send
X
number
of
petabytes
per
day.
C
If
you
wanted
to
process
that
radiology
information
in
the
cloud
so
reducing
and
same
thing
with
video
surveillance
camera,
you
want
to
process
that
machine
learning,
inferencing
on
the
on
premise
and
the
factory
or
whatever
so
I
think
yeah,
I,
think
I.
Think
it's
okay
I
think
it
is
relevant
for
Edge,
Computing
and.
A
C
A
C
D
D
D
Yeah
I
think
it
would
add,
maybe
a
sentence
but
kind
of
provide
more
context
that
hasn't
been
provided
elsewhere,
like
I
think
when
you
mention
that
Steve
a
while
ago,
it
was
quite
helpful
to
me
personally
to
understand
that
those
are
three
kind
of
lenses
that
we've
seen
and
I
haven't
seen.
Another
paper
cite
the
three
lenses.
A
A
E
E
C
D
E
A
E
E
A
E
Yeah,
so
yeah
so
actually
I
have
the.
We
have
the
use
case
that
using
kubernetes
you
know
like
we
want
to
deploy
the
application
based
on
the
location,
so
I
think
it
should
be
at
the
moment,
I
I
was
thinking.
You
know,
like
the
location.
Data
should
be
taken
care
of
by
kubernetes
and
really
broad
application
once
the
location
did
changes.
So
that
was
a
use
case.
So
yeah,
okay,.
C
C
A
A
C
E
A
A
E
C
C
B
E
B
C
B
C
C
A
Well,
I
think
that
stateful
call
out
is
that
in
you
know,
the
traditional
public
Cloud
hosted.
You
had
horizontal
scale
out
with
a
lower
tier
like
a
database
or
something
yeah
used
by
a
bunch
of
stateless,
horizontal
components.
But
when
you
go
to
Edge
first
of
all,
if
you
don't
have
a
cluster
scaling
horizontally,
maybe
isn't
even
an
option
anymore,
and
once
you
remove
that
horizontal
scale
out
often
you'll
see
that
people
just
combine
the
state.
You
know
if
you
don't
have
cluster
nodes
and
you
just
have
one.
A
It
can
be
a
simpler
architecture
to
just
go
put
the
state
in
the
one
thing
that
uses
that
state,
rather
than
break
it
into
two
independent
pieces.
So
you
tend
to
see
more
common
use
of
stateful
apps
I
would
contend
at
Edge
locations
that
are
well
monolithic,
so
I
think
I,
probably
wrote
this
cell,
but
that.
C
A
Yeah
I
think
it's
it's
a
situation
this.
This
gets
pretty
wordy
for
putting
in
a
box
of
a
cell,
but
you
you
can't
as
easily
Outsource
the
state
and
you
know
make
it
somebody
else's
problem
or
the
service
provider's
problem.
You
kind
of
have
to
own
it
and
worry
about
deploying
stateful
apps
more
at
Edge
than
you
do
in
public
cloud.
E
E
C
C
A
E
E
A
Yeah
I
don't
know
if
we
need
to
put
it
in
this
cell
I
think
that,
in
terms
of
okay,
you
know
if
you
had
an
edge
with
a
bunch
of
leaf
nodes.
My
observation
is
I.
Haven't
come
across
that
many
use
cases
where
they
actually
attempt
to
scale
to
another
Leaf
node,
as
opposed
to
going
up
to
a
higher
tier
yeah.
E
Yeah
I
want
to
start
and
Stephen
I'm,
not
talking
and
Edge
has
lots
of
beliefs.
I'm
saying
you
might
have
a
lot
of
edge
things
that
are
geographically
distributed
in.
If
that
makes
sense
like
more
zones,
okay,
you
might
hey.
I
might
have
a
thousand
sensor
sensors
that
are
distributed
as
an
example,
as
opposed
to
it's
not
like
it's
an
edge
site
that
has
lots
of
leaves
I
just
have
way
more
sites.
A
Well,
one
thing
we
didn't
call
out
that
I
I
would
agree,
probably
is
an
issue,
but
it
I
don't
think
it's
in
any
cells.
Right
now
is
that
I
think
the
scale
is
potentially
bigger.
You
know,
if
you
look
at
kubernetes,
it
really
has
an
architecture
that
is
capped
at
about
5
000
nodes,
but
pretty
clearly
there
are
Edge
deployments
that
are
way
above
5000
Edge
nodes,
and
that
is
a
difference
and
it
isn't
covered
by
anything
currently
in
this
cell.
A
But
I,
don't
know
that
they're,
you
know
if
we
wanted
to
follow
up
on
the
difference
in
that
table
on
what
the
recommendation
or
tool
set
is
to
do
with
that
there
maybe
aren't
even
any
great
Solutions
out
there
yet
to
to
manage
that
higher
scale.
But
if
you,
what
you
want
to
call
out
is
that
the
order
of
magnitude
of
scale
is
different
at
Edge.
A
A
E
D
A
E
C
C
C
A
A
So
things
tends
to
stay
more
consistent,
you're
only
dealing
with
you
know
a
three
to
five
year
span
of
Hardware
life
cycle
stuff
out
there,
but
when
you
get
to
Edge
people,
still
it's
an
anomaly,
but
there's
people
using
20
year
old,
stuff
and
10
year
old
stuff,
isn't
uncommon
and
it
creates
all
kinds
of
variances
in
what
the
underlying
compute
looks
like.
In
terms
of
you
know,
generations
of
gpus
or
total
lack
of
gpus
support
for
it.
Aes
encryption
and
things
in
the
hardware.
I,
don't
know
it
I.
D
Focusing
on
Hardware
here
is
a
good
move,
because
I
think
that
is
something
that
is
really
unique
to
the
edge
is
that
the
hardware
is
heterogeneous,
while
the
cloud
is
standardized
homogeneous
extracted
from
the
user,
The
Edge
is
varied
olds
and
you
have
to
be
more
familiar
with
it
and
I
think
that
is
something
to
call
out.
Even
if
the
state,
the
application
developer,
is
not
use.
Usually
that
aware
of
what
hard
or
needs
to
be
that
aware
of
the
hardware
they're
using
that
might
be.
It
is
something
more
unique
to
the
edge.
A
Now
the
caveat
I'll
say
here
is
people
who
read
Hardware
awareness.
Maybe
this
isn't
a
bad
thing,
but
I
think
they'll
often
walk
into
the
scenario
of
what
the
attached
Hardware
I
o
is.
You
know,
in
other
words,
that's
another
reason
for
Hardware
awareness
in
that
some
of
these
edge
things
have
dedicated
interfaces
to
particular
I
o
sensors,
and
what
have
you
that
you
don't
commonly
find
in
a
public
Cloud
yeah.
A
D
E
D
B
D
E
C
E
A
A
C
C
C
A
C
C
A
couple
of
the
projects
we
are
working
on
Emco
and
nephew:
there's
this
concept
of
pull
mechanism
where
the
edge
is
pulling
configuration
as
opposed
to
a
centralized
site,
pushing
configuration
foreign
and
that's
helps
with
scale,
but
it
also
helps
with
network
connectivity
issues.
So
if
you,
if
the
edge
is
pulling,
then
whenever
the
network
is
available,
it
can
pull
it.
So
I
wasn't
sure
it
goes
here,
but.
A
I,
don't
think
we
need
to
make
any
bigger,
but
I
I've
heard
people
who
have
the
attitude
too.
That
Paul
is
actually
even
a
security
attribute.
Yes,
you
can
more
safely
do
a
poll
than
a
you
know.
If
you,
if
something
from
outside
could
push,
maybe
Hackers
from
outside
can
push
too.
So
you
might
sleep
better
at
night
with
a
pull
mechanism,
but
I
don't
I'm
not
contending.
We
need
to
make
this
any
bigger.
C
D
D
C
E
A
C
B
Ahead,
I
I
don't
have
much
it's
just
that
I
tried
so
Amar
put
it
in
in
the
in
the
row
in
the
table.
It
was
a
paragraph
down
there,
so
what
I
try
to
do
is
basically
to
sum
up
the
discussions
we
had
last
week
about
interacting
with
the
external
resources
and
devices,
so
maybe
the
good
until
the
next
meeting,
if
you
guys,
you
know,
can
go
through
it
review,
it
maybe
put
some
comments
and
we
can
discuss
both
offline
and
and
then
in
person.
Next
week,
okay,.
D
B
A
Yeah
some
of
this
I
mean
we
need
material
on
the
external
device
connectivity,
but
I
see
here
like
that.
First
bullet,
one
of
the
goals
of
edge
Computing,
is
to
bring
compute
closer
to
the
source
of
data.
I
think
we
covered
that
already
way
at
the
top.
So
some
of
this
material
looks
outside
the
scope
of
device
connectivity
to
me,
but
yeah
offline,
I
I
can
take
some
time
going
over
this
and.
B
A
D
Yeah,
so
on
that
note
we're
over,
but
I
think
it
might
be
nice
to
like
delegate.
Are
we
only
going
to
be
writing
paragraphs
about
the
principles
since
this
is
that
paper
and
if
so,
do
we
want
to
just
divide
up
who's
writing
what
paragraph
so
like?
Clearly,
Dan's!
Writing
the
external
device
connectivity
paragraph,
but
do
we
want
to
each
take
a
paragraph
and
before
the
next
meeting,
just
put
a
paragraph
down
about
it
or
elaborate.
A
E
A
A
Okay,
well,
I
think
we
made
good
progress
at
three
minutes
after
the
hour,
so
let's
call
this
week's
meeting
to
a
close
and
but
we're
giving
the
presentation
at
kubecon,
which
is
now
less
well
about
a
month
away.
So
we've
got
to
keep
moving
forward
to
be
ready
in
time,
because
somehow
the
paper
has
to
be
done
and
then
a
deck
composed
about
it
too.
So
thanks
everybody
for
showing
up
I
think
we're
we're
moving
forward,
but
we
need
to
keep
up
the
pace
and
we'll
see
a
meeting
next
week.
Bye.