►
Description
Gold Sponsor Lightning Talk: The Future of Container Storage: CSI and Cloud Foundry - Julian Hjortshoj, Dell EMC
In early 2017, representatives from Cloud Foundry, Kubernetes, Mesos and Docker convened a working group to create a common Container Storage Interface. The intent of this interface is to provide a standard API that will allow a storage provider to write a single plugin that can attach their storage to any of the major container orchestrators.
In this talk, we will cover the design and logical flow of the Container Storage Interface, discuss its integration into Cloud Foundry, and look at some initial examples of storage plugin implementations.
About Julian Hjortshoj
Julian is the PM of the Diego Persistence team, and a 12 year veteran at Dell EMC. | In his spare time, Julian enjoys traveling, cooking, sporadic exercise, and building stuff that isn’t software.
A
A
Those
of
you
don't
know.
Container
storage
interface
is
a
project
that
was
launched
roughly
this
time
last
year
between
Cloud
Foundry
kubernetes
mezzo
sand
docker
to
try
to
standardize
the
way
that
storage
is
attached
to
containers
in
container
orchestration
systems.
We've
been
kind
of
working
off
and
on
it,
sort
of
faltered
a
little
bit
last
fall
around
the
holidays
and
picked
back
up
again
in
the
spring,
and
we've
been
going
full-tilt
on
it
since
since
early
this
year.
So
why
did
we
do
this
thing?
A
We
all
all
of
our
various
orchestrators
need
a
way
of
attaching
storage
to
containers
unless
your
apps
totally
stateless,
which
you
know.
Ideally
it
should
be
twelve
factor
app
and
all
this,
but
sometimes
it's
not
so
essentially,
we've
all
evolved
to
the
point
where
we
find
we
need
to
store
some
stuff
in
some
kind
of
volume.
A
Likewise,
storage
providers
have
kind
of
sensed
in
the
wind
that
all
of
the
workloads
seem
to
be
going
toward
containers
and
they
all
dearly
want
to
be
able
to
attach
their
storage
to
containers
in
places,
and
they
don't
really
want
to
have
to
do
that
once
per
container
orchestration
system.
So
I
don't
want
to
have
to
like
build
the
integration
with
kubernetes
and
then
turn
around
and
make
a
docker
volume
plug-in
and
turn
around
and
make
a
cloud
foundry
service
broker
and
thing,
and
so
on
and
so
forth.
A
So
standardized
API,
similar
to
like
the
open
service
broker,
API
or
some.
You
know.
The
container
networking
API
gives
us
a
way
to
allow
storage
providers
to
write
one
plug-in
set
that
works
with
all
of
the
various
different
orchestrators
and
that
way
kind
of
work
together
and
if
you're
running
multiple
storage
providers
and
multiple
container
orchestrators
in
the
same
ecosystem,
they
can
all
just
hook
up
to
one
another.
A
Csi
proposes
that
there
should
be
two
plugins
per
storage
provider.
Essentially,
it's
a
division
of
labor.
The
first
plug-in
will
sit
at
the
at
the
orchestrator
of
the
controller
layer,
similar
to
a
Cloud
Foundry
service
broker,
it's
responsible
for
provisioning,
attaching
storage
to
a
node,
and
then
the
node
plug-in
is
guaranteed
to
be
run
on
the
same
host
as
the
workload
and
that's
where
we
do
things
like
mounts
or
stuff.
It
has
to
happen
on
the
local
node.
A
So
in
the
case
of
Cloud
Foundry,
that
would
be
the
controller
plug-in
running
who-knows-where
and
the
node
plug-in
running,
probably
in
multiple
instances,
one
on
each
Diego
cell
and
if
you
want
more
details
on
that,
the
spec
is
at
this
link,
so
the
basic
kind
of
control
flow.
This
is
quite
a
bit
simplified
or
more,
more
RBC
calls.
But
the
gist
is
that.
A
Container
Orchestrator,
you
know,
in
our
case
the
cloud
controller
is
going
to
call.
This
plug-in
is
going
to
ask
you
to
create
a
volume
when
prompted
by
some
user
action,
so
that
calls
the
create
volume.
Rpc,
some
storage
gets
provisioned,
or
maybe
your
storage
already
exists,
and
this
is
a
no
op.
The
container
Orchestrator
doesn't
know,
but
it
knows
that
it
has
to
call
create
you
get
a
response
back
with
a
little
bit
of
metadata.
A
If
it's
something
like
a
block
device,
then
that's
where
we
would
be
doing
attachment
of
the
block
device
to
the
VM,
so
it
kind
of
depends
on
the
kind
of
storage
and
then
finally,
we
call
node
publish
volume
on
the
on
the
Diego
cell
or
on
the
worker
node
or
whatever
you
want
to
call
it,
and
this
is
where
all
the
note
specific
stuff
happens.
So
if
it's
an
NFS
thing,
then
we
would
do
an
NFS
mount
or
or
if
it's,
if
samba
mount,
we
do.
A
That
kind
of
thing
could
also
be
that
it's
a
block
device,
but
it
requires
some
care
and
feeding
in
the
context
of
the
VM
that
it's
gonna
work
on
so
like
I,
scuzzy
initiation
would
happen
at
that
step,
so
just
to
walk
you
through
quickly
what
the
interfaces
are
in
question.
So
there's
the
create
and
publish
that
I
talked
about
there's
also
some
things
about
kind
of
checking,
volume,
capabilities
to
get
a
little
bit
more
information
back
and
forth.
Again,
you
can
go
dig
around
in
this
back
if
you're
interested
in
the
details
of
these.
A
So
that
was
the
controller.
The
node
is
a
bit
simpler.
It
has
this
additional
probe,
no,
that
just
checks
for
okayness
and
get
node
ID,
which
allows
the
know
to
identify
itself
back
to
the
roller.
So,
for
example,
if
you're
attaching
a
an
EBS
thing
to
ec2
VM,
then
you
need
to
know
something
about
what
the
EZ
two's
instance
ID
is
that
you
can
talk
to
Hamazon
to
get
those
things
attached.
A
A
Mobi
ok
docker
hasn't
yet
decided
what
version
they're,
targeting
and
in
cloud
foundry
you
can
have
it
today,
an
open
source
cloud.
Foundry,
we've
already
added
a
POC
level
implementation
of
this
feature.
So
if
you
want
to
go
right,
you're
on
CSI
plug-in
set
and
it's
not
a
block
device,
you
should
be
able
to
use
it
in
cloud
foundry
with
this.