►
From YouTube: Intro: Kubernetes IoT Edge WG – Cindy Xing, Dejan Bosanac, Preston Holmes, & Steve Wong
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Kubernetes IoT Edge WG – Cindy Xing, Huawei, Dejan Bosanac, Red Hat, Preston Holmes, Google, & Steve Wong, VMware
This working group is focused on discussing, designing and documenting using Kubernetes for IoT and Edge applications. This session will start with the short introduction to the goals and tasks of this working group - with links if you want to get involved. Next, we’ll continue with the panel-style discussion with some Kubernetes users and active members of the group. The panel will cover mapping IoT and Edge use cases and to the Kubernetes architecture.
To learn more: https://sched.co/HSBb
A
Okay,
so
it's
2:35
we'll
get
started
on
time,
because
we'd
like
to
leave
as
much
time
as
we
can
for
QA
you've
come
to
the
IATA
and
edge
working
group
of
kubernetes
the
introductory
session.
At
the
end,
we'll
give
links
to
how
to
join
the
group,
and
this
this
deck
has
been
already
uploaded
in
PDF
form
to
the
sched
site,
so
you
should
have
access
to
it.
Now
with
that
said,
let
me
introduce
the
speakers.
This
is
a
four
speaker
panel.
We've
got
the
people
in
the
order
of
the
pictures
cindy.
B
Everybody,
my
name
is
Cindy
Ching
I'm,
a
Software
Architect
at
work
away
working
on
how
is
public
cloud
infrastructure.
My
domain
expertise
is
in
the
distributed
system
and
cloud
infrastructure.
I
worked
at
Microsoft
over
ten
years,
delivered
many
server
enterprise
products
and
cloud
services
for
the
past
two
years.
My
main
focus
is
on
continuing
dhaulagiri
at
computing.
B
A
I'm
Steve
Wong
I'm,
a
software
engineer
with
VMware
I'm
in
the
cloud
native
apps
biz.
This
unit
and
I'm
assigned
to
work
on
kubernetes
I've
been
working
on
kubernetes
since
2015
edge
and
IOT
is
new
to
kubernetes,
so
I
started
working
on
storage
in
kubernetes
got
a
background
in
enterprise
IT
and
before
that,
I
was
a
engineer
at
the
founding
stage
of
an
IOT
company
before
they
called
this
stuff.
Iot
called
wonder
where
that
is
still
pretty
popular
in
the
world
today.
A
What
we're
going
to
talk
about
today
is
this
idea
of
some
emerging
use.
Cases
for
kubernetes
now
kubernetes
has
been
around
since
2015
or
maybe
14,
with
the
original
use
case
of
managing
containerized
apps
running
in
a
data
center.
But
really,
if
you
take
a
step
back
and
look
at
it
from
20,000
feet,
kubernetes
could
be
viewed
as
a
resource
management
platform
that
is
api
driven
and
it
accepts
descriptions
of
a
desired
state
and
drives
controllers
and
operators
that
attempt
to
converge
on
your
declaration
of
the
desired
state.
A
What
if
you
could
use
this
as
a
general
purpose
thing
to
do
things
for
similar
applications?
The
benefits
might
be
that
you
could
take
advantage
of
a
popular,
well
architected
API
and,
as
you
can
tell,
by
going
to
this
conference,
the
velocity
of
the
kubernetes
project
and
other
CN
CF
projects
is
such
that
you'd
potentially
be
able
to
take
advantage
of
a
tremendous
and
growing
tool
chain,
things
that
deliver
metrics
monitoring
and
a
lot
more.
A
That
said,
there
are
some
differences
between
what
kubernetes
has
been
the
environments
it
has
been
used
in
and
what
you
want
to
expect
out
of
an
edge
or
IOT
deployment.
You
know
the
differences
are
that
many
of
these
edge
IOT
deployments
are
very
resource
constrained.
You
don't
have
this
expanse
ability,
like
you,
have
in
a
public
cloud
where
you
can
pretend
that
you
could
scale
up
to
meet
peak
demands
at
some
point.
A
If
you're
going
into
Rio
t,
there's
physical
space
limitations
may
be
money,
environmental
limitations
that
are
going
to
put
hard
limits
on
this
they're,
often
very
different
networking
requirements
and
for
the
most
part,
these
might
be
completely
unattended
or
not
not
attended.
By
experienced
IT
personnel.
You
also
might
have
to
deal
with
disconnected
operation
either
because
of
intermittent
network
or
by
design
where
you
intentionally
intend
to
air-gap
these
kinds
of
systems.
D
So
that's
that's
somewhat
of
how
we
have
divided
up
these
these
three
areas
and
then,
when
we
look
at
where
these
environments
run,
the
the
thing
we
don't
we
haven't
yet
covered
is
really
like
there's
a
set
of
imperatives
about
why
people
want
to
run
on
the
edge
which
include
things
like
bet.
You
know,
latency
of
requirements
of
workloads
that
need
to
run
at
low
latency
privacy
requirements,
bandwidth
limitations.
D
C
So
when
you
started
looking
into
all
these,
we
you
know
figure
out
and
that
it's
like
whoever
you
talk
talk
to.
We
have
different
Hospital
of
what
edge
actually
means
to
them.
So
we,
after
a
little
bit
of
discussions
and
talking
to
different
kind
of
people,
realize
that
generally
edge,
we
can
put
it
into
two
broad
categories.
C
C
D
E
Awesome,
thank
you.
So
what
I
would
ask
for
clarification
on
is,
can
is
a
device
edge,
actually
several
different
edges
and
what
I
mean
by
that
is
the
actual
end.
Sensors
might
serve
as
something
that
could
run
kubernetes
or
be
on
top
of
kubernetes
err
that
third
category
or
it
might
actually
be
the
gateways
right
and
and
I
view
those
requirements
as
being
really
really
different
between
like
what
you
would
put
on
a
Gateway
versus
what
would
be
on
like
endnotes.
E
A
B
I
say
something:
someone
was
saying:
the
definition
of
edge
computing
is
anything
other
than
Clark
computing.
Okay,
so,
as
you
can
see
from
this
chart,
there
are
all
kinds
of
potential
solutions.
So,
as
our
group
was
formed
back
in
this
August,
it's
not
very
long
so
well.
All
of
us
are
thinking
asking
all
the
questions
to
ourselves.
We
like
to
engage
all
of
you
and
asking
similar
questions,
and
then
we
can
have
the
conversation
and
come
to
something
which
is
meaningful
and
beneficial
for
all
of
us.
B
D
And
this
is
where
I'm
just
to
be
clear.
The
four
of
us
are
representing
a
working
group
that
is
larger
than
the
four
of
us,
so
we've
been
meeting
every
other
week,
a
number
of
folks
from
a
bunch
of
different
companies,
and
one
of
the
things
that
we
have
agreed
we
want
to
understand,
is
what
are
people
actually
trying
to
get
done
on
the
edge?
D
Because,
like
to
your
point,
when
we
drew
when
we
thought
of
these
blocks,
there
is
we
are
trying,
as
a
kubernetes
working
group,
trying
to
constrain
ourselves
to
just
where
kubernetes
applies.
That
doesn't
mean
there
aren't
in
this
sort
of
fog
sense
many
other
device
types
out
on
the
edge
as
well
right.
So
so
in
that
regard,
I,
don't
know
if
anyone
has
a
quick
example,
especially
I.
F
So
we
we
run
a
municipal
government
platform
and
we
provide
kiosk
network
for
people
to
make
cash
payments
check
payments,
credit
card
payments,
so
they're
touchscreens
running
over
a
cradle
point
cell
cell
service
and
currently
each
one
is
its
own
kubernetes
cluster,
much
like
inspired
by
chick-fil-a,
actually
with
a
nanny
service
connecting
back
over
to
the
VPN
to
an
internal
alb
to
talk
to
services
internally
into
prot
cluster,
or
something
like
that.
So
the
very,
very
small
devices
single
computer
running
a
few
things
of
hardware,
mostly
wired
hardware
and
a
touchscreen.
F
F
C
Maybe
we
just
should
mention
that
some
things
and
we
will
cover
that
in
more
details
in
the
deep
dive
session.
Tomorrow
is
what
kind
of
workers
we
identified
so
far
that
people
are
mostly
interested
in
so
first
thing
is
latency
trying
to
put
more
computer
resources
as
close
to
the
data
sources.
You
know
in
order
to
be
able
to
react
more
quickly
to
the
to
the
input
in
and
and
provide
feedback
quicker.
C
Then
there's
a
data,
ingestion
and
pre-processing
kind
of
workloads
that
that
we
think
it's
important
for
the
for
the
Resource
Network
environments
and
helping
people
to
you
know
ingest
data
from
the
heterogeneous
number
of
sensors
and
things
like
that
and
there's
a
privacy
kind
of
thing
where
you
won't
really
want
to
keep
things
local
and
and
don't
want
to
share
it
to
the
to
the
global
cloud.
So
and
basically,
that's
that's
where
we
are
at
the
moment.
I
think
also
compute
offload
is
important
as
well
and
try
to
distribute
that.
A
G
G
D
It's
one
of
the
ones,
so
one
of
the
one
of
the
outputs
of
this
group
has
been
a
still
in
progress,
white
paper
right
where
we're
trying
to
sort
of
consolidate
and
normalize.
Some
of
these
and
I
think
that's
that's
one,
which
is,
is
really
starting
to
see
some
convergence
as
as
poorly
defined
as
edges
in
some
ways,
I
think
there's
been
there's
been
some
increasing
convergence.
D
I
guess
I'll
call
out
again
to
see
for
those
of
you
who
that
have
thought
about
the
edge
and
think
there's
something
that
you've
come
across,
that
you
have
seen
infrequently
or
uncommon
in
the
in
the
general
discussions
of
edge
I.
Think
that's
it's
always
interesting
to
hear
if,
if
there's
sort
of
a
an
edge
case
right,
no
pun.
B
I
think
so
now
we
talk
about
the
potential
workload
why
you
want
to
do
the
edge,
so
then
next
question
would
be
what
do?
How
can
we
enable
it
right?
So
then,
coordinators
can
solution
here
before
I
drill
down
how
they
think
about
copper.
Natives
can
be
a
potential
solution,
I'd
like
to
understand
how
your
thinking
your
current
edge
scenario,
are
you
using
something
special,
different
from
coordinates
and
how
you
think
about
it.
A
I
I'll
address
your
question
briefly:
introduce
myself
I
work
at
Cisco,
I'm,
a
product
manager
for
IOT
edge
computing
actually
and
to
answer
your
question:
are
we
using
something
else?
So,
over
the
past
two
years
we
have
actually
built
container
orchestration
that
are
used
in
IOT
edge
scenarios
and
there's
production
deployed
and
part
of
the
reason
was
you
know
the
use
cases
that
we're
coming
for
us
was
lévesque.
I
H
I
So
the
edge
orchestration
has
to
be
super
lightweight
super
optimized.
For
this,
these
things
right.
Why?
Why
am
I
interested
in
cuban?
It
is
it's
not
that
our
stuff
doesn't
work.
It
works
great
for
the
use
case
that
we
have
seen.
There's
a
different
trend
that
is
happening
is
so-called
itu-t
convergence.
What
it
means
is
cisco
does
have
a
huge
number
of
IT
customers
and
enterprise
IT
guys.
They
also
have
ot
operations.
For
example,
a
motor
company
IT
department
are
now
saying.
I
Okay,
we
have
these
factories
and
we
would
like
to
yes
talking
with
our
ot
folks
ot
colleagues,
and
they
would
like
us
to
manage
the
infrastructure
and
policies
related
to
this
workloads.
Right
and
IT
guys
are
already
using
Cuban.
It
is
right
and
they
would
like
to
continue
to
use
Cuban.
It
is,
instead
of
a
custom,
proprietary
tool,
if
you
will
so.
I
C
A
Let's
move
on
to
the
next
question:
what
are
some
of
the
key
challenges
for
deploying
kubernetes
tej
today,
I'll
throw
one
out
there
and
that's
the
idea
that
when
you
run
it
edge,
you're
still
running
on
some
piece
of
hardware
that
isn't
maintained
by
some
third
party
like
in
a
public
cloud,
and
you
have
issues
like
updating
the
firmware
on
this.
Maybe
some
of
these
edge
deployments
aren't
even
on
hardware
that
is
running
Linux
with
a
docker
container
runtime
and
you've
even
got
a
challenge
of
deploying
your
apps
down
there
now
one
of
the
ways.
A
This
is
a
challenge
today,
but
I'm
gonna
throw
out
an
idea
that
Cooper
Deniz
today
when
you
deliver
your
app
workloads
to
your
worker
nodes,
it's
done
through
a
container
image
repository
which
could
be
viewed
as
just
a
blob
store,
but
you
want
it
with
governance,
so
you
typically
have
signing
security
scanning.
But
what,
if
that
repository,
could
whole
could
be
just
an
object
store
that
could
deliver
these,
including
blobs
that
happen
to
be
firmware
updates.
So
it's
a
challenge
today,
but
maybe
there's
the
seeds
of
a
solution.
Anybody
else
have
got
problems
today.
G
I
can
speak
for
the
over-the-air
update
kind
of
component
for
the
firmware.
There
are
solutions
out
there
and
my
company
deploys
one
and
it
does
use
like
a
repository
based
solution
like
git,
but
for
file
systems
called
OS
tree.
Maybe
some
of
you
know
os
tree
and
other
contexts,
but
that
that's
kind
of
one
way
it
has
to
handle
that
problem
you
described,
and
then
we
also
use
containers
on
the
edge
but
I
think
kubernetes
does
bring
some
additional
complexity,
which
is
non-trivial.
G
Of
course,
there
are
ways
to
manage
the
complexity,
but
for
our
customers,
I
think
that's
where
one
of
the
biggest
challenges
is
handling
that
complexity
and
right
now
we
use
things
like
docker
compose,
which
is
sort
of
a
lighter
level
of
complexity
that
handles
some
of
the.
You
know
configuration
management
of
the
container
as
workloads
but
I
think
that's
how
we
see
it
currently.
J
Yeah,
our
biggest
challenge
really
has
been
kubernetes
on
bare
metal
and
getting
the
cluster
stood
up.
That's
clustered
of
provision
itself
as
three
masters
get
that
all
working.
You
know
if
we
had
a
solution,
a
hardware
solution
and
a
vendor
that
could
go
out
there
put
three
nodes
in
each
one
of
our
restaurants,
maintain
it
and
know
that
we
have
a
kubernetes
cluster
up.
We
would.
That
would
be
something
that
would
be
attractive
to
us.
J
H
J
A
Thanks,
one
other
bet
brings
to
mind
that
I'll
throw
out
there,
it's
the
opposite
of
what
he
suggested
of
getting
a
vendor
to
deliver,
and
that
is
one
thing
you
really
have
to
concern.
Is
this
threat
model
where,
if,
when
you're
out
there
at
thousands
or
tens
of
thousands
of
unattended
locations,
sooner
or
later,
somebody's
gonna
physically
steal
one
of
these
things?
And
if
you
haven't
thought
about
your
threat
model
and
you've
got
keys
to
your
organization
and
somebody
just
goes
and
grabs
a
computer.
You
might
have
a
problem.
L
So
that
is
also
our
biggest
problem
that
the
certificate
rotation
on
the
edges.
How
do
we
manage
that
that
we,
we
can
trust
it
when
we
rotate
the
certificates
and
we
upload
those
to
the
our
cloud
where
we
store
those?
How
can
we
ensure
that
that
is
a
secure
edge
and
not
the
stolen
woman
right,
so
trust
of
the
edge
is
really
our
biggest
concern.
C
You
can
put
also
the
last
slide:
okay
yeah,
because
here
we
have
all
the
information
about
the
working
group,
as
we
mentioned
already,
so
it's
really
really
really
early
stage,
so
we've
been
operating
for
like
a
couple
of
months
now
and
you
know
when
we
started
the
idea
was
like
okay,
you
know
what
everybody
thinks
about
the
edge.
So
that's
why
we
started
with
with
this
white
paper
effort
just
basically
put
up.
You
know
blank
sheet
in
front
of
everybody
and
try
to
figure
out
things
like
what
what
we
talked
today.
What
are
the
workloads?
C
D
It's
a
doc
yeah
we're
not
completely
rehashing
all
aspects
of
everything
edge.
We
really
are
trying
to
be
a
kubernetes
working
group,
so
we
like
to
try
to
constrain
ourselves
to
think
about
what
is
at
that
intersection
of
kubernetes
and
edge,
and
we
also
are
a
working
group
and
not
a
cig
in
that
we
are
looking
at
what
are
some
of
these
edge
kind
of
considerations
that
might
apply
to
other
SIG's.
C
Yet
there
are
a
couple
of
goals
that
we
set
up
for
this
working
group
and
that's
first
and
foremost
like
educating
us
and
the
whole
community
about
IOT
and
edge
and-
and
you
know,
we're
we're
kubernetes
can
fit.
Then
you
know
create
some
of
the
blueprints
and
best
practices
with
the
features
that
we
know
that
we
can
use
today
to
help
people
doing
cuban
artists
on
the
edge,
as
some
people
are
already
doing,
trying
to
find
out
the
gaps
into
the
into
the
feature
set
and
see
if
appropriate.
Six.
C
We
can
address
those
challenges
and
then
also
trying
to
figure
out
what
things
won't
be
done
and
addressed
by
the
kubernetes,
and
maybe
you
know
starting
your
projects,
and
maybe
you
know
something
like
cube
edge.
That
will
try
to
solve
some
some
of
the
things
that
that
we
don't
see
that
kubernetes
should
be
including
by
default,
to
deal
with
these
kind
of
problems.
So
so
these
are
the
things
that
you
know.
We
have
all
like
a.
C
B
You
know
like
H,
is
a
password
nowadays
and
a
I
machine
learning.
So
for
our
group,
like
those
are
the
questions
we
are
thinking
of
I
think
all
of
us.
The
beauty
for
the
open-source
community
is
like
it's
a
encouraging,
open
discussions
and
then
so
you
all
can
join
us
to
the
workgroup
and
country.
So
tomorrow
we
are
gonna,
have
a
deep
dive
session.
We're
gonna
explain
where
we
are.
You
know
deeper
level
and
then
welcome
all
of
you
to
go
there
as
well
and.
A
Then
the
other
thing
at
our
working
group
sessions
that
I
did
vite
would
be
demonstrations
of
people
who
have
taken
the
first
step
down
this
journey.
We
don't
really
want
this
to
be
a
forum
forum
for
commercial
sales
pitches,
so
honestly,
I'd
favor,
open
source
solutions
and
things
like
that,
but
customer
case
studies,
you
know
yeah.
D
It's
really
at
an
experimental
phase,
so
I
think
one
of
the
things
that
we've
discussed
in
the
working
group
is
that
we
potentially
need
to
come
up
with
a
whole
set
of
very
quick
experiments
about
where,
where
kubernetes
applies
and
where
it
doesn't
and
and
try
some
of
these
things
out
so
helping
connect.
People
on
that
is
important.
So.
C
You
know
agenda
for
the
last
meetings
in
the
last
couple
of
months,
maybe
weeks
we
have
a,
we
already
have
a
couple
of
use
cases
presented
from
from
different
companies
and
research
groups
that
deals
with
it,
so
so
there's
also
already
a
bunch
of
material
there
or
what
talking
about
different
kind
of
challenges
that
people
are
thinking
about
solving
and
how
they
approach
these
challenges.
Today,
hopefully
you
know
we
will,
you
know,
streamline
all
these
efforts
and
try
to
provide
best
practices
for
for
features
that
are
already
there
in
kubernetes
to
deal
with
this
and.
A
A
Talk
about
once
you
join
the
group
you're
free
to
suggest
items
on
the
agenda,
so
go
ahead
and
look
you
know
just
by
yourself,
you're
free
to
go,
add
an
item
on
the
agenda
for
the
next
meeting.
We
can't
prop.
We
are
time
limited,
so
we
can't
guarantee
we'll
get
to
it,
but
we're
gonna.
Try
anybody
got
any
wrap-up
questions
here.
I
think
we're
nearing
the
end
of
our
time
slot,
but
we
have
perhaps
time
there's
one
I.
K
Guess
I
I
guess
my
question
is:
what
would
be
the
connection
between
this
working
group
and
the
multi
cluster
working
groups?
You
see
this
working
group
feeding
requirements
to
the
multi
cluster
sig,
just
because
it
seems
like
a
lot
of
edge
problems,
our
problems
of
scale
and
many
clusters.
So
is
it
that
this
group
provides
requirements
and
that
group
provides
solutions?
Do
you
view
this
group
actually
producing
any
code
or
projects
or
it's
more
of
a
feeder
or
a
user
group
to
feed
the
I'd.
A
Almost
go
so
far
as
to
say
it's
orthogonal
to
the
idea
of
multi
cluster
you're
right
that
kubernetes
currently
has
a
limit,
I
believe
of
5,000
nodes
and
at
edge.
You
could
have
way
more
than
that,
and
one
solution
would
be
to
go
to
multi
clusters,
but
I,
don't
think
we're
gonna
be
discussing
multi
cluster.
A
whole
lot
in
this
group,
I.
Think
yeah.
Once
you
hit
the
limit.
That
idea
of
going
to
multi
clusters
is
fairly
obvious
and
probably
best
addressed
in
the
multi
cluster
group.
Not,
but
but.
A
D
K
M
D
There's
there's
somebody
from
the
Linux
Foundation
who
attends
pretty
regularly
and
who's
who's,
explicitly
sort
of
offered
to
kind
of
liaison
and
have
edge
X
participate.
There's
also
some
other
initiatives
in
the
Linux
Foundation
to
try
to
tie
together
some
of
their
multiple
edge,
related
initiatives
into
sort
of
an
uber
initiative,
but
but
so
yes,
I,
think,
there's
there's
it
the
same
way.
There's
opportunity
for
interactions
with
other
kubernetes
SIG's,
there's
opportunities
to
interact
with
other
projects
in
open-source
in
general.
Yet.
N
I
have
something
of
an
add
I
experienced
myself
is
the
the
spec
that
kubernetes
bought
for
its
scalability
and
limits
like,
for
example,
he
couldn't
manage
more
than
5,000
notebook
abilities
but
I'm
working
more
in
deploying
Cubans
and
parameter
environment
and
with
like
with
trying
to
have
5,000
new
it
to
be
managed
by
one
cluster
in
age.
It's
something
not
applicable
like
to
have
five
cells
and
node
in
one
place
managed
it's
not
really
physical
nude
study,
something
applicable
and
also
having
like
just
100,
bought
the
note.
N
It
was
really
kind
of
limits
our
hardware
so
having
this
kind
of
only
had
a
hundred
board
whenever
CPU
calls
your
hub
or
memory,
it's
not
really
something
that
you
need
to
evaluate
again.
So
whenever
somebody
we
start
to
make
the
default
manage
number
of
boards
in
better
node
up
to
255,
and
we
limited
that
because
the
the
single
host
you
know
I,
be
a
subnet,
will
notice
255.
A
H
So
I'm
just
trying
to
make
sure
I'm
in
the
right
spot,
but
so
our
use
case
is
really
about
highly
resource
constrained.
Notes
and
I
mean
to
me
that
I
mean
that's
an
application
of
edge
and
I
just
want
to
make
sure
that
that
that
is
something
that's
the
subject
matter
of
this
because
of
everything
I.
H
D
That's
why
there's
still
this
sort
of
open
pointed
discussion
about
whether
or
not
managing
nodes
in
a
large
wanne
cluster
is
still
viable
or
not
right,
so
I
think
for
certain
use
cases
it
may
seem
crazy,
but
there
are
cases
where
simply
managing
to
run
even
large
sections
of
the
kubernetes
control
plane
on
that
edge
is
not
possible.
That's
where
things
like
virtual
cubelet
are
interesting,
etc.
So
I
think
it's,
and
these
are.
These
are
far
from
resolved
right.