►
From YouTube: Kubernetes IoT Edge WG: Intro to K8s at Edge + Device Connection Option- Steven Wong & Dejan Bosanac
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Kubernetes IoT Edge WG: Intro to K8s at Edge + Device Connection Options - Steven Wong, VMware & Dejan Bosanac, Red Hat
The K8s IoT Edge working group focuses on using Kubernetes as a tool to support applications running on, communicating with, or using information gathered from edge devices. LoRa has been getting attention as a connection technology featuring long-range communication at low cost (power and financial). This session will open with an introduction to LoRa along with the associated LoRaWAN protocol. What can it do? How does it compare to alternatives (WIFI, BLE and LTE, others). We’ll also talk about the open source “Drogue cloud” project which can support LoraWAN, and other connections, between devices and Kubernetes hosted apps and services. The presentation will include a demo. There are opportunities to contribute to the evolution of Kubernetes to better serve edge use cases. We will close with details on how you can get involved with the community effort to help this happen.
A
B
A
A
Then
we're
gonna
move
on
with
an
introduction
to
some
technology
called
lora,
along
with
a
network
architecture
based
on
it
called
lorawan
about
halfway
through
dion,
is
going
to
take
over
with
a
talk
on
the
drug
cloud
project
followed
by
a
demo.
Hopefully
you'll
like
the
talk,
and
if
you
do
we're
going
to
wrap
up
with
details
on
how
you
can
become
a
member
of
the
kubernetes
iot
edge
working
group
where
we
host
ongoing
discussions
on
subjects
like
what's
in
this
talk.
A
Edge
applications
are
often
isolated,
but
they're
generally
going
to
be
part
of
a
bigger
picture,
multi-tier
architecture.
If
kubernetes
is
involved,
you
know,
if
you're,
using
stand-alone
edge
devices
that
don't
talk
to
anything
else,
you're
unlikely
to
really
have
kubernetes
involved,
but
if
you
are
connecting
up
ice
edge
devices
to
feed
into
applications
and
servers
on
a
regional
or
global
basis,
that's
going
to
be
the
scenario
where
it
makes
sense
to
utilize
kubernetes
and
that's
what
we're
going
to
be
here
to
address
today.
A
A
A
A
So
we're
all
familiar
with
wi-fi,
which
is
an
example
of
a
local
area
network.
Its
reach
is
limited
to
perhaps
tens
or
low
hundreds
of
meters
wide
area
networks
bridge
much
longer
distances.
There
are
always
limits
imposed
by
physics.
So
what
you
have
here
in
this
chart
showing
trade
support
of
these
different
technologies,
measured
in
bandwidth
versus
range,
is
going
to
face
a
situation
where
you've
got
to
choose
the
right
technology
for
the
job.
No
technology
provides
all
the
attributes
at
once.
For
example,
there
isn't
a
technology
that
has
maximum
bandwidth.
A
At
the
same
time,
it
has
maximum
range
and
by
the
way,
this
graph
is
two
dimensions,
so
it
only
compares
bandwidth
versus
range
and
it's
missing
an
important
third
dimension,
which
is
power,
consumption
with
regard
to
power,
consumption,
older
people,
remember,
am
radio
stations
which
could
carry
for
huge
distances,
particularly
at
night.
These
am
radio
stations,
use
tens
of
kilowatts
of
power.
A
A
A
A
We
don't
have
time
today
to
go
into
a
deeper
dive
detail
about
laura,
but
it
features
something
called
a
link
budget,
and
this
is
a
budget
that
can
be
spent
either
to
achieve
long
range
or
better
than
average
penetration
through
building
walls
or
a
little
of
each.
At
the
same
time-
and
this
is
very
important
when
you're
dealing
with
a
low
power,
radio
technology.
A
A
The
device
features
300
microamps
of
power
consumption,
while
it's
in
sleep
at
its
peak
during
transmission
at
maximum
power.
This
can
go
up
to
120
milliamps
of
power
consumption
and
it
would
average
about
40
milliamps
of
power
consumption
during
active
radio
listening,
there
are
alternate
forms
of
lora
that
might
even
use
less
power,
but
these
are
potentially
devices
that
could
operate
on
a
battery
for
as
long
as
a
year.
If
you
vigorously
engaged
in
going
into
deep
sleep
and
waking
a
device
up.
Only
when
you
needed
to
measure
or
transmit
something.
A
So
far,
we've
only
talked
about
the
radio
link
from
the
device
to
whatever
it
links
to,
and
that
would
be
laura.
But
even
though
lora
stands
for
long
range,
long
range
here
isn't
infinite.
You
know,
let's
call
it
line
of
sight
up
to
10
kilometers
for
common
use
cases
and
laura
is
the
physical
layer.
Laura
is
the
radio
plus
the
laura
modulation,
but
in
a
practical
scenario
you
would
often
want
to
go
longer
distances
than
even
the
tens
of
kilometers.
A
So
what
you
do
here
is
put
together
a
big
picture
architecture,
and
if
you
compare
this
to
what
you've
got
in
physical
ethernet
links,
the
physical
ethernet
can
be
used
to
build
a
point-to-point
link.
But
this
isn't
really
a
practical
network.
In
an
ethernet
scenario,
you
need
to
bring
in
switches
routers
higher
level
protocols
and
management.
Tooling,
you
also
you
need
these
sorts
of
things
that
so
that
you
can
join
devices
together
with
other
things.
A
Going
back
to
the
early
ethernet
days,
somebody
called
metcalf
proposed
something
called
metcalf's
law
that
says
that
the
value
of
the
network
goes
up
with
the
square
of
the
number
of
connected
nodes.
Laura
is
no
different.
We
need
to
add
a
few
more
things
to
make
this
super
valuable
and,
what's
shown
in
this
slide,
is
something
called
lorawan.
A
Lorawan
is
managed
by
the
lora
alliance,
which
is
an
open
non-profit
association
that
currently
has
over
500
members.
Lorawan
is
designed
to
incur
very
little
overhead
for
a
device
to
simply
be
present
on
a
network,
so
it's
great
for
devices
that
are
usually
in
deep
sleep
most
of
the
time
to
save
power.
A
Note
that
you
can
have
devices
that
have
lora,
but
also
have
wi-fi
at
the
same
time
and
selectively
use
wi-fi
on
an
as-needed
basis
under
relatively
rare
circumstances,
once
again
to
save
power.
An
example
of
a
lorawan
network
is
the
things
network
which
we're
going
to
use
later
in
the
network
demo.
A
So
as
part
of
this
lorawan
architecture
moving
from
devices
at
the
left,
you
have
these
connected
to
gateways.
The
lorawan
gateway
receives
laura
modulated,
rf
messages
from
any
end
device.
That's
within
hearing
distance
and
forwards.
These
data
messages
up
to
the
lorawan
network,
server
that
is
just
to
the
right
of
the
gateways,
there's
no
fixed
association
between
an
end
device
and
a
specific
gateway.
Instead,
the
same
sensor
could
be
served
by
multiple
gateways
in
the
area.
The
gateways
operate
entirely
at
the
physical
layer
and
in
essence
they
are
nothing
but
lora
radio
message
forward.
A
If
the
crc
is
incorrect,
the
message
is
dropped,
otherwise
the
gateway
forwards
it
up
to
the
network
server
together
with
some
metadata
that
includes
the
received
signal,
strength
and
an
optional
timestamp
for
downlinks,
a
gateway
executes
transmission
requests
coming
from
the
network
server
without
any
interpretation
of
the
payload.
It's
just
forwarding
it
on,
since
multiple
gateways
could
be
in
a
position
to
receive
the
same,
laura
rf
message
from
a
single
end
device.
A
A
Text
so
here's
a
wrap
of
what
what
we've
learned
we've
got.
Some
we've
got
a
technology
called
laura
and
higher
level
protocol
built
upon
it
called
lorawan.
The
suitable
use
cases
for
this
are
use
cases
where
you
need
long
range
in
multiple
kilometers,
and
with
that
lorawan
backbone
you,
you
can
go
worldwide
on
this
stuff.
A
They
are
constrained
to
have
low
bandwidth,
so
there
are
clearly
use
cases
that
demand
higher
bandwidth
that
aren't
suitable,
but
for
things
like
event
or
measurement
reporting
that
are
in
the
range
of
reports
once
every
five
minutes
or
even
less
frequently
demanding
bandwidths
in
the
range
shown
in
this
slide.
This
is
a
good
match.
A
A
It
does
feature
128
bit
encryption
and
the
higher
level
network
server
can
integrate
data
and
event
streams
to
apps,
using
tcp,
mqtt,
http
cloud
events,
etc.
What's
not
suitable
for
laura
wan
real-time
data,
it
can
only
send
devices
in
small
packets
every
few
minutes,
not
continuous
data
streams.
You
can't
use
this
for
phone
calls.
A
You
should
use
it
something
like
lte.
Instead,
it's
nominally,
at
least
in
the
lorawan
case,
not
designed
for
home
automation,
although
semtech
does
have
some
alternate
technology
for
operating
a
private
loronet
that
can
be
used
for
home
automation,
also
not
useful
for
sending
photos
watching
videos
you'd
want
to
use
wi-fi
here.
B
Thanks
steve,
so
we
come
with
an
idea
to
to
to
bring
two
worlds
together
with
with
the
drug
iot
cloud,
the
the
rising
interest
in
in
using
rust
programming
language
to
to
to
do,
embedded,
work
and
and
and
on
the
other
side,
to
do
a
serverless
on
on
the
cloud
side
is
what
brought
us
to
to
try
to
bring
this
this.
This
two
two
worlds
together.
B
If
you,
if
you're
interesting
more
into
into
that
topic
here,
we
can
see
that
that,
from
the
central
part
of
this
system,
we
have
a
canadian
and
kafka
as
a
as
as
a
as
a
core
of
of
of
of
this
serverless
iot
solution.
But
we
need
a
lot
more
services
to
make
this
really
a
a
usable
of
of
the
shelf
iot
cloud
platform.
B
But
even
if,
if
we
have
that,
assuming
that
everything
runs
in
in
a
single
single
kubernetes
cluster,
we
can
deal
with
with
providing
appropriate
serverless
services
to
to
to
deal
with
with
our
data.
But
you
know
having
all
this
as
as
a
hostess
solution
and
and
and
potentially
having
iot
applications
running
in
different
clusters,
then
the
cluster
that
is
hosting
the
the
draw
cloud
we
need
to
provide
different
different
integration
with
integration
endpoints,
for
example.
B
As
you
will
see
in
the
in
the
moment.
One
more
important
part
of
this
is
is
the
change
events
as
we
see
on
the
arrow
here.
A
typical,
typical
iot
solution
never
consists
of
of
a
single
project.
It's
a
distributed
system
by
by
the
nature,
and
each
of
these
systems
has
its
own
their
own
registry
of
identities.
That
needs
to
be
to
be
managed.
B
So,
let's
talk
a
little
bit
about
types
of
devices
that
that
we
have
and
and
what
we
will
use
in
the
demo
today,
so
the
simplest
way
is
to
have
a
a
single
device
connecting
directly
to
the
to
the
cloud
right.
That's
a
simple
possible
case
in
some
cases:
steve
measures,
for
example,
using
using
the
ble
or
or
or
zigwave.
B
B
And
what
we
need
to
do
in
order
to
to
connect
it
to
the
cloud
is
actually
to
to
to
connect
this
this
device
as
an
as
an
as
an
as
a
device
in
in
in
the
draw
cloud,
and
for
that
we
need
to
do
a
proper
integration.
In
this
case,
we
will
use
an
http
integration
and-
and
you
know,
simply
configure
it-
that
for
every
message
that
that
the
the
things
service
receives
from
the
device
it
will
forward
to
our
our
cloud
solution.
B
And
for
that
we
need
to
specify
a
couple
of
parameters
which
is
like
an
url,
the
authorization
it
will
use,
and
we
will
see
that
that
in
the
moment,
but
you
can
see
that
that
already
here
we
have
at
two
different
identities.
So
we
we
have
an
identity
of
the
things
network
service
that
that
authorize
itself,
and
that's
that's
our
application
here
and
the
actual
device
belonging
to
that
application.
That
that
will
send
data
data
to
the
cloud
draw
cloud
we
will
use
for.
For
this
demo.
B
B
B
B
A
Thanks
for
that
great
demo,
and
just
to
point
out
my
device
here
that
I'm
holding
up
is
coming
from
los
angeles
and
dion
and
I
are
a
13
13
hour
flight
away.
So
this
is
definitely
long
range.
Although
laura
didn't
agree
at
the
bulk
of
that
range,
once
it
hit
the
things
network,
I
think
that
it
went
over
the
backhaul.
A
So
if
you
like,
the
presentation
today-
and
you
like
topics
like
this-
that
relate
to
using
kubernetes
for
applications
either
running
on
the
edge
or
supporting
data
and
events
collected
from
the
edge
with
kubernetes
hosted
applications
and
services
at
a
mezzanine
tier
or
a
cloud
tier,
you
should
join
this
group.
We
have
meetings
twice
a
month
they're
at
alternating
times,
so
we
have
one
series
that
is
optimized
for
people
in
north
america
and
the
north
american
meetings
report.
Repeat
every
four
weeks.
A
We
have
another
series
that
was
optimized
for
asia,
asia,
eastern
europe
and
once
again
those
occur
middle
of
the
night,
if
you're
in
north
america,
but
a
better
time
for
other
locations
and
they
repeat
every
four
weeks.
We've
also
got
a
slack
group
in
addition
to
the
meetings.
So
you
can
go
on
there
and
ask
questions
the
content
at
the
user
group
meetings
is
intended
to
be
user
driven.