►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Building a PaaS for Robotics with Kubernetes - Dhananajay Sathe, Rapyuta Robotics (Beginner Skill Level)
Building a real-world robot enabled solution is challenging. Access to limitless compute and storage facilitates smarter, cheaper, and agile robots. Cloud robotics has different considerations than a typical web application.The session aims to dive into architecting a PaaS for robotics atop Kubernetes. More specifically - Lessons learned and benefits accrued migrating from the pre-docker era. Discuss abstractions necessary to appeal to a roboticist and challenges running ROS[1] middleware in the cloud-native world. Our extensions to sig-catalog and the OSB Spec. Ideas unifying declarative runtimes across the cloud and remote heterogeneous devices. Describe adaptations to Helm, Fluent, and other cloud-based infrastructure tools to manage and debug distributed robotic applications. In conclusion, the session will touch upon future directions and discuss community participation.
About Dhanaajay
Dhananjay Sathe was one of the primary authors of the RoboEarth Cloud Engine at the IDSC, ETH Zurich during his university thesis. Today he heads the engineering efforts on the Cloud Robotics Platform at Rapyuta Robotics. Prior to this he worked on designing and building the central platform tools at Directi/Endurance to optimize operations and site-reliability efforts at the firm. In the past he has contributed to FOSS projects like the Samba Project and Gnome among others. He has also spoken at conferences like ROSCON, PyCon India, and RootConf India.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Good
afternoon,
everybody
welcome
to
the
talk.
I
am
done
on
J,
sati
and
I
will
be
talking
to
you
about
building
a
cloud
platform
for
robots.
The
docs
will
focus
on
what
we're
doing
and
how
that
relates
to
kubernetes
and
the
greater
CN
CF
ecosystem
right.
That's
my
twitter
handy.
You
can
reach
out
to
me
for
queries
at
any
point
on
that.
So
reputa
is
a
cloud
robotics
company
and
when
we
were
still
a
research
project,
we
used
these
stills
to
motivate
the
idea.
How
many
of
you
recognize
these
stills
great?
A
So
for
those
of
you
who
don't
it's
from
the
movie
The
Matrix
that
came
out
in
98
and
it's
a
scene
where
Trinity
is
stuck
on
top
of
a
skyscraper
and
she's
being
chased
by
a
gazillion,
Agent,
Smith
clones
and
the
only
way
out
is
using
a
helicopter,
gunship
b2
and
two
helicopter
gunship,
and
so
she
does
not
know
how
to
fly.
This
helicopter,
however
she's
in
the
matrix,
which
is
a
connected
world.
So
she
calls
the
Morpheus
and
gets
the
codes
to
fly.
The
helicopter
and
the
badass
that
she
is.
A
She
saves
the
day
right
and
this
idea
stuck
with
us
for
a
very
long
time.
So
what
exactly
this
Trinity
mean
in
the
context
of
robots?
It
means
two
key
things:
robots
can
download
information
and
knowledge
from
the
cloud
and
use
it
for
their
operations
or
they
can
offload
computation
and
storage
to
the
cloud.
This
allows
robots
to
get
cheaper,
lighter
and
hence
more
ubiquitous.
A
If
you
think
about
it,
it's
not
very
different
from
your
mobile
phone
$100
mobile
phone
or
a
$1,000
mobile
phone
performs
some
of
the
most
complex
operations
with
equal
ease
stuff
like
personal
assistance
or
navigation,
and
they
sort
of
leverage
to
the
cloud
to
do
the
same
thing
right.
So
this
was
the
founding
idea
behind
creating
the
robot
project.
It
was
across
University
cross,
lab
collaboration,
backed
by
the
European
Union
I
worked
at
ETH
back
then,
and
the
idea
was
to
create
a
cloud
platform
for
robots.
A
A
This
could
be
something
like
AWS
or
Rackspace,
or
even
work
stations
inside
a
laboratory,
and
so
what
we
did
at
that
point
was
go
with
LXE
containers
and
twisted,
and
that's
I
think
what
a
lot
of
people
were
doing
back
then
with
container
based
platforms.
So
we
did
that
and
what
you
could
do
is
add
a
simple
container
environment,
which
we
call
the
compute
environment
with
us
with
something
like
a
container
tag
that
said:
Roomba
clone
to
represent
a
Roomba
robot
that
you
just
saw
in
the
previous
talk,
for
instance.
A
A
So
what
you
could
do
is
go
to
the
API
server
and
say
add
this
country
in
this
container,
the
roomba
node
add
a
particular
node
that
does
a
position
recording,
for
instance,
right,
and
this
worked
well
Ross
sort
of
did
everything
within
the
compute
environment,
but
to
get
to
more
complex
applications.
What
you
needed
to
do
was
link
together,
multiple
such
robotic
and
compute
environments
and
the
robot
environment
process
that
you
had
inserted
inside
each
one
of
these
environments
was
now
responsible
for
sort
of
channeling.
A
A
We
go
into
more
details
of
this,
but
this
is
what
it
looked
like
at
a
high
level,
and
it
worked
that's
the
good
news,
so
what
we
were
able
to
do
is
have
two
little
Roomba
robots
that
cost
about
hundred
forty
dollars
roam
around
the
lab
and
perform
slam
with
by
using
GPUs
that
sat
in
Amazon
Island
on
remote
and
build
these
3d
maps.
Some
of
our
friends
at
tu
Eindhoven
were
able
to
do
mobile
manipulation
in
different
scenarios.
A
So,
let's
step
ahead,
we
decided
to
form
a
company
with
the
same
ideas,
and
we
did
this
about
two
years
ago,
and
this
was
a
completely
different
world.
You
had
docker,
you
had
kubernetes
just
coming
out
of
1.0
a
lot
of
exciting
things
happening
in
the
cloud
space.
So
this
is
what
we
have
right
now
when
we
started
off
it.
A
We
have
a
control
plane,
we
have
an
API
server,
we
have
some
sort
of
coordination
between
them
and
you
have
a
way
of
managing
data
flow
wooden
platform,
but
it
didn't
it
had
it's
a
whole
set
of
problems.
So
let's
look
into
each
one
of
the
problems.
The
first
one
is
containerization.
Today
we
think
containers
are
quite
ubiquitous,
but
that
wasn't
the
case
back.
Then
there
was
no
standard
of
describing
a
container
and
the
only
way
of
shipping.
A
A
container
was
actually
doll,
gzipping,
the
entire
route
FS
and
passing
that
around,
and
we
had
a
bunch
of
collaborators
all
across
Europe
and
we
were
trying
to
spend
these
packets
do
them
and
all
that
often
broke
down.
So
we
decided
to
start
sending
only
the
diffs,
and
that
brings
you
to
a
whole
set
of
new
problems
around
dealing
with
dependency
hell
and
then
you're,
trying
to
define
the
right
interfaces,
and
often
it's
hard
to
do
that
because
you
really
don't
know
the
right
interfaces
are
right
fast
forward
to
today.
A
What
you
have
is
basically
docker
and
pods.
Now
at
this
conference
we
have
been
discussing
a
lot
of
runtimes
but
I.
Think
the
two
key
takeaways
from
docker
is.
We
have
consensus
in
the
whole
world
today
about
how
to
describe
a
container.
At
least
a
bulk
of
the
world
knows
how
a
docker
file
works,
and
once
you
execute
the
dock
of
build
command,
you
can
use
the
registry
API
to
solve
the
problem
of
transporting
those
little
LOB's,
because
you
have
shaman
signed
images
and
their
chains
and
their
links,
and
that's
a
really
powerful
idea.
A
Also,
you
don't
need
to
make
install
the
entire
world
into
a
single
route
FS,
because
you
can
combine
these
things
at
runtime,
using
pods
and
containers
within
pods
and
moving
ahead.
You
have
cryo,
which
gives
you
different,
runtimes
and
pluggable
isolation,
which
is
really
useful
if
you
are
trying
to
run
a
production
based
cloud
platform
or
trying
to
run
different
architectures
within
the
same
context,
so
that
solves
the
containerization
problem.
The
next
problem
is
the
control
plane.
The
control
plane
was
sort
of
segmented
out.
A
We
dealt
with
two
or
three
ayahs
providers,
so
scalability
was
an
issue.
We
wrote
this
whole
thing
in
Python
twisted
how
many
of
you
have
actually
used.
Python
twisted
right-
and
this
brings
a
big
problem
about
day
to
operations
and
visibility
into
it.
So
the
only
way
to
debug
Python
twisted
is
using
something
called
a
reactor.
A
man
who'll
in
a
reactor
and
getting
down
that
manhole
is
exactly
as
disgusting
as
it
sounds
in
reality.
A
So
that
was
definitely
a
problem
and
hence
maintainability
and
modularity
of
code
was
a
problem
because
no
not
too
many
people
enjoy
writing
Python
twisted
and
the
other
problem
was
definitely
to
deal
with
is
providers.
You
wrote
these
plugs
and
hooks
for
different
I
asked
platforms,
but
they
broke
all
the
time
because
people
change
stuff
I.
Remember
we
had
this
problem
when
we
were
using
ec2
and
we
relied
on
some
very
specific,
a
vxi
instruction
sets
and
we
try
to
execute
code
and
it
didn't
work.
A
So
we
had
to
keep
trying
till
AWS
actually
gave
us
a
machine
that
reported
what
its
hypervisor
actually
said.
It
did
right,
and
that
was
a
major
problem,
so
kubernetes
sort
of
solves
that
problem
for
you.
It
is
battle
tested
at
sufficient
scale
for
these
sort
of
applications
and
the
cloud
providers
now
sort
of
fight
with
each
other
almost
to
maintain
and
have
the
best
and
the
greatest
features
supported
in
community.
So
you
as
a
developer,
don't
really
need
to
deal
with
it
and
it's
a
modular,
codebase
I
think
I'm
preaching
to
the
church.
A
Here
when
I
say
you
can
pick
out
things
that
the
community
is
built
and
a
wise
man
once
said,
stand
on
the
shoulder
of
giants
and
sort
of
use,
what
the
community
is
doing
and
that's
a
really
great
thing
that
really
helped
us
accelerate
our
development
last,
but
not
the
least,
and
one
of
the
most
painful
points
always
is
networking
when
you're
building
a
platform
so
the
first
implementation.
We
had
this
beautiful
idea.
A
A
That
was
a
bad
idea,
so
we
came
up
with
a
way
to
implementation
that
used
VX,
LAN,
&
Greet
annals,
but
those
were
the
early
days
of
Linux
3x
and
we
X
LAN
implementations
tended
to
be
flaky
so
those
broke,
and
when
nodes
disappeared,
reconfiguring
everything,
I,
sort
of
notifying
every
single
process,
saying
hey,
something's
changed
you
need
to
go
and
fix.
It
was
always
an
issue.
A
So
those
are
the
kind
of
issues
that
you're
dealing
with
and
all
the
external
communication
was
maintained
by
these
robot
processes
and
the
master
control
plan
had
to
sit
on
babysit
each
one
of
these
processes
and
that
very
quickly
goes
out
of
hand.
So
in
the
kubernetes
world,
I
think
this
is
something
we
talk
about
a
lot.
The
CNI
ecosystem
is
gives
you
high
performance,
l2
and
l3.
A
Networking
you
have
with
which
basically
enables
you
to
use
any
host
of
l4
to
l7
protocols
that
you
choose,
and
this
gives
developers
flexibility
and
does
not
make
them
rewrite
the
entire
application
using
your
proprietary
protocol,
and
that
is
really
important
for
developers
to
build
more
diverse
applications.
Also,
DNS
is
a
really
good
idea
for
service
discovery.
Unless
you
have
a
specific
reason,
but
you
don't
want
to
use
DNS.
It
is
a
great
idea.
A
A
So
this
is
what
we
start
with
as
an
idea,
and
you
see
where
we're
going
with
this
I
think
this
in
itself
demonstrates
the
power
of
what
we've
created
together
as
a
community
of
what
kubernetes
in
the
CN
CF
ecosystem
have
enabled
you
to
do,
and
we've
sort
of
leverage
that
to
build
our
cloud
platform,
of
course,
with
changes.
But
we
sit
on
top
of
a
rock
solid
base
and
build
ahead
so
that
helped
us
solve
the
data
center
problem
right.
A
But
when
robots
get
really
exciting
or
challenging
is
when
you
break
out
the
data
center,
you
have
compute
that
isn't
necessarily
bound
to
a
data
center.
So
at
which
point
when
you
address
the
problem,
you
run
into
a
new
set
of
issues
and
they're
daunting,
yet
they're
a
lot
of
fun.
For
instance,
there's
heterogeneity
of
compute
right
inside
the
data
center
there's
very
little
variation
in
what
you're
actually
running
on.
A
Yes,
there
are
changes
in
certain
processor
versions,
but
it's
vastly
x86
/
64
processing
units
and
you
have
super
reliable
networks
which
may
not
be
the
case
or
which
is
definitely
not
the
case
when
you're
running
on
a
remote
location
and
reproducibility
and
configuration
is
also
a
major
thing
for
a
single
drone
to
fly.
For
instance,
you
manage
north
of
150
parameters
and
getting
one
of
them
wrong
can
cause
the
drone
to
crash.
In
fact,
the
Russians
lost
a
satellite
because
they
program
the
long-long
the
wrong
launch
parameters
at
that
point
right.
A
So
that's
really
important
and
of
course
there
is
latency
issues.
You
cannot
run
a
application
in
the
cloud
in
u.s.
East
one
and
expected
robot
in
Japan
to
run
very
well
because
they're
super
less
latency
sensitive.
You
typically
want
to
run
in
the
same
city
or
perhaps
even
want
to
put
a
kubernetes
cluster
on
the
edge
to
give
you
a
low
latency
applications.
A
So
let's
look
at
a
real
world
example.
This
is
something
we've
been
doing
over
the
past
one
year.
It
is
basically
an
autonomous
drone
that
sits
on
its
charging
station.
You
open
up
fire
up,
Google
Chrome
and
fly
the
drone
around
in
real-time
latency
means
you
can
typically
sit
within
the
same
continent.
For
instance,
we
have
an
office
in
Bangalore
India
and
we
can
open
Google
Chrome
and
fly
the
drone
that
in
in
rural
Japan,
for
instance,
but
doing
that
over
larger
distances
might
be
concerned
purely
because
of
latency
issue
but
schematically.
A
If
you
think
about
this
problem,
it
is
four
different
things
coming
together
to
make
the
application
work.
You
have
certain
parts
of
the
application
sitting
in
the
cloud,
often
written
by
different
teams.
Something
might
be
written
in
golang
or
Python
in
the
cloud
you
have
some
code
running
in
the
browser
with
JavaScript,
probably
react:
you
have
something
running
on
the
edge
and
typically
you're
on
words
offers
in
C
or
C++.
A
Here,
I
use
different
colors
for
different
protocols,
because
there
are
just
so
many
different
kinds
of
protocols
that
you
use
when
you
are
dealing
with
robotics.
It's
there's,
no
one
standard
or
there's
no
one
right
way
of
doing
these
things.
It
could
be
G
RPC,
it
could
be
WebSockets,
it
could
be
web
RTC.
A
And
this
is
what
Kelsey
Heather
said
at
coop
con
Austin
last
year,
which
says
coop
cattle
is
the
new
SSH
and
you're,
basically
giving
out
as
coop
cattle
to
everybody
and
people
are
abusing
it
and
you're
coming
up
these
hundreds
of
different
are
back
policies,
and
the
more
problematic
thing
here
is
robotics
is
already
super
complicated
and
what
you're
doing
is
adding
one
more
level
of
complexity.
We
all
out
here,
love,
kubernetes
and
understand
it,
but
to
a
person
from
a
completely
different
domain.
A
It
can
be
often
very
daunting,
so
you
don't
want
to
expose
those
things,
and
this
is
very
similar
to
what
the
guys
at
coop
Flo
said
earlier
in
the
conference
saying
you
have
these
ml
experts,
let's
not
introduce
communities
to
them.
Let
them
just
use
the
power
of
communities
and
sort
of
compost
higher
order
applications.
So
how
do
you
expose
kubernetes
the
power
of
communities
to
them
without
exposing
the
complexity
of
it,
and
we
find
that
it
is
good
to
use
high-order
abstractions.
A
So
one
of
the
higher-order
abstractions
that
we
actually
came
out
with
is
something
we
call
a
package
now.
A
package
is
basically
an
abstraction
that
runs
anywhere,
be
the
cloud
be
the
edge
be
at
the
robot.
It
offers
a
uniform
set
of
tools
and
a
uniform
set
of
api's,
and
it
should
have
a
declarative
runtime.
So
what
do
I
mean
by
a
declarative,
runtime
here
right?
A
This
is
an
example
of
a
declarative
runtime
where
I
say
this
is
my
package.
It's
a
really
simple
exam.
It's
a
cloud.
Pub/Sub
I
am
running
I'm
running
a
listener
on
the
cloud
and
because
it's
the
cloud
I
can
do
fancy
stuff,
like
TLS
termination
or
replicas,
and
on
I
want
to
run
something
on
the
device
on
the
device.
In
a
more
complex
example,
a
real-world
example
I
would
give
feature
saying
here.
A
Building
it
on
the
board
is
a
terrible
idea
because
it's
painstakingly
slow
and
it
probably
won't
work
in
most
cases,
all
right
and
let's
also
recognize
that
we
live
in
a
world
where
a
lot
of
devices
will
and
do
not
run
docker,
and
for
these
devices
you
still
need
to
build
artifacts
that
are
binary
artifacts.
But
the
idea
is
the
same
right.
The
the
core
idea
is
you're,
taking
a
bunch
of
source
code
using
a
some
sort
of
transformation
to
arrive
at
strategies
and
architectures,
and
then
you
have
a
build
phase
which
yields
artifacts.
A
Is
that
enough?
The
question
we
often
ask
is:
is
that
enough,
and
that
was
also
the
question-
that
a
bunch
of
people
put
forth
to
the
coop
flow
guys
is
cool.
Now
you
have
applications,
you
have
a
way
of
building
them,
but
how
do
you
actually
compost
them
think
about
a
problem?
Today,
you
build
a
shopping
website,
you
don't
start
building
a
web
server,
you
don't
start
the
building
of
payments
gateway.
A
You
sort
of
put
these
few
things
together
and
you
quickly
sort
of
focus
on
selling
your
teddy
bears,
for
instance,
and
that's
great
that's
how
it
should
be.
However,
in
robotics
we're
not
doing
that,
and
what
you
would
really
want
to
do
is
allow
people
to
reuse
other
people's
work.
For
instance,
if
I
am
a
person
who
knows
how
to
make
great
electromechanical
systems,
I
I
should
not
need
to
get
a
PhD
in
navigation
theory,
to
figure
out
how
to
make
my
robot
move
from
point
A
to
point
B
right.
A
So
what
you
want
to
do
is
permit
coupling
of
these
applications.
That
also
brings
forth
another
really
important
point,
even
within
a
single
robotics
firm.
What
you
typically
have
is
different
teams
use
completely
different
vocabularies,
completely
different
tool,
sets
and
languages
to
actually
build
and
develop
their
applications,
and
they
want
to
test
that
they
want
all
beautiful
things
like
CIC,
the
ins
amber,
but
you
want
a
coupling
to
be
frozen
before
you
actually
put
it
out
in
the
real
world.
A
A
So,
to
give
you
an
idea
of
composition,
let
me
take
this
example.
You
are,
for
instance,
a
drone
manufacturer.
You
build
beautiful
drones
that
fly
around,
but
you
know
nothing
about
low
latency
video
streaming
and
you
shouldn't
write.
What
you
could
do
is
take
your
teleoperation
package.
Add
simply
import
a
package
that
says:
hey
I
do
video
streaming
now
that
you
have
the
same
package
and
you
have
the
same
very
same
tool
sets
and
API
is
in
place.
A
What
you
do
is
execute
this
ten
times
100
times
a
thousand
times
and
sort
of
use,
the
same
tools
and
behavior
or
another
app
example
would
be
when
you
want
to
maintain
two
things
but
use
the
same
API,
but
have
completely
different
life
cycles.
For
instance,
I'm
going
to
set
up
a
mapping
server
and
then
robots
inside
the
warehouse
come
and
go
and
sort
of
use
and
consume
this
mapping
data,
and
you
want
this
very
same
API
every
single
time.
So
how
do
you
achieve
that?
A
I
I
know
all
this
sounds
really
interesting,
but
how
do
you
actually
get
there
and
there
happens
to
be
a
very
powerful
tool
kit
in
our
arsenal,
called
the
open,
serve
Broker
API?
How
many
of
you
are
actually
aware
of
what
the
open
service
broker
API
is
great,
so
primarily
the
open
service
broker-
API
some
people
have
talked
a
lot
of
people
have
been
talking
about
in
the
confluence
is
a
way
of
reasoning.
A
Granting
asking
for
resources,
provisioning
and
de-provisioning
them
that
yield
a
set
of
credentials,
credentials
contain,
coordinates
and
configuration
of
how
to
use
a
particular
resource.
Essentially,
you
can
use
a
robot
or
a
Twitter
account
or
a
hard
disk
or
a
particular
cloud
provider
in
exactly
the
same
way
right.
So
when
you
do
a
provision
request,
you
create
a
resource
when
you
do
a
bind
request,
you
get
these
credentials
and
now
you
can
consume
these
credentials
right
and
we
want
the
platform
to
be
extendable
in.
A
It
has
to
be
extendable
because
you
have
so
many
combinations
of
algorithms
and
hardware
and
all
these
things.
So
what
you
do
is
take
this
I/o
package
that
we
talked
about
earlier
and
create
a
metadata
representation
of
it
that
helps
the
platform
sort
of
reason
about
the
package
stuff
like
labels
and
selectors,
and
you
also
create
a
service
class
representation
out
of
it
and
shove.
The
whole
thing
behind
the
open
service
broker
API.
Now
you
have
standard,
tooling
standard
methodologies
of
how
to
deal
with
open
service
brokers.
A
So
what
you
could
do
is
create
a
platform
broker,
send
a
request
to
it.
That
says,
create
provision
bind
unbind
and
what
this
platform
broker
does
is
then
cascades
it
to
a
second
level
of
brokers,
and
it's
quite
interesting
why
we
do
this.
For
instance,
here
we
have
a
device
broker
and
a
cloud
broker
and
perhaps
other
I
asked
brokers.
So
what
you
would
do
is,
if
you
wanted
to
render
a
part
of
the
application
graph
on
the
cloud.
A
The
device
or
the
cloud
broker,
would
kick
in
and
say:
hey,
I'm,
gonna
handle
this
and
talk
to
the
cloud
controller
and
render
the
application
graph
into
the
cloud
using
something
like
helm
or
templates.
We
use
hell
in
this
case
and
what
you
get
is
all
the
fancy
features
of
kubernetes,
your
edges,
your
services,
pods
deployment,
configs,
all
the
great
things,
and
now
you
get
the
credential
set
and
go
to
the
device
block
and
say:
hey
buddy.
Why
don't
you
connect
up
to
this
endpoint
on
the
cloud
and
it
uses
exactly
the
same
semantics?
A
So
you
sort
of
reuse
them
and
compose
this.
The
application
use
some
sort
of
a
control
channel
to
the
device
the
device
connects
up.
You
have
a
complete
application
graph
deployed
across
the
cloud
and
the
robot
that
works
together
in
unison,
and
you
have
the
very
same
API
to
now
bind
unbind,
destroy
or
create
these
service
class
representations,
and
it's
also
really
simple
to
extend
them
and
include
features
that
providers
bring
in
to
the
table
because
you're
using
the
open
service
broker
API.
A
A
Now
this
example
could
very
well
be
you
very
well
be
used,
in
other
cases
like
following
workers
around
a
factory
to
help
them
like
load
stocks
or
drones,
going
in
swamps
to
achieve
a
certain
mission
right.
So
this
is
the
kind
of
power
that
you
can
actually
unlock
with.
Cloud-Connected
robots
and
communities
has
helped
us
a
long
way
in
getting
here.
Thank
you.