►
From YouTube: Kubernetes WG IoT Edge 20181123
Description
November 23 2018 meeting of the Kubernetes IoT Edge Working Group - demo of Fog Atlas https://fogatlas.fbk.eu/
B
C
C
We
are
basically
working
on
distributed
computing
and
on
the
cloud
to
see
continuum
from
a
research
point
of
view.
In
particular,
we
are
part
of
a
bigger
resource
center
that
is
called
the
foundation
bruno
kessler.
We
are
located
in
the
north
part
of
italy,
a
near
venice
video
in
india,
but
then
you
need
a
demo.
You
will
see
a
map
and
you
will
see
exactly
where
we
are
located.
C
D
C
A
automatic
or
semi-automatic
way,
and
you
should
also
be
able
to
model
the
workload
and
intelligently
smartly,
let
me
say,
place
that
workload.
Last
but
not
least,
this
is
still
experimental
as
a
feature,
but
we
introduced
it
in
fogatras
in
the
last
few
months.
The
idea
is
to
provide
also
a
sort
of
negotiation
over
the
resources
between
the
infrastructure
owner
and
the
developer
and
the
price
for
for
each
resource.
C
Focal
building
can
be
applied
in
different
verticals.
I
listed
here
some
of
these
verticals.
Probably
there
are
more.
What
I
will
say
now
is
that
we
focused
in
particular
on
two
verticals:
one
is
industry
4.0
and
the
other
one
is
a
smart
city
and
in
particular,
smart
city
is
the
vertical
that
you
will
see
during
the
demo.
C
C
E
C
In
different
venues,
in
particular,
they've
been
stuck
in
italy
and
the
fog
that
were
progressing
in
california
last
year,
and
we
wrote
also
a
couple
of
people,
some
forgotten
on
one
of
or
or
if
I
don't,
if
I
recall
correctly
on
both
of
them,
the
knee
was
not
forgotten
but
foggy.
That
was
the
former
name
of
fugatos.
C
You
have
the
reference
if
you
wanted
to
check
them
here
to
the
to
the
two
papers.
The
current
the
trl
over
forgotten
is
four.
So
basically
we
tested
it
in
a
lab
environment,
but
we
are
a
pilot
that
is
ongoing
with
an
industry
here
in
a
hidden
italy,
in
the
context
of
industry
4.0
and
for
the
future.
We
plan
to
for
sure
finalize
and
enhance
some
functionalities,
in
particular
the
ones
related
with
the
usability
and
front-end
and
to
experiment
to
to
improve.
I
mean
the
trl.
E
C
B
Yeah:
okay,
let's
start
with
the
demo,
but
before
give
me
a
couple
of
minutes
to
give
you
a
quick
introduction
on
the
context.
The
context,
as
I
said,
but
studio,
is
the
one
of
smart
placement.
Basically,
for
that,
with
focus
for
atlas,
we
are
trying
to
optimize
the
usage
both
of
the
physical
infrastructure,
but
also
you
try
to
respect
traditional
but
more
important,
non-traditional
requirements
imposed
by
the
application
developer
or
the
application
provider.
B
This
is
the
this
is
the
picture
that
summarize
the
infrastructure.
As
you
can
see,
we
use
this
infrastructure
to
do
experiments
and
to
do
demos,
and,
as
you
can
see,
we
have
five
regions.
Five
different
reasons:
each
region
represents
one
kubernetes
worker
node
or
an
aggregation
of
many
kubernetes
workers.
They
can
be
virtual
machine
hardware
or.
B
We
classified
the
region
in
three
years,
but
fogata
supports
also
more
more
tiers
and,
as
you
can
see,
the
tiers
are
used
to
classify
the
computational
resources
that,
as
you
can
see
on
the
top
are
higher
and
they
decrease
as
soon
as
we
reach
the
edge.
Also,
we
can
note
also
the
links
here.
We
have
the
links
that
connects
the
region
interconnects
the
region
at.
B
Of
course,
high
usually
have
high
bandwidth
and
low
latency,
but
instead
the
links
that
interconnect
the
edge
to
the
cloud
usually
have
low
bandwidth
and
high
latency.
Finally,
we
have
we
have
camera
that
are
directly
attached
to
the
region
that
are
that
are
at
the
edge
in
the
edge.
Here
we
will
see
the
deploy
of
a
particular
application
that
is
composed
by
three
microsoft.
Microservices.
B
Provide
a
specific,
specific
role
on
a
big
application,
so
we
have
a
chain
of
microservices.
If
you
look
at
the
picture
on
the
right,
we
have.
The
green
box,
for
example,
is
a
could
be,
could
be
a
microservice
that
extract
image
of
image
from
a
video
stream
of
a
face
of
or
of
a
plate
of
a
car
plate.
The
yellow
one
could,
for
example,
recognize
the
plate
or
the
face,
and
the
red
one
could
provide
some
analytics
or
machine
learning
or
anything
anything
that
does
not
need.
B
Then
that
does
not
need
the
street
strictly
require
a
strictly
network
requirement
towards
towards
the
endpoint.
That
is
the
camera.
We
classified
the
application
that
you
will
see
deployed
on
the
infrastructure
in
two
categories.
The
first
one
is
the
traditional
cloud
native
application
that,
in
this
application
we
does
not.
We
do
not
provide
a
requirement
on
the
network,
but
only
computational
computational
requirements
and
later
you
will
see
also
a
deployment
of
iot
and
data
centric
application,
in
which
we
provide
a
specific
requirement.
B
B
Yeah
and
the
the
green,
the
green
one
has
a
small
requirement
in
term
of
basically,
the
color
of
the
box
represents
the
computational
record
requirements.
While
you
will
see
later
the
capital
letter
inside
the
box
represents
the
requirement
of
networking
between
the
containers
between
the
micro
services.
B
Okay,
what
we
see
in
the
demo,
you
will
see
a
first
phase
in
which
we
will
deploy
a
traditional
application.
Three
traditional
application
composite
each
one
by
three
microservices
and
one
of
these
microservices
needed
to
connect
to
a
camera
camera
one
camera
two
and
camera
three
that
are
directly
connected.
If
you
remember
the
picture
before
that
are
directly
connected
to
region,
vela,
meziano
and
povo,
and
you
will
see
that
all
the
microservices
will
be
deployed
on
the
cloud.
B
While,
on
the
second
phase,
we
will
deploy
an
iot
centric
application
specifying
the
requirements,
the
network
requirements
between
each
component,
and
you
will
see
that
in
this
case,
all
the
microservices
will
be
distributed
on
the
infrastructure.
You
will
see
also
that
hard
constraint,
like
the
one
of
latency,
is
achieved
in
a
in
a
specific
and
particular
case.
B
B
B
Is
an
application
composed
by
many
microservices
and
currently
is
running
on
the
cloud
region,
but
to
avoid
the
complexity,
I
will
disable
the
listing
of
these
components
on
the
dashboard,
so
we
will
concentrate
on
on
the
components
that
are
specific
of
the
use
case.
As
you
can
see,
we
have
this
icon
representing
the
three
tier
we
we
showed
before,
and
we
can
see
that
the
in
these
three
heads
velar
museum
and
povo,
we
have
cameras,
we
simulate
cameras
connected
to
to
these
specific
regions.
B
B
B
Okay.
So
now
I
want
to
deploy
iot
centric
application.
In
this
case,
we
are
submitting
to
the
systems
the
deployment
requests
that
are,
that
are
just
a
representation
representation
of
the
of
the
microservices
chain
specifying
inside
also
the
network
requirements
that
have
to
be
respected
between
all
the
components
and,
as
you
can
see,
for
example,
for
camera.
B
Two.
We
have
that
the
small,
the
the
micro
service
that
have
small
computing
requirements
is
deployed
on
this
small
on
this,
this
node
at
the
edge,
also
because
it
has
high
higher
network
requirement
in
term
of
bandwidth
and
latency
towards
the
camera
that
is
connected
to
these
to
these
to
this
region.
That
is,
camera
two.
The
intermediate
component
is
deployed
on
trento.
That
is
the
intermediate
region.
B
B
B
B
Okay,
so
just
to
complete
the
demo,
we
will
deploy
a
specific,
an
additional
final
latest
application,
with
a
specific
requirement
of
latency
between
the
first
component
within
the
camera
and
the
first
microservice,
and
also
the
first
to
the
second
think
about
of
an
example
of
this
application
could
be.
I
don't
know,
a
gaming,
a
gaming
application
at
the
edge
in
which
we
have
a
first
container
that
managed
the
streams
that
come
come
from
the
camera
and
the
second
container.
B
B
B
B
F
So
one
one
question:
I
don't
know
if
you
can
open
a
couple
of
the
deployments
to
show
a
little
bit
about
where
what
kubernetes
constructs
you're
using
in
the
in
the
services
and
routing
to
get
your
your
network
priority
design,
like
I
understood
the
I
understood,
sort
of
the
narrative
of
it,
but
where?
What
does
that
look
like
in
kind
of
yaml?
B
B
Yes,
okay:
this
is
a
deployment
request
that
we
send
to
the
focus
api
in
this
deployment
request.
Basically,
we
specify
data
flows
between
each
between,
for
example,
this
data
flow
in
this
data
flow,
we
specify
the
network
requirements
between
the
camera
and
the
destination
might
be
the
destination
microservice,
and
here
we
specify
the
bandwidth,
and
here
we
specify
the
latency.
So
we
have
data
flows
are
basically
the
edge
of
a
graph.
Okay.
B
B
F
And
then,
how
does
the?
How
does
the
route
with
the
the
requirements
for
network
that
you
have
described
in
the
first
graph
for
the
cameras?
Are
they?
How
so
are
the
services
using
the
the
traits?
I
mean
the
the
constraints
for
using
certain
services
with
like
inside
one
of
the
microservices,
that's
calling
so
your
source
to
destination.
B
F
C
C
C
C
F
I
think
so
so
that
the
alternatives,
the
way
the
the
graph
kind
of
resolves
with
those
alternatives,
is
you're
you're,
assuming
you
know
in
advance
the
performance
of
the
links
exactly
and
you
code
those
into
the
graph
as
opposed
to
something
that
is
more
runtime
or
dynamic,
where
it's
testing
multiple
edges
in
the
graph
to
see
which
one
is
the
the
best.
At
that
time.
Okay-
and
I
know
I
know
again
like
I've,
said
in
in
other
presentations-
this
is
a
early
stage.
B
That's
correct:
okay,
basically,
each
region
can
be
composed
can
be
composed
by
one
kubernetes
worker,
but
in
a
region
we
could
also
have
many
kubernetes
workers
that
are
interconnected
in
the
same
layer,
3
network,
okay.
So
basically
what
fog
atlas
does
is
to
schedule
and
to
place
the
container
inside
the
region?
Then
it
leaves
to
the
to
the
kubernetes
scheduler
decide,
which
is
the
specific
node
where
these
microservices
should
be
should
be
deployed.
C
C
Let
me
also
add
that
in
this
way
I
mean,
as
it
is
implemented
now,
fogatras
is
more
or
less
a
sort
of
wrapper
of
kubernetes.
That
means
that
we
wrap
the
scheduler
of
bernates
and
the
api
bernatus.
With
the
I
mean
something
that
add
this
distributed
functionality
in
terms
of
ability
to
handle
network
requirements.
C
B
B
D
C
C
D
D
D
D
But
if
you
do
some
kind
of
features
like
getting
some
image,
processing-
or
I
don't
know-
maybe
other
things
using
the
camera,
but
those
services
are
deployed
using
kubernetes.
If
you,
if
you
appear
to
have
a
small
network
issues,
you
might
I
mean
that's.
My
experience
see
that
those
services
might
be
removed
from
the
from
the
node.
So
do
you
plan
to
I
mean.
C
C
So
at
the
moment,
in
this
architecture
we
have
the
kubernetes
master
that
is
running
on
icloud.
So,
of
course,
if
something
happened
on
something
happens
on
the
link
between
the
cloud
and
the
edge,
the
kubernetes
master
is
no
more
able
to
to
talk
with
with
the
community,
the
kubernetes
workers
and
the
other
services.
C
In
some,
let
me
say
smart
way,
for
example,
in
order
to
keep
a
cache
of
the
video
streaming
that
is
collecting
from
the
camera,
then
probably
everything
is
working
because
I
don't
know
10
minutes
later,
when
the
network
leaner
comes
back
on
the
remote
part
of
the
application,
the
microservice
that
is
running
on
the
edge
can
again
connect
with
the
microscope
that
is
running
in
cloud,
and
so
they
can
start
exchanging.
The
water
was
in
cash.
C
Salem
education
is
not
true
for
the
kubernetes
services,
and
for
this
reason
what
we
are
thinking
about
we
didn't
implement.
Yet
this
is
to
distribute
all
the
kubernetes
so
to
have.
Basically
a
sort
of
I
mean
refrigerated
bernat
is
where
we
have
a
yes,
a
master
in
the
cloud,
but
probably
another
master
on
the
middle
tier.