►
From YouTube: Intro: K8s IoT Edge Working Group – Adopting a Cloud Control Plane... - Steven Wong & Dejan Bosanac
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Intro: K8s IoT Edge Working Group – Adopting a Cloud Control Plane to Edge - Steven Wong, VMware & Dejan Bosanac, Red Hat
Edge refers to geographic distribution of compute, data ingest, and network. A lot of use cases fit under this “umbrella”. Kubernetes was born as a solution for large scale application hosting in a cloud. Edge deployments have much in common with public cloud - large scale, desire for automated remote management - but at the same time there are key differences. This session will be an introduction to challenges of applying Kubernetes for edge and IoT applications. We will survey some solutions for addressing these challenges, and cover how you can interact with the open source community to learn about and help build better solutions for edge.
https://sched.co/cpAG
A
B
A
On
so
we're
going
to
give
contact
information
and
a
link
to
the
deck
at
the
end,
but
here's
the
agenda,
I'm
going
to
start
with
a
really
quick
definition
of
what
we're
defining
as
kubernetes
at
the
edge
within
this
talk.
Kubernetes
has
obviously
been
hugely
successful
in
applications.
Calling
for
orchestration
of
containerized
apps
in
large
clouds,
but
edge
can
be
a
little
different,
we're
going
to
cover
what
kubernetes
can
do
and
what
it
can't
at
edge.
A
Hopefully
you
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
this
talk
when
we
say
kubernetes
at
edge.
What
are
we
referring
to?
Well,
some
examples
are
listed
here
at
past
kubecon
physical
events,
we've
taken
audience
polls
to
identify
the
popular
use
cases
and
in
those
polls
the
leading
use
cases
have
been
retail,
telco,
industrial
iot,
smart
cities
and
video
capture
with
image
recognition.
A
Let's
start
by
observing
that
containerized
packaging
of
apps
can
be
really
valuable
in
both
a
centralized
cloud
and
at
edge
locations
and
with
edge
just
like
cloud.
You
might
have
a
lot
of
these
things
to
manage.
So
just
like
a
large
data
center
hosted
cloud,
you
need
something
that
offers
automated
management
at
a
huge
scale.
A
A
A
But
that
isn't
the
only
aspect
that
makes
kubernetes
attractive.
The
second
factor,
and
perhaps
the
most
important,
is
the
healthy
ecosystem,
which
is
spinning
off
collateral
tools.
What
the
cncf
calls
the
cloud
native
landscape
you
know:
edge
applications
are
going
to
need
far
more
than
just
containers.
I'm
talking
about
logging
network
management,
even
things
like
available
training
materials
and
experienced
people
and
vendors
writing
software
on
island
just
isn't
efficient.
A
A
A
cloud
data
center
can
generally
add
new
capacity
in
days
to
weeks.
Edge
locations
are
really
different,
they're
going
to
have
no
trained
staff,
and
in
some
cases,
have
hardware
life
cycles
of
a
decade
or
more.
The
nature
of
networking
at
edge
can
be
quite
different.
It's
not
all
ip
based
protocols,
load,
bandwidth
and
intermittent
connections
are
normal
scheduling
of
apps
to
the
hosts
they
run
on
is
different
in
a
large
public
cloud.
The
compute
resource
is
mostly
interchangeable.
A
A
So
a
scheduler
might
need
an
awful
lot
of
coaching
to
do
the
right
thing,
then
there's
the
big
issue
of
physical
security.
There
might
not
be
any
so
to
compare
central
cloud
to
edge
they're,
both
managing
a
lot
of
things
both
benefit
from
containerization
as
a
road
to
portability
and
both
benefit
enormously
from
a
community
driven
driven
by
a
standard,
api
and
collateral
tools.
A
Let's
consider
how
we
might
apply
kubernetes
at
edge.
Suppose
we
take
one
monster-sized
central,
hosted
kubernetes
cluster
with
each
edge
location
running
as
a
cluster
node.
Can
that
work
maybe-
and
I
think
it's
fair
to
say
that
I
know
of
people
who
are
trying
it
and
reporting
that
it
works
well
enough
to
be
useful,
but
for
others
they're
going
to
be
issues.
For
example,
what
if
I
need
more
than
5000
nodes,
the
current
kubernetes
upper
limit?
A
Yes,
I
could
go
multi-cluster.
Some
use
cases
might
have
enough
resource
at
the
edge
locations
to
run
a
full
kubernetes
cluster
at
each
location.
Can
you
federate
over
5000
clusters?
I'm
not
really
sure,
but
I
know
it
would
be
challenging
and
running.
A
full
cluster
at
each
edge
location
is
going
to
take
resource
that
some
of
you
may
not
have
and
suppose
these
locations
are
unstaffed.
A
A
A
Let
me
start
by
describing
the
kubernetes
control
plane
architecture,
because
this
is
the
basis
of
its
extensibility.
The
kubernetes
api
has
a
declarative,
not
an
imperative
philosophy.
This
means
that
you
tell
kubernetes
your
desired
goal
and
it
figures
out
how
to
get
there.
You
don't
feed
it
step
by
step
instructions.
A
So
what's
a
controller?
Well,
it's
just
a
snippet
of
code
that
looks
at
this
declared
desired
state.
It
then
looks
at
the
state
of
the
world
and
compares
it
tries
to
reconcile
these
by
making
the
state
of
the
world
look
like
it
should,
according
to
the
configuration,
if
the
controller
fails,
or
it
can't
fully
realize
the
desired
state
it
continuously
and
relentlessly
retries.
A
If
it
takes
time
to
make
stuff
happen,
the
controller
can
be
patient
and
diligently
work.
This
is
a
very
stable
distributed
system
pattern.
Actions
are
item-potent
and
self-healing.
So
if
something
goes
wrong,
the
controller
will
fix
it.
If
you
change
the
desired
declaration
of
state,
while
the
controller
is
working,
it
can
change
course
and
work
towards
the
new
goal
picture.
This,
like
the
thermostat
in
your
house,
set
a
desired
temperature,
go
to
sleep,
everything's
going
to
be
fine.
Contrast
this
to
a
wood
burning
fireplace
of
a
hundred
years
ago.
That's
an
imperative
api,
too
cold.
A
You
go
outside
and
get
a
log.
How
well
does
that
scale
what
if
the
person
had
to
manage
a
hundred
fireplaces
in
a
huge
building
or
many
buildings
on
a
college
campus,
compare
this
to
the
declarative
nature
of
thermostats
and
you
can
kind
of
get.
The
idea
of
you
know
the
advantages
of
going
with
a
design
based
on
declarative
with
controllers.
A
Internally,
kubernetes
is
built
on
these
controllers,
a
lot
of
them
as
a
recurring
aspect
of
the
system.
The
placement
of
containerized
apps
on
worker
node
servers
is
handled
by
just
such
a
controller,
but
the
interesting
thing
for
iot
and
edge
is
that
you
can
write
your
own
custom
controllers
for
managing
and
controlling
whatever
you
want
or
need.
You
can
extend
kubernetes,
and
this
is
called
a
custom
resource
definition
or
crd.
For
short,
when
you
install
one
of
these,
it
extends
the
api
with
the
xcd
database
holding
the
settings
using
that
declarative
model.
A
The
the
declarative
part
of
this
is
called
a
crd
and
they
work
with
a
piece
of
software
called
a
controller
and
by
the
way
the
controller
can
be
hosted
on
kubernetes,
but
doesn't
have
to
be.
You
could
host
it
externally
now
what?
If
we
used
kubernetes
crds
to
manage
low-level
devices
and
apps
on
those
devices,
even
when
the
constraints
don't
allow
docker
packaging,
you
can
run
kubernetes
orchestrated
containers
where
it
makes
sense
the
upper
half
of
this
diagram.
A
Depending
on
your
use
case,
you
could
even
influence
the
line
by
using
specialized
kubernetes
distributions
like
k3s
or
microcades
that
are
made
specifically
for
low
resource
environments,
or
you
could
go
with
stretch
clusters
where
edge
locations
run
individual
kubernetes
worker
nodes
instead
of
whole
full
clusters,
regardless
there's
always
going
to
be
some
point
where
the
standard
managed
containers
can't
go
know
take
the
arduino
platform.
For
example,
it
doesn't
even
run
an
os,
so
it's
never
going
to
run
a
docker
image.
A
A
B
Of
these
custom
resource
definitions
and
when
we
have,
when
we
pair
the
crd
with
the
with
the
control
loop,
we're
basically
getting
operator
operator
that
that
leaves
in
in
its
own
reconcile
loop
and
and
try
to
do,
do
the
right
thing
for
us.
So
the
same
pattern
as
as
we
saw
that
that
kubernetes
itself
uses
is
used.
You
use
here
so
so
the
operator
observe
the
current
state
of
the
system
and
the
desired
state
of
the
crd
analyze
the
differences
and
then
act
on
that
trying
to
get
the
the
real
world.
B
B
So
here
I
wanted
to
show
you
like
a
simple,
simple
crd
and
how
it
can
it
can
look
when
it
when
it
doesn't
apply
to
a
typical
kubernetes
resource
like
a
pod
and-
and
things
like
that.
So
here
we
have
a
device,
and
this
device
basically
have
a
specification
for
for
a
couple
of
of
inputs
inputs,
and
then
we
also
see
here
that
that
each
crd
has
current
status
it's
empty
here.
B
So
here
we
we
defined
how
we
can
model
things
outside
of
the
kubernetes
and
and
and
a
new
obstructions
that
that
we
want
to
apply,
but
for
some
iot
and
edge
edge
edge
locations.
Maybe
we
can
think
about
the
other
way
around.
So
maybe
our
pod
specifications
is
all
we
need,
so
we
can
define
our
containers
that
we
want
to
run
on
on
our
edge
node
and
the
edge
side,
but
we
really
don't
need
the
whole
control
plane
of
the
kubernetes
to
do
that.
B
Of
course,
if,
if
you
go
into
into
this
direction,
you
will
need
still
to
to
do
some
some
provisioning
on
your
own.
So
so
you
still
can't
get
away
from
from
the
control
plane
right
either
you
will
do
it
manually,
so
you
will
be
the
control
plane
that
will
install
things
and
and
take
care
of
things,
but
in
in
most
most
cases
you
will
use
something
as
something
like,
ansible
and
or
ignition
to
to
do
a
basic,
node
provisioning
on
the
lower
level.
B
B
B
So,
first
one
that
we'll
mention
here
is
eclipse
honor,
which
tries
to
to
define
a
connectivity
layer
for
iot
devices
connecting
to
the
to
the
cloud
to
the
cloud
it
tries
to
define,
define
a
commonly
used
communication
patterns
between
the
the
the
devices
and
and
and
the
cloud
workloads
in
terms
of
sending
telemetry
data
from
the
device
to
the
cloud
and
sending
commands
and
controlling
controlling
these
these
devices.
From
from
the
cloud.
B
B
B
So
so
we
want
to
deal
with
the
device
state,
the
current
state
or
the
desired
state,
and
provide
provided
with
the
apis
that
it
can
do
it
in
a
similar
way
in
a
similar
way
of
how
it
it
would
do
it
for
any
other
kind
of
like
a
web
resource
right.
So
eclipse
detail
is,
is
a
project
that
that
defines
the
digital
twin
in
this.
In
this
context,
and
the
final
piece
of
puzzle
here
is,
is
how
we
actually
manage
all
these
devices
connected
to
the
cloud
right.
B
You
know
in
a
in
a
secure
in
a
secure
fashion
and
one
thing
to
to
tie
all
these
projects
together
is
something
what
we
call
the
cloud
to
edge
package.
So
each
of
these
projects,
like
horno,
dito
and
hogbit
all
have
have
their
own
helm
packages,
so
so
they're
really
very
easy
to
install
in
in
the
kubernetes
environment,
but
we
also
defined
a
cloud
to
edge
package
which,
with
basically
fun
command,
as
you
can
see
on
this
screen,
you
can
install
the
the
whole
cloud.
B
Iot
platform
consists
consisting
of
these
projects
all
configured
to
work,
the
work
together
in
in
the
in
the
coordination,
and
we
have
a
lot
of
a
lot
of
so
so,
if
you
look
at
it,
look
at
it
like
this.
It's
it's
positions
as
a
as
a
cloud
platform
right,
but
more
and
more
we
we're
discussing
at
how
we
can
bring
some
of
these
functionalities
closer
to
the
edge
and
make
a
make
a
more
more
more
edge
edge
style
deployment
of
of
these
functionalities
in
different
environments.
B
But
this
is
something
that
that
will
probably
talk
talk
about
in
the
future
or
talk
about
during
our
our
regular
course.
So
this
is
again
the
call
out
to
to
to
join
our
regular
meetings,
which
are
happening
every
other
wednesday.
We
have
two
different,
two
different
time
slots,
one
more
appropriate
for
for
a
western
world
for
for
us
and
one
more
up,
more
adjusted
for
for
the
apex,
so
that
everybody
can
can
have
their
own
their
own
appropriate
time
slot.