►
From YouTube: Kubernetes WG IoT Edge 20190717
Description
July 17 meeting of the Kubernetes IoT Edge working group - discussion of LF Edge glossary, presentation on an MQTT based edge broker concept
A
A
B
Yeah
I
have
not
attended
very
often
so
for
the
rest
of
the
fox
on
the
call
my
name
is
jeremier.
I
have
been
a
driver
for
over
seven
years
now,
so
I'm
part
of
the
red
hat
company-
and
I
am
a
product
manager
for
edge
computing
at
red
hat.
So
my
main
interest
is
to
learn
what
kind
of
use
cases
you
guys
are
seeing
what
kind
of
needs
you
have
from
kubernetes
and
try
to
contribute.
Also
from
our
perspective.
B
C
E
Yeah
sure
sure
that's
great
so
for
background
when
we
publish
well.
So
let
me
tell
you
about
the
state
of
the
edge
first.
The
state
of
the
edge
is
a
group
that
I
co-founded,
that
is
sponsored
by
vendors,
but
it's
vendor
neutral
and
its
mission
is
to
publish
vendor
neutral
research
on
edge
computing,
and
we
published
our
first
report
last
year.
In
june
it
was
the
state
of
the
edge
of
2018.
E
E
E
So
if
the
working
group
has
a
topic
that
they're
passionate
about
that
they'd
like
to
get
out
in
front
of
there,
that
you
know
represents
a
point
of
view
coming
out
of
this
group,
I'm
happy
to
help
shepherd
that
through
that
process,
it's
completely
optional,
but
I
think
it
would
be
good
to
express
this
group's
viewpoint
and
also
promote
this
group's
work.
So
that's
the
stay
of
the
edge
and
I
would
need
to
get
that
essay
sometime.
You
know
before
the
end
of
july.
E
You
know
most
of
them
following
sort
of
the
principles
of
open
source.
You
know
trying
to
encourage
people
to
do
it
based
on
you
know,
knowledge
and
meritocracy,
but
we
may
in
fact
make
that
a
qualification
for
projects
to
reach
a
certain
stage
as
to
is
to
demonstrate
conformance
to
the
lexicon
and,
of
course,
if
people
disagree,
that's
the
whole
point
of
an
open
source
project
there's
a
mechanism
by
which
you
can
do
it.
So
with
that
background,
I
welcome
contributions
from
this
group
to
the
glossary.
E
And
I
would
like
to
encourage
this
group
to
consider
adopting
it
as
appropriate.
You
know,
as
you
write,
white
papers
and
stuff
and
again
it
would
be
a
two-way
street.
So
if
there's
terms
or
phrases
that
you
feel
need
to
be
defined
differently
or
need
to
be
defined
at
all,
we're
happy
to
incorporate
that,
and
you
know,
vice
versa,
we're
happy
to
get
feedback
on
the
language
of
the
use,
but
I'd
love
to
see.
E
A
E
E
That's
probably
the
best
first
step,
because
then
you
know,
as
as
this
group
goes
to
look
to
publish
a
white
paper.
I
can
help
channel
resources,
review
the
white
paper
and
identify
anything
that
we
think
you
know.
Maybe
the
glossary
should
benefit
from
or
contribute
to,
and
also
just
a
way
to
conduit,
create
a
relationship
between
between
the
different
organizations
that
I'm
a
part
of.
D
E
A
E
A
D
A
D
I
don't
think
it's
it's
nothing
new
for
people
who
know
brokers,
but
for
some
reason
I
think
the
the
the
ecosystem
just
seems
to
be
more.
Around
kind
of
you
know:
istio
style
service
to
service
type
communication,
but
once
you
are
running
an
mqtd
broker
of
any
kind
in
in
a
cluster,
you
have
this
great
opportunity
on
the
edge
to
talk
between
between
devices
locally
between
applications
within
the
cluster
between
applications
and
local
devices.
Right,
it's
just
a
running
completely
sort
of
offline,
just
as
a
land-based
broker,
is
a
useful
thing
unto
itself.
D
What
I
wanted
to
do
was
then
take
the
mosquito
broker
and
use
the
feature
it
has
for
bridging,
so
that
essentially
a
subset
of
the
namespace
routes
to
our
cloud
iot
service,
and
this
the
syntax
for
this
is
not
super
well
documented.
So
it
took
me
quite
a
bit
of
trial
and
error
to
kind
of
come
up
with
the
right
syntax.
So
the
idea
is
that
these
local
broker
name
spaces,
which
I
prefix
all
of
them,
with
jcp
route
to
our
device,
specific
topics
on
our
managed
cloud
service.
D
D
D
The
standard
mosquito
container
so
totally
unmodified
not
custom
as
pulled
from
kind
of
docker
hub,
but
the
other
is
my
custom
refresher
and
then
they
share
a
volume
where
the
mosquito
configuration
is
and
the
other
kind
of
interesting
thing.
I
I
figured
out
how
to
do
in
here.
This
is
just
kind
of
kubernetes.
D
D
It
uses
customize
to
take
some
of
the
you
know,
project
specific
overlays
and
patch,
that
into
the
standard
deployment
enamel,
as
well
as
generate
the
config
map
with
the
device
private
key.
So
that's
an
overlay
for
those
who
haven't
used
customize
it.
It
works
on
kind
of
base
layers
and
then
modification.
D
D
A
D
D
D
So
then,
one
of
these
applications,
instead
of
using
a
native
mqtt
client
it
can
use
you
know
the
k-native
eventing
construct
to
subscribe
to
a
certain.
You
know,
subscription
type
for
mqtt,
that's
sort
of
a
it's
gonna.
It's
a
whole
lot
of
machinery
to
basically,
you
know,
create
one
message
type
to
another
message
type,
but
but
I
think
that
way:
it'll
it'll,
let
people
who
are
totally
unfamiliar
with
mqtt
who
are
coming
at
it
from
a
k-native.
D
A
A
D
A
Well,
I
I
I
was
wasn't
thinking
about
the
k-18,
but
yeah
definitely
there's
there's
a
group
of
people
were
working
on
all
kind
of
bridging
bridging,
but
what
I
meant
is
is
more
like
these
direct
proxies
for
different
kind
of
traffic
for
http
or
or
mqtt
over
to
over
overlay
mqp
network
and
and
and
bridging
the
services
between
the
the
clusters
and
and
things
like
that.
So
similar
thing
that
that
we
already
presented
here
in
the
concept
stage.
So
you
know
trying
to
make
that
more
consumable
right.
A
Yeah,
but
so
don't
think
about
the
broker
topic
you
can
think
about
the
the
you
know,
general
aim
qp
addressing
which
can
be
sure
that
directly
services,
or
or
or
whatever
yeah
that's
cool,
yeah,
so
yeah,
maybe
yeah,
there's
a
way
to
to
do
something
in
common,
because
I
think
it's
a
it
started
targeting
basically
the
same
a
similar
use
case.
You
know.
A
D
D
D
I
think
it
comes
up
here.
I
definitely
think
that
the
the
flavor
of
multi-cluster
that
I
call
many
many
small
clusters
versus
a
few
large
clusters
right,
I
mean,
I
think,
a
lot
of
a
lot
of
typical
multi-cluster
kubernetes
interested
parties
come
to
multi-cluster
from
the
context
of
I'm
running
five
globally
distributed
large
clusters,
and
I
need
to
do
a
global
rollout
of
software
across
my
five.
D
You
know
three
to
five
big
clusters,
whereas
you
know
edge
iit,
like
we
often
talk
about
the
chick-fil-a
case,
they've
got
2
000,
tiny
clusters,
and
so
the
challenges
around
multi-cluster
are
tuned
or
tweaked,
but
largely
common.
So
we
don't
we
don't.
We
don't
in
the
working
group,
try
to
usurp
any
of
the
multi-cluster
sigs
sort
of
charter,
but
we're
looking
at
and
interested
in
if
people
have
thoughts
around
kind
of
the.
Where
does
this
need
to
be
different
for
edge
or
where
does
edge,
add
additional
kind
of
consideration?
F
F
F
B
Those
clusters
are
completely
standalone.
What
you
need
is
you
need
unified
management
and,
ideally
automated
get
ops
model
when
you're
managing
those
environments,
but
as
for
federation
and
some
service
chaining
or
something
between
those
locations.
It's
not
really
requested,
at
least
in
this
large-scale
amount
of
use
cases.
F
So
they
are
like
fully
independent
standalone
clouds
and
and
yeah
the
orchestration
that
we've
done
has
been
more
around.
You
know
kind
of
infrastructure.
Orchestration,
like
you
know,
I
I
you
know,
you
know
getting
identity
orchestration.
You
know
for
user
id
and
logins
common
across
on
managing.
You
know
in
openstack
managing
glance
images
across
them
all.
D
A
B
Correct,
I
would,
I
would
expand
on
that.
This
usually
is
being
solved
by
layering
the
configuration
templates
so
that
you
have
some
global
configuration
and
then
in
another
layer,
you're
specifying
for
specific
region.
And
then
you
have
another
layer
of
configuration
which
is
specific
to
a
location
which
you
need.
So
that
is
very
often
done
by
layering.
The
configuration
files.
D
The
other
interesting
pattern-
and
I
have
I
lost
some
of
the
work
on
my
laptop-
that
I
spelled
coffee
on,
but
I'll
I'll
go
back
and
recreate
some
of
it
is
the
kubernetes
supports
oidc
as
a
as
a
source
of
authorization
and
identity
for
for
clusters.
So
you
can
set
all
of
your
clusters
to
recognize
the
same
issue
or
so
the
demo
I
built
was
using.
D
F
D
Yeah,
that's
certainly
one
of
them,
so
we
have
a
managed
service
that
goes
under
both
firebase
auth
and
now
we
have
it
called
a
custom
or
cloud
identity
platform
on
google,
but
it's
the
same
back
end.
It
started
as
firebase
auth
and
it
was
built
to
allow
people
to
build.
You
know
mobile
applications
to
make
it
really
easy
to
log
in
with
x,
y
or
z,
but
then
it
becomes
its
own
issuer.
D
D
Another
observation
on
the
multi
cluster
so
that
I'm
seeing
you
know
chick-fil-a
does
this
where
we
have
a
a
couple
projects
where
I
think
the
name
now
goes
under
anthos
conflict
management,
but
the
idea
of
using
sort
of
git
ops
for
declarative
policy
across
multiple
clusters.
So,
let
me
see
was
it
was
it
haramir.
D
The
other
thing
I'm
seeing
is
that
in
general,
people
are
looking
at
a
namespace
as
a
global
namespace
for
authorization,
meaning
if
you
define
a
namespace,
you
define
it
on
all
of
your
clusters
and
it
represents
a
certain
kind
of
role,
workload,
etc.
So
if
it's
an
edge
cluster,
that
name
space
might
be
running
workloads
that
are
communicating
with
equipment.
That
is,
you
know,
mission,
critical
or
sensitive
at
every
installation
where
that
edge
is
installed,
but
that
you,
wouldn't
you
wouldn't
end
up
you.
A
B
A
Want
to
second
this
yeah,
I
think
it's
that
should
be
it.
I
think,
yeah
we
had
a
good
attendance
despite
I,
I
wasn't
expecting
this
this
much
people.
I
said
it
at
the
beginning
at
the
in
the
middle
of
the
july,
but
it's
good
that
the
interest
is
here
so
yeah.
Let's
keep
on
in
touch
on
the
slack
around
all
the
topics
that
everybody
is
interested
in
and
and
see
you
in
two
weeks.