►
From YouTube: Kubernetes WG IoT Edge 20220831
Description
August 31, 2022 meeting of the CNCF IoT Edge Working Group. Special meeting outside normal schedule to work on the edge native white paper draft.
A
Hi
welcome
to
the
supplemental
meeting
of
the
cncf
iot
edge
working
group
called
for
the
purposes
of
doing
group.
Preparation
of
this
Edge
native
white
paper
looks
like
we've
got
five
attendees
today,
I
put
a
link
to
that
white
paper
in
the
chat.
I
took
a
brief
look
at
it.
Just
in
the
last
30
seconds,
it
looks
like
there
have
been
a
number
of
edits
and
a
number
of
comments
that
got
resolved.
So
that's
good.
It
looks
like
we're
moving
forward.
A
Otherwise,
I
propose
that
what
we
do
is
what
seemed
to
work
last
time
of
just
opening
the
dock
scrolling
on
through
looking
at
the
comments
and
chatting
people's
thoughts
on
the
comments
as
we
go
along.
Try
to
close
them
out
during
the
meeting
I
could
open
that.
But
if
anybody
else
wants
to
do
it,
that's
fine
I,
I,
don't
know
if
I
personally
touched
it
that
much
in
the
last
few
days.
A
B
A
B
A
B
Yeah,
so
so
those
are
the
the
differences
between
I,
think
Edge
native
and
the
cloud
native,
and
it
was
open.
What
do
we
mean
by
by
the
context
information?
So,
from
my
point
of
view,
the
the
services
and
applications
running
in
the
cloud
really
do
need
to
interact
with
the
local
environment
in
the
harbor.
A
Foreign
I
agree
that
it
is
a
it
is
a
critical
difference
and
we
should
call
it
out
I'm.
The
one
comment
I'd
have
on
this
other
than
just
take
it,
as
is,
is
I'm
wondering
context
information
when
I
first
read
that
I
wasn't
clear
what
it
meant
and
maybe,
if
you
want
to
call
out
or
just
put
colon
I
O
devices
or
whatever
you
had
in
mind
for
picking
up
context,
that
would
be
a
good
thing.
A
You
know
technically
I,
guess
you
could
some
of
these
things
in
some
contexts.
People
assume
IO
devices
mean
supplemental
things
plugged
into
the
computer,
but
I
think
for
many
of
these
bespoke
Edge
devices,
they're
kind
of
built
into
the
device
itself.
So
maybe
I
O
devices
isn't
the
best
thing.
But
that
was
just
what
came
to
mind,
but
you
know
I
think
just
saying
context.
B
So
so
that's
that's
what
I
got
from
from
the
from
the
other
description
in
these
columns
and
I
I
thought
from
my
perspective
that
it's
good
to
I,
don't
know.
What's
original
author
meant
by
the
context
information,
but
this
is
what
I
got
and
I
think
it's
it's
good
to
have
it
called
out,
I
mean
it
doesn't
it
doesn't
cover
all
the
edges
cases
but
I
think
for
for
for
a
lot
of
them.
B
A
B
A
A
B
C
C
C
Cloud
native,
you,
hey,
I,
think
it
or
deploy
something
I
blow
it
away
and
start
over.
If
it's
a
service
deployed
to
the
edge
and
it's
tied
to
the
hardware,
because
I
mean
you
change,
it
configuration
wise
and
the
operation,
or
can
you
is
it
set
up
in
a
way
that
you
can
blow
it
away
and
start
over
from
an
application
perspective?
Does.
B
That
make
sense,
I
I
think
it
does
so
I
didn't
want
to
go
into
to
my
detail
here.
I
was
I
I
just
wanted
to
to
have
it
called
out
that
those
applications
usually
so
why
do
you?
Why
do
we
deploy
things
on
the
edge
instead
of
the
cloud,
so
we
can
pick
up
the
local
information
quicker.
So
so
it's
usually
something
that
a
clients
connecting
to
the
cloud
are
doing
in
a
typical
scenario.
So
now
we
have
these
workloads.
Actually
we
are
managing
it
right.
So,
from
my
perspective,
it
should
be.
B
B
Do
we
keep
it
local
or
or
is
it
you
know,
provisioned
on
the
cloud
and,
as
you
said
like,
if
you
blow
it
all
up
and
we
start
over,
can
it
be
picked
up
and-
and
you
know,
restored
in
into
some
meaningful
State
I
think
it
should
right.
So
maybe
that's
something
we
could
call
on,
not
only
you
know,
you
know,
you
know
in
a
section
dedicated
to
this
topic.
B
C
A
A
I
think
to
me
at
any
way
immutable
infrastructure
as
I
understand
it,
and
maybe
my
personal
definition
is
off
base
compared
to
others.
Is
this
idea
that
you
know
once
you
deploy
some
piece
of
quote
infrastructure
you're
never
going
to
try
to
modify
it
or
patch
it?
You
have
a
spec
for
it
and
if
you
decide
that
something
needs
changing
the
spec
changes
first
and
then
you
cause
a
complete
read
to
build
deployment
from
scratch
so
that
you
know
that
you've
got
what
you
asked
for
now.
A
C
C
D
C
A
So
my
thought
is
when
it
comes
to
immutable
infrastructure,
if
the
infrastructure
is
software-defined,
networking,
maybe
software-defined
infrastructure
in
the
sense
of
using
VMS
or
containers
or
even
software-defined
radio
that
that
actually
isn't
going
to
be
different
from
cloud
native.
In
that
you
can
still
do
immutable
infrastructure,
and
you
should
so
that
wouldn't
belong
as
a
line
item
as
a
difference.
A
It's
only
when
you
get
to
Hardware,
where
I
think
immutable
sort
of
goes
out
the
window
when
it
is
Hardware,
unless
you
you
know,
if
it
were
Hardware
immutable
to
me,
would
mean
that
if
I
need
to
change
what's
out
there
at
an
edge
location,
I
need
to
order
a
new
one
from
a
factory
get
shipped
there
and
blow
away
the
old
one,
and
maybe
there's
people
who
do
it,
but
I
I.
Guessing
that's
not
common.
B
So
maybe
sure
I
I
I,
don't
know
how
how
to
you
know
how
to
put
it
in
words.
But
but
what
we
discussed
from
the
beginning
of
of
talking
about
the
edge
and
kubernetes
is
that
those
Edge
Edge
workloads
are
usually
painted
to
specific
nodes,
having
a
specific
as
as
you're
talking
about
hard
words
or
cameras,
and
things
like
that
that
that's
also
what
akri
is
doing
right,
trying
to
find
the
nodes
with
with
proper
Hardware
resources
and
deploying
adequate
workloads
there.
So
so.
B
D
D
I
was
just
saying
if
it's
still
good,
okay,
great
I
was
just
saying
we
could
even
name
this
category
heterogeneous
resources
or
external
resources
or
I.
Don't
know
something
along
or
leap
devices
visitors
talking
about
how
resources
are
different
for
the
cloud.
Data
sense
for
resources
are
usually
embedded
in
the
servers.
They're,
often
consistent.
Well,
the
more
you
get
to
the
edge.
The
more
that
resources
is
takes
on.
A
different
idea
is
external
to
the
servers,
they're
everywhere,
they're
diverse.
A
D
B
B
A
Okay,
this
looks
good
to
me
well
by
the
way
I
don't
know
if
I
didn't
see
any
comments,
but
I
I.
If
you
want
to
scroll
up
Dion
ahead
of
this
table
of
differences,
I
did
add
the
table
of
what's
the
same,
which
is
something
we
talked
about
in
the
last
meeting.
So
hopefully
people
agree
with
that.
If
I
missed
anything,
go
ahead
and
add
it
there,
but
that
is
a
that
is
a
Delta
to
the
document
that
wasn't
in
the
last
that
wasn't
in
here.
A
I
think
the
technique
I
used
to
come
up
with
this
list
was
I,
went
at
the
original
cloud
native
definition
documents
you
know
that
were
published
in
the
cncf
charter
went
over
the
bullets
of
what
was
in
there
and
everything
that
was
in
there.
That
applies
to
Edge
native
I.
Put
is
an
entry
in
this
table,
so
I
kind
of
think
I
got
them
all,
but
if
not
anybody's
welcome
to
add
some
more
or
edit
those.
D
A
D
E
A
A
A
Yeah,
it
could
be
that
you
know
the
I,
don't
necessarily
have
an
objection.
You
know
it
was
the
other
table.
That's
calling
out
differences.
There's
no
requirement
in
my
mind
that
this
table
call
out
all
the
differences.
So
depends
what
the
intent
here
is.
If
we're
trying
to
lay
out
kind
of
a
best
practices
strategy
for
how
you
go
about
deploying
apps
at
Edge.
B
B
D
A
Yeah
it's
in
Detroit
and
even
then
I.
Don't
think
that
that
is
a
deadline
for
declaring
that
the
document
will
be
final.
At
that
point,
it's
just
that
we're
going
to
expose
the
draft
of
of
this
paper
in
the
condition
it's
in
it'll.
Basically,
an
effort
will
be
made
to
convert
this
paper
into
a
slide
deck
and
then
present
it.
But
even
then
it
will
be
presented
in
the
context
that
this
is
still
open
to
discussion
for.
D
A
A
A
But
yeah
I
think
the
key
context
there
is
that
an
application
lives
in
this
context
where
it's
spread
potentially
across
both
Geographic
domains
and
maybe
across
Network
latency
chasms,
and
it
isn't
just
the
latency
chasms,
but
probably
the
reliability
chasms
to
where,
in
a
cloud
native
application,
it's
perhaps
a
bit
less
rare
for
anterior
applications
to
lose
connectivity
to
the
different
levels.
It's
not
impossible
and
it
does
happen.
A
B
But
I
think
we
have
that
as
a
line.
Poor
I
would
just
think
in
my
mind,
spending
these
just
noting
that
that
we're
not
talking
about
applications
that
that
are
Edge
only
they
rarely
are
right.
So
so
there
is
some
control
plane
in
the
cloud
or
or
or
something
that
handles
data
in
the
cloud
as
well
right.
So
it's
it's
not
an
application
that
lives
only
on
at
the
edge
does
that
yeah.
E
A
B
A
E
A
A
B
A
I
like
spanning,
because
it's
maybe
more
open-ended,
there
might
be
some
context
yeah,
where
they're
not
so
much
geode
distributed.
As
you
know,
latency
Chasm
distributed
or
maybe
even
things
like
they're
moving
around
where
mobile
devices
might
sometimes
be
at
one
location
and
then
things
move
around
and
they
are
at
different
ones
and
they're
going
back
and
forth.
E
Yeah
I
think
spanning
gives
us
the
opportunity
to
define
a
new
term
like
the
fact
that
it
doesn't
quite
make
sense
for
us
could
allude
to
the
power
it
could
have
of
defining
Edge
applications
as
being
spanning.
What
does
that
mean
and
setting
that,
but
I
also
understand
starting
from
a
foundation,
could
probably
elude.
A
Yeah
the
one
hesitation
I
have
to
Geo
is
that
to
me,
if
you've
got
say
three
tiers
that
are
connected
by
radio
links,
they
might
actually
be
at
the
same
location.
But
when
you
go
down
to
radio
links
instead
of
hardwired
you're
facing
the
same
sort
of
issues
where
these
things
can
be
kind
of
intermittently
connected
big
latencies
living
in
different
failure
domains.
Yet
they
are
pretty
much
in
the
same
Geo
area.
A
B
A
B
A
I
gather
this
means
that
you
know
we
we're
hopeful
that
some
tech,
some
abstraction
layer
exists,
so
that
you
can
write
apps,
that
you
could
reuse
there.
Let's
say
that
I've
got
10,
000
Edge
locations
with
differences,
because
you
know,
if
you
deploy
10
000
they're,
not
going
to
go
up,
be
purchased
and
get
deployed
on
the
same
day.
If
it
took
you
three
to
five
years
to
put
out
that
campaign
to
provision
hardware
and
Edge,
probably
the
ones
you
put
out
this
year
are
different
than
the
ones
you
put
out
two
years
ago.
A
Yet
you'd
aspire
to
being
able
to
write
apps
that,
for
the
most
part,
a
component
that
would
get
laid
down
at
a
particular
Edge
location
wouldn't
have
to
get
Rewritten,
because
an
abstraction
layer
would
cover
up
some
of
those
differences
in
the
infrastructure.
The
the
difference
is
you
don't
cover
up.
Are
your
I
o
devices,
perhaps,
but
is.
E
I
think
this
principle
we
could
debate
removing,
but
I
see
it
as
being
saying
hey
their
these
applications
are
portable,
but
not
as
portable
as
Cloud
native
applications.
There
are
configuration
steps
that
you
have
with
the
edge
that
you
don't
have
with
the
cloud,
for
example,
maybe
you're
using
the
device,
plugin
interface
or
the
container
device
interface,
which
the
latter
Works
across
orchestration
systems.
E
You
have
to
configure
that
before
you
can
shift
your
application
things
like
that
that
it's
not
quite
as
portable
as
a
completely
like
that,
an
app
as
an
app
that
runs
on
the
same
Hardware
everywhere,
but
you
still
could
make
it
portable,
so
I
guess
it's
not
well
defined,
so
I
wonder
if
we
should
remove
it
and
we
might
be
covering
a
lot
of
that
in
the
other
principles.
How.
A
A
B
A
E
I,
like
that,
it's
saying
we're
trying
to
abstract
this
away,
but
what
comes
with
it
is
extra
configuration,
uh-huh,
I
I,
think
that's
a
good
place
to
be
for
now
and
I
still
think.
This
might
be
something
that
we're
gonna
find
we
covered
generally
in
the
next
sections,
and
it
would
be
nice
to
reduce
the
number
of
principles.
So
I
think
we've
gotten
this
to
a
good
point
and
can
always
remove
it.
If
we
find
that
to
be
preferable.
A
Okay
and
yeah,
and
who
knows
maybe
last
week
we
had
a
tech
writer
who
joined
us,
and
maybe
somebody
will
come
around
who's
a
little
better
at
work
at
writing
skills
to
tune
this
up
further.
Okay.
How
about?
If
we
move
on
to
the
third
one,
then
it
says
capability,
focused
environment
is
heterogeneous,
so
applications
need
to
be
aware
of
the
unique
capabilities
of
their
internals
hardware
and
programs
and
external
environment,
tiny
Edge
devices.
E
E
A
A
Better
myself
and
maybe
there's
an
issue
of
not
even
just
to
me
not
just
using
these
resources
but
and
maybe
this
is
pushing
the
envelope
of
solutions
already
out
there
but
cataloging
what
resources
are
out
there.
You
know
things
like
accurate
attempt
to
discover
them,
but
in
some
cases
maybe
they're
not
discoverable.
Yet
you
would
still
wish
to
have
some
sort
of
catalog
of
keeping
track
of
what
things
are
out
there,
where,
even
if
they
couldn't
be
Auto,
discovered.
D
B
What
I
think,
maybe
is
that
the
this
section
can
be
before
the
the
portability,
and
then
we
can
reference
that.
Because
of
of
of
of
this,
that's
why
why
the
portability
is
limited,
so
so
I
would
leave
for
now.
The
portability
as
well,
but
but
maybe
call
out
that
the
heterogeneous
environment
is,
is
why
we
have
our
limited
portability
and
and
extra
steps
for
that.
A
And
I
think
the
expansion
of
the
text
should
call
out
that
you
know
the
the
platform
you
won't.
You
desire
to
have
the
platform,
keep
track
of
what
resources
are
out
there
and
maybe
give
you
an
assist
in
being
able
to
utilize
those.
That
is
that
too
general.
You
know
we
have
specific
projects
that
attempt
to
do
this,
but
I
think
what
we
need
is
a
general
statement
of
what
what
you
would
hope.
The
platform
would
do
for
you
to
manage
resources.
If
you
will.
E
B
A
Well
to
me,
there
might
be
like
cloud-hosted
resources
that
are
involved
with
the
apps
and
I.
Don't
think
that
edge
native
would
treat
those
in
a
way
different
from
cloud
native.
Yet
you
know
these
local
resources
to
me
are
the
things
like
the
I
o
devices
that
are
specific.
You
know
to
the
the
domain
of
The
Edge
location,
that
that's.
Why
I
put
the
word
local
in?
If
you
want,
we
can
take
the
word
local
out.
C
A
B
A
A
B
B
B
A
E
Definitely
yeah-
this
was
just
from
our
brainstorm.
I
just
put
everything
in
there,
so
this
can
help
for
if
we
have
a
paragraph
on
it,
but
I
think
the
main
focus
of
this
was
air-gapped
environment,
slash
like
communication
queuing
for
when
you're
offline
versus
online,
some
of
the
things
that
we
see
and
I
think
this
section
would
be
really
interesting
to
discuss
kind
of
how
kubernetes
has
adapted
to
this.
E
Kind
of
I
forgot,
Edge,
core
I,
think,
is
what
it's
called,
where
it's
basically
cueing
information
to
send
to
the
kubernetes
API
server,
because
it
doesn't
always
have
connection
so
I
think
this
is
kind
of
how
your
architecture
needs
to
be
adapted,
knowing
that
it
won't
always
be
able
to
access
the
control
plane
nor
its
local
environment.
Even.
A
A
A
A
E
A
B
E
A
B
B
A
B
A
Yeah,
the
one
thing
that
I,
don't
think
is
called
out
in
these
other
rows.
That
I
think
is
a
common
technique
for
management
at
scale.
Is
that
if
you
could
impose
centrally
policies
that
get
Cascade
down
to
the
different
tiers
and
locations?
That's
how
that's
how
these
systems
are
usually
built
right.
A
Okay,
well
I
think
we
made
some
good
progress
here.
Yeah
I'd
invite
anybody
to
go
back
at
these
ones,
we're
still
in
the
middle
of
discussion
with
and
go
have
added
either
edit
directly
I
think
nobody
here
is
super
happy
with
this.
If
so,
whether
you
wanted
to
do
it
as
a
comment
or
just
take
another
crack
at
rewriting,
these
I'd
say
go
for
it,
but
let's
call
this
session
to
an
end
and
we'll
resume
again
at
a
future
meeting.