►
From YouTube: Deep Dive: 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
Deep Dive: Kubernetes IoT Edge WG – Cindy Xing, Huawei, Dejan Bosanac, Red Hat, Preston Holmes, Google, & Steve Wong, VMware
What are the workloads that are unique or common to running Kubernetes on the edge? How do they take advantage of existing Kubernetes features, or require refinements and new capabilities? We’ll dive into the use cases, functional requirements and unique challenges of deploying IoT and Edge workloads on Kubernetes and discuss the technical challenges involved today. With the goal of addressing the challenges, we’ll have a panel discussion to share views and ideas on potential platform improvements. The session will close with audience participation and Q&A.
To learn more: https://sched.co/HSCE
A
We're
going
to
get
started
here,
you
came
to
the
edge
an
IOT
working
group,
deep
dive.
We
had
another
session
yesterday
that
was
very
well
attended.
I
see
a
lot
of
you
familiar
faces,
so
I
think
some
of
you
carried
over.
But
if
you
didn't
I'm
gonna
go
into
a
little
intro,
very
rapidly,
probably
not
covering
and
or
explaining
those
slides
and
I'd
encourage
you
to
go.
Look
at
the
recording.
That
said,
we've
got
four
presenters
here
from
the
edge
in
IOT.
A
Why
don't
you
guys
stand
up
and
turn
around
and
they'll
take
the
stage
in
a
moment
and
I'll
get
started,
so
the
agenda
is
we'll,
have
an
intro
will
cover
edge
workloads,
some
challenges
that
you
would
typically
incur
with
these
workloads
today
and
at
the
end
QA.
If
it's
anything
like
the
intro
session,
we're
going
to
have
a
lot
of
interest
in
QA,
we'll
probably
move
it
out
into
the
hallway
so
that
we
don't.
We
were
polite
to
the
next
speaker
here,
so
the
book
book
ended
these
talks
with
very
little
gap
in
between
oops.
A
A
One
of
the
things
we
covered
yesterday
is
that
kubernetes
has
a
lot
of
similarities
to
what
people
are
trying
to
accomplish
in
the
edge
space,
in
that
it's
a
control
plane
made
for
controlling,
more
or
less
IT
workloads
in
a
commercial
data
center.
It
featured
a
standardized
API
with
tools,
and
it
instigated
a
very
rich
tool
chain
of
collateral
things
for
metrics
monitoring
that
could
potentially
be
valuable
in
the
IOT
space,
but
the
IOT
space
is
a
little
different
in
that
many
of
these
are
resource
constrained,
they're
not
close
to
infinitely
expandable.
A
Like
the
view,
you
might
think
you
have
in
a
public
cloud.
They
potentially
have
very
special
networking
requirements
which
we'll
cover
later
on
in
the
presentation,
and
they
have
challenges
of
unattended
and
disconnected
operation.
Another
thing
that's
different.
You
know
there
you've
got
potentially
many
more
of
these
very
small
things
than
you'd
have
in
a
traditional
IT
data
center.
Setting
that
said,
I'll
bring
up
Preston
Holmes
from
Google
and
I'll.
Let
you
introduce
yourself.
C
So,
first
of
all,
it's
the
the
workloads
related
to
the
data
ingestion
and
pre-processing.
So,
basically,
coming
from
the
IOT
use
pace,
use
cases,
you
have
a
lot
of
devices
producing
data,
so
you
know
how
you
on
board
these
devices
to
the
cloud
and-
and
how
do
you
you
know,
gather
these
information
from
the
different
kind
of
sensors
using
different
kind
of
protocols,
and
you
know
and
how
you
basically
normalized
normalized
the
data
you're
reading
from
different
different
kind
of
devices.
C
C
So
so
so
we
need
to
have
some
kind
of
workloads
that
that
will
use
use
annual
field
protocols
to
get
data
from
the
wire
and
and
and
actually
onboard
this
device
to
IP
enabled
world,
so
so
so
getting
in
getting
them
to
some
kind
of
usually
some
kind
of
standardized
messaging
protocols
like
MQTT
or
nqp
or
or
HTTP
to
be
being
able
to
to
be
processed
and
sent
and
further
on
on
to
the
cloud.
But
even
if
you,
if
you
get
that
data,
you
know
you
know
in
a
consumable
way
by
the
cloud.
C
Do
you
usually
want
one
want
to
do
some
kind
of
structuring
of
the
data,
giving
it
some
some
kind
of
semantics
and
in
some
some
kind
of
meanings?
So
these
kind
of
workloads
are
there
to
basically
try
to
to
you
know,
convert,
although
all
those
different
kind
of
protocols,
the
different
kind
of
meanings
in
some
kind
of
meaningful
way
for
a
particular
ayah
T
edge
edge
solution.
C
So
that's
where
we're
different
different
kind
of
open
source
projects
like
water
and
standards
like
LW
m2m,
coming
to
play,
trying
to
make
sense
of
the
readings
and
end
of
the
data
we're
collecting
collecting
on
the
edge.
On
the
other
side,
we
will
talk
a
bit
more
about
the
challenges,
but
usually
you
don't
want,
maybe
to
send
all
the
data
back
to
the
cloud.
So
you
want
to
do
some
kind
of
pre-processing
there
so
basically
trying
to
do
some
kind
of
a
streaming.
C
For
example,
the
you
know
you
don't
want
to
send
a
temperature
rating
every
couple
of
seconds.
You
want
to
send
it
in
an
event
when
the
temperature
temperature
actually
changed
so
so
these
kind
of
workloads
are
also
belong
closer
to
the
edge
trying
to
filter
whilst
the
mountains
they
and
create
meaningful
events
that
are
actually
useful
for
the
product
for
the
cloud
cloud
applications.
So
that
there's
something
also
that
you
know
people
usually
want
to
do
to
move
closer
to
the
age.
C
And
finally,
you
want,
to
you
know,
take
some
of
this
data
in
a
proper
metadata
metadata.
There
so
maybe
add
some
some
more
information
that
are
not
provided
by
the
by
the
by
the
underlying
hardware,
so
putting
things
like
location
where
the
data
was
generated
or
all
right,
the
entity
of
some
kind
and
and
put
some
some
security
tokens
there,
just
just
that
the
sources
of
the
data
can
be
properly.
You
know
properly
recognized
there,
so
we
are
talking
about
all
these
device,
these
things
and
you
can
see
in
the
Box
down
down
downstairs.
C
This
is
nothing
new
and
only
concern
when
you
wanna
run
something
like
this
inside
of
the
kubernetes
and
other
system.
Is
that
you?
You
know
you
can
always
need
to
have
in
mind
that
these
kind
of
solutions
are
our
solutions
for
a
temporary
or
floating
or
data
or
temporary,
buffering
go
of
data
because
usually
resources
on
the
edge
is
problematic
and-
and
you
know,
storage,
for
example-
is
one
of
those
resources.
C
C
So
the
node
that
have
appropriate
you
know,
GPU
hardware,
GPU
resources
and,
and
and
things
like
that,
so
with
this
I
would
wrap
up
about
like.
Why
would
you
like
to
run
something
on
the
edge
and-
and
you
know
some
brief
descriptions?
All
of
you
know
what's
available
today
in
kubernetes
to
do
that.
So
I
will
you
know
hand
over
to
press
down
again
to
talk
about
some
of
the
challenges
that
can
be
solved.
B
Thank
you.
So
these
are
I'm
going
to
talk
about
just
a
couple
features
of
something
that's
already
available
in
built-in
to
kubernetes.
That
I
think
ends
up
being
more
important,
often
in
an
edge
environment,
and
this
isn't
meant
to
be
comprehensive.
I'd
rather
I,
just
sort
of
picked
a
few
things
to
dive
a
bit
deeper
into
since
this
is.
B
Some
of
those
are
higher
priorities
than
others,
and
so
how?
What
what
levers
does
Cooper
know
does
kubernetes
give
you
to
sort
of
effect
the
the
prioritization
and
there's
there's
sort
of
two
main
categories.
So
these
are.
These
are
things
that
are
out
there
in
kubernetes,
but
I,
don't
think
get
as
much
attention
in
the
average
cloud
cluster
but
they're
there
so
for
the
first
is
prioritization.
This
allows
you
to
sort
of
rank
the
the
priority
class
of
different
workloads.
B
B
So
so
all
of
these,
I
think
you
know,
kubernetes-
has
never
been
accused
of
being
super
simple
and
that's
why
a
lot
of
these,
these
I,
think
in
an
edge
environment,
need
more
careful
examination
of
how
they
apply.
The
second
of
these
is
is
called
quality
of
service
quality
of
service,
isn't
as
something
you
actually
apply
explicitly
in
any
pod
spec
or
any
llamo.
It's
a
it's
an
inferred,
implicit
quality
of
service
level.
These
come
from
the
way
you
actually
ask
for
resources
in
a
given
pod.
B
So
there's
these
three
levels-
guaranteed
burstable
and
best
effort
guaranteed
happens
when
you
explicitly
declare
that
every
container
in
a
pod
has
both
a
memory
request
and
a
limit
and
a
CPU
request
and
limit.
So
when
you
exactly
sort
of
pin
those
resource
requests,
that's
called
a
guaranteed
quality
of
service.
The
second
one
is
burstable.
This
is
when
the
pod
is
not
going
to
meet
this
guaranteed
criteria,
but
at
least
one
of
the
containers
in
the
pod
has
a
memory
or
CPU
request.
B
So
this
is
sort
of
when
you're
asking
for
some
portion
of
the
pod
to
have
certain
requirements
be
met
and
then
best
effort
is
when
really
no
no
containers
in
the
pod
can
have
any
sort
of
memory
or
CPU
limits
right.
So
this
is
well.
It
will
sort
of
fit
in
between
the
cracks
and,
what's
interesting
is
that
the
prioritization
tools
and
the
quality
service
implicit
label
are
actually
orthogonal
to
each
other.
B
So
when
the
scheduler
is
looking
to
preempt
pods
by
looking
across
nodes
to
see
where
there
are
some
lower
priority
pods,
it
does
not
consider
quality
of
service.
So
this
is
I.
Think
to
me
sort
of
deep,
deep
kubernetes
level
if
you're
really
trying
to
figure
out
you're
in
an
edge
environment
and
you're
saying
say:
we're
in
a
retail
location
and
you're
running
some
point-of-sale
services.
B
Those
you
want
to
be
very
high
priority,
high
quality
of
service
and-
and
you
may
have
some
sort
of
inventory,
updating
workload
that
if
it
has
to
be
preempted
and
move
to
later
in
the
day
or
when
the
time
is
quieter.
You
certainly
don't
want
that
workload.
Kind
of
causing
churn
on
your
your
high
priority
workloads.
B
B
So
there's
two
parts
of
this:
one
is
policies
and
one
is
related
to
bandwidth.
So
policy
really
deals
with
permissions
policy
deals
with
what
traffic
is
allowed.
This
is
also
important
in
the
edge.
If
you
want
to
restrict
certain
data
types
from
ever
egressing
from
the
cluster,
you
would
want
to
use
network
policy
again.
It's
it's
applied
via
a
network
plug-in
and
kubernetes.
It's
based
on
the
network,
external
api's,
meaning
you're
you
wouldn't
use
since
pods
can
move
around
you're
not
going
to
use
sort
of
pod
level.
Ips
you're
you'd,
always
reference.
B
The
the
cluster
external
API
is,
and
for
anyone,
who's
dealt
with
sort
of
firewall
rules.
It
looks
kind
of
similar,
so
I
have
a
snippet
here.
So
the
idea
is
that
you
have
both
ingress
and
egress
as
types
of
policy
and
for
each
of
those
you
can
control
source
and
destination
where
source
and
destination
might
come
from
something
like
a
label
match
criteria.
So
if
you
want
to
restrict
certain
pods
can
only
send
data
to
other
pods
over
the
network
or
it
might
be
based
on
cider
and
address
ranges
for
IP
level
traffic.
B
So
the
network
policy
addresses
the
who
can
can
talk
to
what
the
other
is
bandwidth.
So
bandwidth
is
where
you're
going
to
limit
just
how
many
bytes
are
given
given
load
can
can
take
advantage
of
on
the
on
the
pipe
and
I've
put
this
sort
of
stack
together
to
show
that
the
way
bandwidth
management
is
affected,
kind
of
happens
at
multiple
levels,
so,
first,
the
lowest
level
is,
is
sort
of
the
Linux
kernel.
That's
dealing
with
IP
traffic
at
the
kernel
level.
B
There's
then,
a
Linux
tool
called
traffic
control,
which
is
able
to
set
limits
to
certain
Linux
Network
namespaces.
So
this
is
where
you
have
a
slightly
higher
order:
sort
of
grammar
for
being
able
to
apply
network
limits
at
the
Linux
network,
namespace
level.
You
then
have
the
container
networking
interface
so
the
the
way
that
kubernetes
knows
it
has
network
interfaces
available
to
it,
so,
whether
that
sort
of
different
NICs
in
a
machine
on
a
node
etc.
B
The
way
kubernetes
has
access
to
that
network
interfaces
through
the
cni
and
there's
a
bandwidth
plug-in,
and
then
that
plug-in
can
affect
bandwidth
limits
per
interface
or,
if
you
simply
enable
the
network
bandwidth
plug-in
the
essentially
the
control
plane
will
apply
pod
annotations
via
that
network,
plug
into
specific
pots.
So
I
have
a
little
bit
to
show
you
what
this
looks
like.
So,
if
you
simply
enable
it
on
a
interface,
you
can
say
enable
true.
B
This
will
allow
the
the
pod
annotations
to
work
which
I'll
show
in
the
next
slide,
but
you
can
also
specifically
limit
your
overall
bandwidth
to
a
specific
network
interface
at
the
cni
level
as
well,
and
so
this
might
be
applied.
If
you
have
multiple
network
interfaces,
let's
say
one
of
them
is
a
modem
applying
sort
of
point-to-point
networking
over
a
very
slow
satellite
or
cellular
link,
but
you
have
something
else
where
you
have
across
your
cluster
a
Ethernet
connected
to
services,
and
you
may
not
need
to
limit
that
network
bandwidth
on
that
network
interface.
B
If
you
are
having
sort
of
competing
workloads
and
you
want
to
prioritize
or
allow
restrict
certain
workloads
from
bandwidth
I
think
sometimes
this
is
most
relevant
from
a
from
a
protect.
Your
yourself
against
self
use
case
right,
so
I
think
many.
Many
things
that
go
wrong
in
clouds
and
computing
is
when
you,
you
accidentally
sort
of
Dass
yourself
or
you
accidentally,
have
a
bug
that
results
in
some
sort
of
runaway
Network
process
and
it
wasn't
malicious
and
there
wasn't.
You
know,
attack
here.
It's
just.
There
was
a
bug
that
you
you
got
yourself.
B
You
know
in
trouble
and
so
having
something
applied
to
the
pod
might
say:
look.
We
should
expect
this
workload,
never
to
need
more
than
a
certain
amount
of
bandwidth.
If
we
apply
this
annotation
and
we
have
the
container
networking
plugin
enabled,
then
we
know
that
this
will
essentially
act
as
a
cap
right.
B
One
thing
that
is
is
essentially
missing
from
from
this
kubernetes
space
is
the
ability
to
prescribe
a
cluster
wide
limit,
so
all
of
these
still
are
applying
per
node,
so
you
still
need
to
sort
of
do
the
bookkeeping.
Math
of
saying
well,
I
have
this
this
interface
in
this
interface
and
this
interface
on
these
nodes
and
then
I
might
have
these
workloads.
D
You
so
to
recap
what
we
talked
so
far
you
heard
about
why
we
are
doing
at
computing,
what
are
the
potential
user
scenarios
and
whether
kubernetes
can
can
be
used
already,
if
not
what
other
challenges
we
are
facing,
so
what
I'm
gonna
talk
to
you
later
next
is
about
what
about
beyond
kubernetes
our
way
already
mission
accomplished
or
not,
if
not.
What's
the
distance
I
think
for
kubernetes
is
a
cluster
resource
management
and
application
orchestration
tool?
D
Okay,
it's
an
infrastructure
and
framework,
but
from
a
computing
perspective,
the
I'm
listing
a
few
challenges
or
issues
here
think
about
in
the
data
center.
You
probably
have
tens
of
thousands
of
servers
in
a
dedicated
data
center,
a
single
location
or
maybe
across
rooms.
Ok,
but
at
the
edge
IT
computing
scenarios.
We
are
talking
about
hundreds
of
thousands
of
machines
or
even,
if
we
think
of
the
devices
it
can
be
millions
or
billions
of
devices
and
those
devices
and
nodes
are
geographically
located
in
all
kinds
of
locations.
D
D
Then.
We
also
talked
about
for
the
for
the
edge
scenario.
The
network
may
not
be
reliable,
because
the
network,
due
to
the
geographical
location,
the
network
can
be
connected
or
disconnected,
and
the
bandwidth
is
limited
as
well,
because,
as
I
said,
the
scale
is
big,
but
your
data
center
is
limited.
So
in
that
sense
we
would
think
about.
In
case
network
disconnected,
can
the
edge
node
continue
work
or
not,
as
you
all
know,
for
kubernetes
there's
a
part
or
no.
The
eviction
concept
so
couplet
keeps
on
reporting
the
heartbeat
to
the
master
node
every
10.
D
Second,
in
case
the
controller
thinks
it's
not
healthy,
then
your
part
will
be
affected
or
even
the
node.
The
concept
here
is
the
order.
Let's
say
the
goal
here
is
we
want
the
edge
node
can
be
autonomously
manage
itself
or
even
like
say
because
of
what
them
mentioned
earlier
due
to
the
latency
or
the
cost-benefit
perspective.
We
want
things
to
run
itself
at
the
edge
and
then
it
can
be
autonomous.
The
other
difference
for
ad
computing
versus
cloud
is
the
hardware
hitter
change
in
years.
D
Hardware
right
so
it
can
be
to
have
108
make
one
core
CPU
Raspberry
Pi,
2,
multi-core
multi,
gig
memory
servers.
We
are
talking
about
such
large
landscape
and
then
for
the
resource
constraint
devices.
The
can
you
run
docker
container,
darker
engine
and
couplet
on
it
think
about
a
darker
engine
itself
at
runtime.
It
can
take
a
hundred
make
already.
If,
for
me,
I
have
a
Raspberry
Pi.
It's
only
120
a
to
make
it's
already
used
up.
I
can't
do
anything.
Ok,
then
the
last
leap
are
not
list.
D
D
So
here
I
like
to
introduce
you
open
source
project
called
kuba
edge.
We
recently
announced
this
project
was
introduced
by
Huawei,
a
few
of
us
in
Seattle.
We
started
this
effort
and
then
we
have
a
open
sourced
recently
this
project,
the
the
main
idea,
is
we
plan
to
address
three
main
problems.
First
of
all,
is
the
network
reliability,
as
I
mentioned
earlier
in
the
network
between
edge
node
and
cloud,
is
unreliable
and
the
bandwidth
is
limited.
The
second
problem
we
try
to
address
is
we
want
the
edge
node
to
be
autonomous.
D
D
Just
to
share
you.
Some
status
for
the
for
the
open
source
coverage
has
two
parts.
One
is
in
the
cloud.
The
other
is
in
the
edge
on
the
edge
side,
we've
already
open
sourced
on
the
cloud
side,
because
we
have
to
separate
from
the
production
code
it
takes
a
while,
but
it's
gonna
be
open
sourced
very
soon.
D
So
in
this
slide,
you're
gonna
see
the
functionalities
of
Kubik
and
the
fundamental
architecture.
Let
me
first
address
the
functionality,
the
cooperage
support,
multi-tenant,
large
skill
of
distributed
and
node
edge,
node
registered
in
your
cloud
infrastructure,
and
you
can
manage
those
edge
nodes
remote
remotely
through
the
cloud
infrastructure.
D
Secondly,
the
agent
in
the
cottage
at
the
edge
side,
is
a
lightweight
agent.
At
this
point.
It's
about
10
to
20
megabyte
footprint,
so
obviously
you
can
run
on
the
120
or
256
Meg
resource
constraint.
Devices
are
at
node
and
if
you
use
it
on
your
server,
obviously
you
can
save
your
management
overhead
for
the
networking
infrastructure.
We
support.
Multiplex
connection
and
then
for
the
connection.
Basically,
they
use
WebSocket
to
build
the
connection
between
the
edge
node
and
the
cloud.
After
that,
the
connection,
health
and
heartbeat.
D
The
other
thing
I
want
to
call
out
is
we
have
a
store
on
the
cloud
as
well
as
on
the
edge
the
store
on
the
edge
and
the
cloud
side.
They
are
synced
together.
That's
a
way
for
us
to
address
the
autonomy
problem
in
case
when
the
network
is
disconnected
because
I
have
all
the
metadata
sing
down
from
the
cloud
to
the
edge
already.
So
all
the
business
logic
can
continue
work
on
the
edge
if
they
drill
deep
on
the
architecture.
D
As
you
can
see
on
the
graph
when
you
run
cooperage,
it's
like
you
are
or
cluster
as
at
the
cloud.
All
the
data
model
and
the
semantics
are
the
same.
Basically
your
uncle
cuddle,
and
then
you
you
get
your
note.
You
can
create
their
status.
You
can
deploy
your
applications.
It's
transparent,
you
don't
even
know
that
note
is
at
that
and
then
the
main
component
on
the
cloud
side
r2
was
called
control
edge
controller.
The
other
one
is
a
metadata
store.
The
reason
we
have
edge
controller
is
like
this.
D
You
know
in
the
etcd,
for
example,
after
scheduler
schedule,
apart
to
a
node,
basically
in
the
path
tree,
you
have
all
the
assigned
and
know
the
information,
but
the
etcd
doesn't
support
a
secondary
indexing.
So
in
order
for
the
node
to
get
all
the
assigned
part,
so
it
has
to
watch
the
whole
pod
tree.
So
you
think
about
that.
What
I
call
out
earlier
the
network
bamas
is
limited
and
we
really
want
the
edge
node
to
sink
down
only
the
needed
data.
D
So
that's
why
we
created
the
edge
controller,
so
the
edge
controller
will
watch
the
etcd
for
the
master
and
then
it
will
rewrite
the
data.
Just
just
get
the
data
for
that
node
and
restructure
it
and
stored
it
in
the
metadata
store
at
the
cloud
then
make
back
to
the
to
the
network.
Part
network
part.
We
introduced
a
component
called
a
cool
bus.
D
If
you
want
to
know
more
details,
one
of
my
colleagues
had
a
talk
in
Cook
County
on
hi
this
this
year
he
explained
in
detail
about
cool
bus,
so
cool
bus
has
two
components:
one
deployed
on
the
server.
The
other
component
is
deployed
on
your
edge
node
between
the
cool
bus
and
the
server
opponent
and
edge
component,
as
I
mentioned
earlier
through
WebSocket.
Once
the
connection
is
connected,
we
rewrite
the
layer,
2
and
layer,
3
traffic,
we
monitor
the
health
and
so
that
it
can
be
connected
further.
D
We
I'm
not
sure
how
many
of
you
know.
Gollum
has
a
native
has
a
library
which
can
help
you
to
call
the
native
Network
API
to
create
your
tunnel
to
do
the
ink
haptic
app.
So
we
also
have
a
proxy
which
can
build
the
VPN
tunnel.
Those
kind
of
thing,
ok
and
then
the
other
part
I
want
to
say
is
the
agent.
D
You
know,
couplet
is
kind
of
heavy,
and
a
lot
of
features
are
not
not
needed
in
the
edge
scenarios.
That's
why
we
rewrite
some
of
the
functionalities
and
wrote
our
own
app
agent
and
it's
very
lightweight.
The
other
last
thing
is
on
the
edge
side,
there's
a
store
as
well,
so
this
is
the
functionality
and
architecture.
D
D
The
one
thing
I
want
really
want
to
call
out
as
a
working
group
here.
This
doesn't
mean
to
be
the
perfect.
That's
why
we
have
this
community
and
work
group.
I
really
hope,
like
you,
gave
us
feedback
or
even
contribute,
because
personally
I
think
this
is
a
great
architecture,
can
help
you
solve
a
lot
of
issues,
and
then
next
is
the
road
map
you
can
find
the
information
at
the
key
have
as
well
just
from
long-term
perspective.
I
want
to
call
out
a
couple
of
things
wise.
D
We
plan
to
integrate
it
with
steel
and
build
mesh
kind
of
networking
infrastructure,
and
then
the
other
thing
is
like
we
want
to
integrate
the
edge
node
with
the
cloud
server
as
well,
so
that
in
your
cluster
you
can
have
a
server
machine
in
your
data
center
and
the
nodes
at
the
edge.
Okay,
so
I
think
that's
what
I
have
here
is
a
information
about
our
workgroup
and
how
you
can
contribute.
We
meet
every
other
Friday
so
and
we
have
recordings
if
you're
interested,
you
can
all
go
there
and
and
recap
catch
up.
Okay
and.