►
From YouTube: Kubernetes WG IoT Edge 20220504
Description
May 4, 2022 meeting of the Kubernetes IoT Edge Working Group. Discussion of running Bluetooth low energy mesh applications on K8S
A
A
And
and
don't
feel
bad
about,
hijacking
the
because
I
don't
have
that
much
I
just
wanted
to
share.
What's
been
going
through
my
mind-
and
you
know,
maybe
by
talking
through
it,
get
more
ideas
for
myself
and
from
you
like
on
how
to
to
proceed
and
how
to
deal
with
with
this
kind
of
this
kind
of
use
cases
so
you're,
okay,
perimeters
to
start.
A
You
know,
get
a
more
clear
picture
of
of
how
how
to
deal
with
this.
So
the
idea
is:
there's
a
ble
as
a
standard
right
which
is
similar
to
the
standard
Bluetooth,
it's
a
it's
a
it
can
be
connection
between
the
device
and
so
to
say
the
the
Gateway
or
or
it
can
work
in
in
a
more
advertising
mode,
but
there's
also
a
ble
mesh,
which
is
a
spec
on
top
of
the
the
Bluetooth
low
energy
which
allows
the
basically
to
have
a
lot
of
devices.
A
Send
the
commands
and-
and
you
know,
connect
the
cloud
applications
like
like
digital
Twins
and
everything
in
into
into
that
picture,
but
to
go
from
the
mesh
to
the
clouds
you
need
some
kind
of
Gateway
and
or
or
so
so
to
say.
Edge
Edge
stack
to
to
basically
offload
things
from
the
from
the
from
the
Bluetooth
mesh
and
put
it
put
it
to
the
cloud.
C
C
A
A
A
The
the
mesh
demon
is
using
the
system
bus
to
to
send
events
basically
of
what's
going
on
on
the
radio
and
the
final
thing
you
would
need
you
need
for
this,
because
this
mesh
demon
is
basically
holding
a
lot
of
State,
meaning
it
needs
to
know
all
the
devices
it's
coming,
communicate
with
it.
It
needs
to
know
all
the
keys
and
and
there's
needs
to
be
a
provisioning
process
for
a
device
to
actually
to
actually
join
the
joint
join
the
mesh.
So
there's
there's
a
there's
a
as
you
can
see
here.
A
Yeah
in
Docker,
but
but
talking
just
just
from
the
pure
Linux
box
perspective.
These
are
the
the
three
things
you
you
would
need
you.
You
need
access
to
the
device.
You
would
need
a
couple
of
folders
for
for
con
for
storing
the
configuration
in
the
state
and
you
need
access
to
the
debuffs
for
for
you
to
be
able
to
communicate
with
with.
A
C
B
A
Yeah
we
will
get
there
yeah.
So,
okay,
no!
No!
No!
It's
all!
It's
all
good
questions
because
it
took
it,
took
me
a
while,
like
I
said:
okay,
yeah
I'll
I'll
get
to
do
this
part
because
other
people,
other
folks
are
working
on
the
on
the
firmer
side
and
and
some
folks
are
are-
are
covering
the
the
cloud.
A
A
This
word
is
when
you,
when
you
start
the
Gateway
right,
it
needs
to
have
some
state
or
or
you
need
to
be
able
to
create
that
state
from
from
somewhere
somewhere.
So
we
envisioned
that
it
will
have
like
a
number
of
devices,
for
example
the
think
about
the
the
typical
you
know,
conference
demo
use
case.
B
A
B
A
So
there
needs
to
be
a
handshake
between
the
device
and
and
and
and
the
provisioner
or
or
the
Gateway
in
in
in
this
case,
for
the
device
to
be
able
to
join
the
mesh.
So,
basically,
when
you
turn
on
device,
I
need
to
dig
a
a
little
bit
more
into
this,
but
this
is
my
current
understanding
how
this
works.
A
So
you
you
you,
you
get
your
microcontroller
device,
you
you
boot
it
up
and
and
it
will
start
broadcasting
its
ID
uuid
over
over
the
the
Bluetooth
mesh
right,
and
it
would
be
seen
by
everybody
else,
even
and
in
the
provisioner
app
as
well.
Then
somebody
needs
to
say
entrepreneur
up,
say:
okay,
you
know
provision
this
device
right
and
then
that's
where
the
handshake
between
the
Gateway,
app
and
and
the
actual
device
is
actually
being
being
started.
A
B
C
B
A
But
but
once
the
device
is
provisioned,
it
usually
gets
a
token
or
as
a
result
of
that,
and
that
token
should
be
stored
somewhere
that
you
know
when
the
device
reboots
it
can
join
the
mesh
without
provisioning.
So
so
so
so
so
you
can
have
pre-provisioned
devices
so
to
say,
and
when
you
turn
it
off
turn
it
all
on.
If
it
has
all
the
keys-
and
it
has
its
own
token,
it
can
just
attach
to
the
mesh
without
without
needing
to
to
be
provisioned.
Sorry,
yeah
again,
is
that.
B
A
B
A
A
It
can
have
multiple
workloads
that
are
actually
behaving
like
a
like
a
Bluetooth
devices
right,
so
so
so
so
so
there's
nothing
wrong
in
in
actually
implementing
implementing
implementing,
like
that
and-
and
you
know
interacting
with
with
the
rest
of
the
rest
of
devices
in
the
mesh,
what
they
Envision
in
the
future
as
well.
So
first
value
here
is
that
you
can
test
all
these
things
without
actually
having
to
to
have
a
a
physical
microcontroller
and
Flash
it
or
everything.
So
this
is,
you
can
run
all
these
as
I'll.
A
Show
you
a
little
bit
later,
just
as
a
is
a
is
a
payload
on
on
the
kubernetes
right
in.
In
these
terms,
everything
will
run
on
the
single
hold,
but
if,
if
you
have
a
multiple
host,
they
that
will
work,
because
it
will
all
go
through
the
to
the
host
3D,
radio
and
and
being
emitted
to
to
other
nodes
in
the
in
in
the
area.
A
Yeah
so
okay
start
from
the
bottom
bottom
up,
improve
the
stack
that
that
it
can
be
used.
You
know,
on
its
own
a
little
bit
easier
and
and
be
more
programmable,
so
that
we
can
add
more
apis
and
integrate
it
better
in
our
draw
cloud
with
our
firmware
but
but
but
also
being
able
to
to
integrate
it
in
in
any
any
other.
Any
other
solution
that
that
wants
to
use
it,
because
that's
that
that's
very
hard
thing
to
do
today.
C
So
in
chat,
I,
post
I,
don't
know
if
this
is
relevant
or
not,
but
I
think
it
might
be,
and
it
looks
like
there's
an
Android
API
for
doing
this
ble
onboarding.
So
maybe
that's
a
decent
model
to
look
at
somebody
else
who
tried,
if
that's
a
similar
enough
problem
going
on.
Maybe
there's
something
to
be
learned
of
by
looking
at
that.
A
It's
a
different
problem
so
that
that's
what
I
said:
there's
a
ble
and
and
there's
a
billionaire
and
and
and
the
ble
is-
is
much
more
much
better
or
better
supported
at
the
moment.
But
the
match
thing
is
is
still
a
thing
in
development
and
and
yeah
for
one
reason
or
Not
Another.
We
we
decided
to
focus
on
on
the
on
the
mesh
as
a
as
a
thing
that
that
we
wanna
we
wanna.
You
know,
play
with
and
and
continue
developing
for
for
this
kind
of
use
case,
foreign.
A
But
I
I
think
it's
it's
a
from
like
thinking
and
just
just
to
finish
on
on
this
device
app.
What
I
think
it's
also
will
be
useful
at
some
point.
Is
that
will
be
will
be.
It
will
be
useful
to
have
something
like
this
to
be
able
to
do
a
scale
testing
at
some
point,
because
it's
much
easier
to
to
to
run
a
hundred
of
pots
and
and
test.
A
Oh,
but
but
what
what's
interesting
to
me
is
is
that
you
know
this.
This
use
case
shows
one
kind
of
workload
that
I
think
pushes
a
little
bit
this
age,
Edge
workouts,
you
know
to
the
to
these
boundaries.
It
is
from
from
what
they
see
so
far,
because
you
know
our
our
our
our
service
needs
to
have
a
a
proper
yeah,
proper
access
to
the
to
the
physical
host
device.
A
A
So
so
this
is
at
the
moment
how
how
how
things
work.
This
is
the
deployment
of,
for
example,
the
the
Gateway
service.
The
entry
point
will
start
the
local
merge
demon,
so
so
I
was
experimenting.
A
lot
about.
You
know
where
each
of
these
things
should
live
or
or
not,
and
and
you
can
easily
see
that
that
you
can
start
emerging
even
on
the
host
as
well
and
and
and
then
you
you
use,
use
just
keep
all
the
state
state
outside
of
the
containers.
A
But
I
I
ended
up
thinking
that
that
it's
good
to
have
a
containerized
mesh
and
mesh
State,
because
it's
much
easier
to
to
replicate
that
over
over
the
multiples
of
multiple
systems,
because
otherwise
you
you
will
need
something
else
like
ansible
or
or
something
else
to
to
get
your
host
to
the
proper,
proper
State.
Even
before
you,
you
can
run
your
workload
like
this.
Your
workload
actually
own
this
state,
through
the
volumes
and
and
and
and
and
starting
a
demon
internally
right
and
for
the
state
yeah.
A
A
But,
for
example,
if
in
in
this
current
state
of
things
you
want
to
add
new
device,
you
need
to
basically
exit
into
this
spot
run
the
tooling
start
the
provisioning
and,
and
it
will
update,
update
the
state
and
storage,
but
there's
nothing.
There's
no
API
I
could
use
today
to
to
do
this,
and
and
the
idea
is
to
develop,
develop
the
other
one
and
and,
as
you
said,
Steve
in
order
to
use
to
access.
B
I'm
really
interested
in
this.
It's
actually
quite
interesting.
We
in
our
community
meeting
this
morning,
someone
proposed
a
discovery
Handler
for
awkward
for
Bluetooth,
and
that's
why
we
were
discussing
like
the
blue,
Air
crate,
which
is
a
little
under
maintained
compared
to
another
rest
crate
that
I
don't
remember
what
it
was,
but
blue
is
based
off
blue
Z,
which
is
very
established
but
anyways.
So
this
is
really
interesting
because
it's
I
mean
clearly
in
similar
Landscapes
as
awkary
and
yeah
I'm,
enjoying
hearing
about
all.
A
This,
my
idea
would
be
to
to
discuss
at
some
point
how
we
can
you
know,
hook
up
actually
occurring
in
in
the
picture
as
well,
right,
the
and
and
like
like,
going
into
into
the
same
direction,
but
currently
I
I
haven't
seen
seen
anything
in
inactory.
That
would
help
with
this
state
stateful
Edge
Services
right.
So
that's
why
I
wanted
also
to
pick.
You
know
pick
your
mind
about
all
these
things
and
and
yeah,
which
one
is.
A
B
A
Is
just
so
so
let
me
so
let
me
show
you
how
it
works
today.
So
so
we
have
the
security
content,
so
it
needs
to
be
a
previous
container.
So
so
it
can
access
the
the
actual
radio
device
right
and
we
we
need
to
mount
these.
These
volumes
containing
the
the
mesh
state
so
so
that
the
merge
demon
running
inside
of
it
can
work
properly
and
and
in
the
end
we
we
need
to
mount
the
Divas
socket
to
enable
the
communication
with
the
outside
world
on
on
the
same
node.
B
A
A
A
A
A
So
the
device
basically
is
just
sending
sending
data.
You
know
using
the
python
library
that
basically
talks
debus
on
a
proper
Channel
and
then
sending
a
properly
format
to
Divas
messages.
That's
that's
all
this
app
is
is
doing
and,
and
then
the
Gateway
is,
is
basically
getting
or
getting
those
those
messages.
This
is
from
the
other
device
right.
But
but
it's
the
same
thing.
A
It's
listening
on
the
Divas
Channel
I
think
that
that's
a
proper
terminology
getting
all
the
events
there
and
then
you
know
converting
those
in
into
in
into
the
API
that
our
Cloud
project
is
is,
is
actually
expecting
right.
So
there's
a
device
model
and
it
gets.
It
gets
converted
from
the
ble
mesh
model
to
the
Json
model
that
that
this
Cloud
expects.
B
A
B
I
have
a
I
would
love
to
look
at
it
deeper
and
kind
of
get
even
more
of
a
sense
of
what's
going
on
there,
but
one
of
the
parts
where
I'm
curious
about
is
I.
Guess
that
diagram
is
actually
quite
helpful.
Let
me
see
I
think
I
might
have
it
pulled
up
just
to
make
sure
I'm
using
the
right
terms
for
everything.
Okay,
I.
B
A
So
when
you
start
from
the
clean
on
your
provisioner
node,
you
can
say:
there's
there's
a
there's,
a
tool,
part
of
the
blue
Z
that
that's
configuring,
the
mesh
right
and
that's
the
first
part
we
need
to
tackle
you
know
in
order
to
this
be
be
more
programmable
and
more
integratably
into
the
bigger
ecosystem.
But
for
now
you,
you
start
that
that
tool-
and
you
say-
create
create
me
a
mesh
right
and
it
will
create
a
great
a
basic
key
for
the
provisioner.
A
I
may
be
missing
some
some
things
because
I
I,
it
didn't
dig,
dig
too
deep
into
it,
but
that's
something
next
on
my
plate.
So
maybe
you
know
in
a
month's
time
we
can
revisit
with
more
information
and
then
you
create
an
application
key
for
for
one
application.
That's
the
concept
of
of
the
BL
image,
spec
and
then
well
you'll.
You
you,
you
basically
listen
for
unprovisioned
devices
which
will
broadcast
themselves
there,
devices
that
are
available
in
your
surroundings,
but
not
being
being
joined
the
mesh.
A
There's
a
couple
of
keys
network
key
and
application
key
and
if
that's
all
successful
devices
is
part
of
the
mesh
and
that
state
is,
is,
is
written
into
this
storage,
these
volumes
that
they
show
you
that
the
the
mesh
demon
is
is
using
right.
So
so
in
theory
you
can,
then
you
know:
stop
the
demon
get
these
files,
these
Json
files,
with
with
with
keys
and
and
everything,
and
basically
containerize
it
and
and
put
it
up
somewhere
else
and-
and
you
have
your
mesh
with
with
its
proper
state
right.
B
A
A
Plants,
so
our
demo
was
in
in
the
end
the
postponed
canceled
because
copied
and
not
enough
participants
interesting
into
this.
These
kind
of
things,
but
we
are
working
to
to
you,
know
to
complete
it
and
to
make
it
work
and
and
present
you
know,
have
it
see
having
it
being,
reproducible
on
on
different
events,
but
but
I
think.
The
whole
idea
with
the
mesh
is:
is
that
ble
on
its
own?
A
A
Here
comment:
yeah,
yes,
so
so
mesh
should
help
with
that,
because
it,
you
know,
as
a
mesh
there's
a
there's,
a
more
responsibility
and
and
scale
of
floating
from
a
single
node,
right
and
device,
and
and
the
Gateway
in
in
the
main
scenario
is
just
one
device
right.
It
gets
everything
it
it
can
get
from
from
from
what
it
can
see.
A
It
can
send
data
data
for
the
you
just
have
a
role
role
of
Gateway,
but
but
it's
a
it's
a
simple
device
from
the
mesh
perspective,
so
so
idea
would
be
to
have
at
least
couple
of
of
gateways
in
in
in
this
kind
of
scenario
and
I.
Think
for
that
even
you
know.
In
my
mind,
the
current
idea
is:
is
that
like
having
a
proper
three
node
cluster,
which
each
node
having
like
a
demon
set,
which
is
which
is
which
is
a
gateway?
And
then
you
know.
A
But
actually
distributed
over
the
the
The
Wider
area,
so
so
that
you
you,
you
actually
have
a
Bluetooth
coverage
and
and
behaving
like
like
a
one
cluster,
with
with
each
node
being
a
Gateway
and
and
being
able
to
cut
to
cover
just
the
certain
certain
area.
I
think
that's
something
we
are.
We
are
we're
heading
for
yeah.
That's.
B
A
B
And
I
think
the
interesting
thing
here
or
the
question
that
we
can
maybe
take
this
later,
but
is
if
that
Gateway,
you
have
a
Gateway
running
on
each
node
kind
of
demon
so
fashion.
If
that
Gateway
can
kind
of
enumerate
what
devices
are
on
each
node,
then
you
could
bring
awkary
in
in
the
sense
of
say,
you
have
applications
that
you
want
to
only
be
deployed
to
the
node
that
has
that
device.
A
A
It's
an
issue
because
the
whole
idea
to
have
a
mesh
is
that
these
devices
can
roam
basically
right.
So
if
you
go
from
one
room
to
another
room,
you
will
switch
Gateway,
but
but
your
application
will
continue.
Working
I
was
more
thinking
in
in
some
somehow
yeah,
using
accurate
to
to
figure
out
if
the
nodes,
if
the
node
supports
Bluetooth
in
the
first
place,
so
this
demo
set
can
be,
can
be.
A
A
No,
no,
it's
just
the
Bluetooth
right.
If,
if
all
the
nodes
are
are
the
the
Bluetooth
and
part
of
the
same
mesh
yeah,
so
you
know
this
node
will
lose
the
Bluetooth
connection,
but
the
other
one
will
pick
it
up,
that
that's
the
whole
point
and
and
that
Gateway
will
then
continue
to
to
pick
up
the
data
from
the
from
the
device.
A
B
B
A
B
A
I
mean,
but
but
we
would
need
to
implement
something
that
that
will
basically
right
now
what
we're
doing
we're
getting
everything
from
and
sending
sending
it
to
the
cloud
right.
What
what
we
need
to
do
is
to
create
those
database
a
little
bit
smarter
to
know
you
know
to
create
an
ipmesh
that
will
map
the
the
radio
mesh
right
that
we
have
so.
A
Yeah
and
I
think
that's
something
yeah
I
I
see
where
you're
going
and
I
think
there's
something
accurate
can
help
with
right
and
in
the
sense
that
we
we
are
saying
now
yeah
for
this
particular
Bluetooth
device.
You
know
don't
send
things
to
the
cloud.
Send
this
to
the
this
local
pod
running
running
on
the
edge
and
I
think
that's
a
very,
very
powerful
use
case.
Yeah.
B
B
A
The
the
first
one
yeah-
okay,
okay,
okay,
but
but
but
but
it
it
it
all
depends
how
we
Implement
things
so
from
the
mesh
from
the
Bluetooth
perspective,
every
device
just
broadcast
everything
it
has
and
every
device
listens
to
everything
that
comes
to
it.
So
every
Gateway
every
so
we
have
device
and-
and
we
have
nodes
right
so
every
node-
we
will
receive
everything
that
that
it
have
right.
A
So
every
Gateway
service
that
we
have
at
the
moment
will
receive
everything
that
every
device
it
it
has
publishes
locally.
So
what
we
do
at
the
moment
is
just
send
everything
to
the
cloud.
Did
you
up
there
and
you
know,
push
it
forward
to
to
forward
to
the
stack,
but
in
theory
those
Gateway
Services.
You
know
we
control
them,
so
so
they
can
do
much
more
local
things.
They
can.