►
Description
Speakers: Jing Xu, Manu Batra
Getting started in containers and Kubernetes can be daunting, especially when coming from the Virtual Machines world. The differences in storage models adds to the confusion. This session will explain the storage and data management differences between Virtual Machines and Containers. Specifically we will focus on:
- Translating the VM terminology and challenges to the Kubernetes container world.
- Drawing architectural parallels between the two approaches including storage operations and communication fundamentals.
- Discouraging the impulse to tackle storage problems the same way on Kubernetes as was done in the VM world.
You will leave this talk with an understanding of how storage works in Kubernetes ecosystem, with parallels to VM/hosts storage terminology, architecture, and operations.
A
B
Thank
You
German
for
the
introduction
again
appreciate
everybody
being
here.
Part
of
the
talk
was
more
about,
like
I
spent
quite
a
few
years,
just
20
working
on
physical
machines.
We
am
sand
about
in
a
year
and
a
half
ago,
or
so
I
landed
up
in
container
lab
and
I
was
looking
to
say.
Okay,
if
somebody
has
to
start
today
and
coming
from
that,
how
can
we
draw
parallels
on
how,
at
an
architecture
level
how
things
work
in
a
vm?
How
can
I
look
at
that
in
a
container
world?
B
How
can
I
look
at
an
operational
level
allocation
of
volumes
setting
up
corners?
What
does
it
mean
in
if
I'm
used
to
those
things
on
a
VM
world?
How
does
can
I
translate
them
in
a
container
lab,
so
the
talks
more
about
that
we'll
definitely
have
time
towards
the
end
for
questions
so
definitely
feel
free.
B
So,
moving
on
to
the
agenda,
what
we
really
want
to
spend
time
on
is
a
little
bit
talking
about.
Why
do
containers
need
storage
containers
supposed
to
just
come
up
and
go
away
and
come
back
again
anyway?
You
need
them,
then
we're
gonna
dive
into
a
little
bit
more
around.
What
does
it
mean?
Do
you
look
at
container
storage
at
an
architecture
level
and
draw
parallels
from
a
VM
standpoint?
Moving
on
I'll
be
talking
more
about
we're
at
an
operational
level
talking
about
day
two
and
day
three.
B
How
do
we
draw
parallels
at
an
operation
level?
Then
what
we
really
want
you
to
walk
out
is
a
small
cheat
sheet.
When
you
talk
to
storage
to
container
folks-
and
they
start
using
terminology,
you
can
always
look
it
up
and
say:
I
know
exactly
what
you
mean.
So
that's
the
goal
that
we
can.
Let
you
walk
out
with
a
quick
small
cheat
sheet,
not
40k.
Just
quick.
B
Storage,
why
I
mean
I
talked
about
autumn
containers,
epithermal,
just
there's
no
supposed
to
be
stayed
now.
When
we
talk
about
containers
there,
they
still
need
storage
depending
on
what
type
of
workloads
are
configured,
how
things
are,
what
workloads
and
applications
they're
running
on
at
a
minimum?
You
need
storage
to
have
control,
kubernetes
control
planes,
so
HDD
has
to
have
so
you
have
some
base
images
when
you
boot
up,
you
need
storage
for
that.
So
that's
at
a
minimum!
Please
that's
what
you
need
from
a
story
standpoint!
B
Moving
on,
if
you're
running
straight,
less
applications,
you
don't
need
persistent
storage,
but
you
may
need
storage
for
stateless
applications
to
runs
scratch
space.
You
may
need
to
store
some
logs
temporary
data
while
the
processing
is
happening
in
the
containers.
So
that's
the
second
area
where,
depending
on
the
application,
if
they're
stateless,
that's
one
place,
might
need
storage
for
containers.
Moving
on
as
we
get
into
more
stateful
applications,
you
wanna
run
a
MongoDB
Cassandra
or
my
sequel
in
containers.
You
may
actually
need
storage
which
lives
beyond
the
life
of
containers.
B
B
Just
do
a
manual
looking
so
talking
about
before
we
start
deep,
diving
into
it,
we're
responsive
time
on
how
the
progression
of
containers
is
happening
and
what
are
becoming
the
acceptable
norms
around
your
deployments.
So
talking
about
some
storage
attached
patterns
traditionally,
if
I
must
admin
and
order
deploys
some
workloads,
kubernetes
and
researchers
who
deploy
workloads
in
containers,
but
the
data
was
either
living
in
if
you're
running
in
the
cloud
like
a
managed
database
service
from
a
particular
cloud
vendor.
That
was
one
pattern
for
deployment
moving
on.
B
There
was
another
pattern
where
well
I
want
to
run
my
own
databases,
but
I'm
not
sure,
should
I
run
them
inside
a
container
because
I'm
not
sure
I'll,
just
run
it
inside
a
VM.
So
one
potential
option
was:
you
could
run
a
database
inside
a
VM,
but
your
workload
is
running
in
containers.
You
get
the
agility
the
scale
across
them
and
that's
some
place.
One
configuration
to
do
100
patterns,
but
as
the
CSI
is
maturing,
as
the
CSI
has
now,
enterprise
features
like
snapshot
it's
in
going
into
beta.
B
Soon
there
is
a
huge
push
and
a
huge
ask
for
our
mr.
to
say:
I,
don't
want
to
look
at
two
separate
frameworks.
One
for
VM
one
for
containers
can,
as
an
application,
can
I
have
a
consistent
application
of
framework
all
based
on
containers.
So
more
and
more
admins
are
adopting
to
move
towards
running
databases
inside
containers
itself.
So
that's
where
you
need
persistent
disks
and
where
the
life
of
disk
is
actually
beyond
just
the
container
itself.
So
a
lot
of
our
conversations
between
Jing
and
I.
We
focus
more
on
the
third
pattern
today.
B
So
we
wanted,
we
were
looking
at
many
ways
on
how
we
dice
and
slice
the
whole
model
and
what
we
did
ended
up
doing
was
kind
of
doing
it
in
a
pattern
to
say
at
day
zero
when
you're
thinking
about
deploying
an
application.
What
are
the
fundamental
approach,
differences
at
an
architecture
level,
so
de
zero,
you're
thinking
about
architecture,
you're
thinking
about
a
design
of
an
application
you
haven't
deployed
anything
yet
day.
One
you
start
to
deploy
your
application.
B
You
start
building
the
application
framework
infrastructure
framework,
we'll
talk
about
what
are
the
differences
at
that
level?
Then
we
get
a
day
two
I
start
ringing.
Applications
I
start
consuming
my
infrastructure
with
applications
and
framework.
What
are
the
parallels
we
can
draw
on
that
side
and
a3
as
I
start
consuming?
How
do
I
start
controlling
and
managing
things
at
scale?
I'm
used
to
certain
patterns
on
PM's
can
I
translate
the
same
concept
and
what
does
the
translation
even
mean
at
managing
at
scale
levels,
sharing
quarters
and
things?
B
D
So
this
is,
you
know
typical
virtual
machine
clusters
that
have
right
this
simplified
architecture
view
the
bottom
layer,
storage,
you
there's
a
variety
of
storage
available
and
on
top
of
physical
storage
layer.
Typically,
there
is
a
virtualization
layer.
It
provides
a
unified
interface
for
a
virtual
machine
to
access
your
storage
right,
no
matter
what
kind
of
storage
underneath
you
can
access
as
file
or
prog
devices
and
across
these
layers
and
the
data
paths
make
available
for
a
workload
to
access
the
storage
and,
on
the
other
hand,
there's
also
need
a
control
path
right.
D
D
So,
on
top
of
virtual
machine
layer
you
have
operating
system
and
then
you
can
run
a
number
of
containers
inside
a
virtual
machine
and
you
can
run
a
workload
instead
of
containers
and
across
these
layers,
again
the
telepaths
make
available
for
your
workload
to
access
a
storage
and
in
order
to,
of
course,
manage
your
containers
and
it's
really
the
resources.
You
know
you
need
another
layer
of
control
plane.
D
Kubernetes,
of
course,
is
one
of
such
continuous
treatment
system,
so
Cabana
is
a
main
difference
is
commonly
used
when
a
DS,
we
so-called
the
current
API,
so
just
in
a
minute
we'll
describe,
was
the
fundamental
difference
between
kubernetes,
declarative,
API
and
imperative
API,
and
also
focus
be
able
to
manage
the
underlying
storage
resources
when
it
need
to
communicate
with
the
control
plane
at
what
machine
layer.
So
the
storage
community
initiative
standard
to
be
able
these
two
layers
to
communicate
each
other.
D
Okay,
we
just
mentioned
imperative
API
and
a
component
is
the
curse
of
the
API.
What's
the
difference
at
a
left
side
right,
it
is
a
typical
some
list
of
commands.
You
can
use
to
perform
some
tasks
in
virtual
machine
environment
and
pokemon.
That
is
everything
every
resources
basically
described
as
API
objects.
Here
we
have
some
examples
and
for
storage
later,
we'll
explain
those
in
more
detail
all
right.
D
So
what's
the
difference
between
these
two?
Let's
use
a
simple
task,
as
example
right
you
want
to
create
a
disk
and
you
want
to
make
it
available
for
your
workload
to
access
it
and
in
the
typical
virtual
machine
environment.
You
need
to
figure
out.
What's
the
sequence
of
commands,
you
need
to
run
like
here,
you
need
to
create
disk,
you
need
to
partition
format
this
and
attach
takes
to
denote
that,
where
your
container
is
scheduled
to
what,
if
there's
some,
when
you
run
these
commands,
there
are
some
failures
and
problems.
D
Then
you
have
to
run
your
API
again
now
in
a
declarative,
API
word,
so
it's
changed
a
way
of
managing
system.
You
no
longer
need
to
worry
about,
or
figure
out,
the
sequence
of
commands.
You
need
to
run.
You
just
describe
what
you
want
to
achieve,
what
the
state
of
your
system
you
want
to
get
so,
for
example,
if
you
need
a
volume
available,
you
just
define
a
volume
spec
describe
what
kind
of
volume
you
need.
D
What's
the
size
of
the
volume,
what
some
you
want
and
the
system,
the
controller
will
figure
out
what
to
do
and
make
it
available,
and
if
you're
part
need
to
use
that
volume,
then
you
define
your
parts
bag
which
have
a
reference
of
your
volume
object
again.
The
controller
will
just
figure
out
what
to
do
and
basically
what
you
they
find
in
your
API
objects
right.
This
grab,
what's
the
desired
state
of
your
system
and
the
controller
will
compare
the
desired
state
and
with
the
actual
state
and
determine
what's
the
action
I
need
to
take.
D
D
D
So
again,
in
water,
washing
environment
rats,
you
have
two
type
of
people:
two
different
rows:
four
users
right
user
care
about,
like
what
kind
of
storage
I
need,
whether
it
is
persistent
or
whether
they
need
to
be
a
file
blog,
whether
you
need
multi
or
single
reader
writer.
What's
the
size
of
your
storage
and
user,
just
kind
of
sent
this
request
and
the
system
mean
we'll
need
to
figure
out
how
to
set
up
the
storage,
whether
it
is
fabric
I,
know,
FSS,
mbm
and
based
on
users
request
and
the
system
may
need
to
run.
D
D
Again,
to
make
the
relationship
between
the
user
and
system
mean
so
from
user
side.
Please
delay
it
needs
some
requests,
so
we
use
so
called
persistent
volume
claim
to
represent
a
request
for
storage.
So
here
we
have
example
and
in
the
persistence
volume
claim
spike,
you
can
define
what's
the
size
of
your
storage
and
what
is
the
access
mode
for
storage
and
also
you
can
define.
What's
the
file
system
want
to
put
for
your
storage
and
you
may
notice,
there
is
no
detail
information
about
the
actual
storage
at
all.
There's!
D
No,
you
don't
know
what
is
the
actual
underlying
storage
type,
whether
it
is
NFS
or
it
is
a
scuzzy
and
there's
no
like
a
disk
ID
there.
So
the
benefit
of
this
way
is:
it
makes
your
workload
very
portable
right.
So
if
you
need
to
migrate
your
workload
from
one
class
to
another
right,
you
can
just
use
exactly
the
same
PVC
right,
there's
nothing!
You
need
to
change
and
also
is
PVC.
The
queries
can
manage
the
volume
lifecycle
independently
from
their
workload.
D
D
So
in
this
example,
is
specifying
what's
the
size
of
what's
the
capacity
of
the
storage
and
was
the
available
volume
access
mode
and
what
is
the
file
system
and
also
what
is
the
driver
for
this
storage
and
the
detailed
volume
ID
visit
is
a
handle
or
so
that
you
can
access
the
volume
and
for
user
side
right?
It
creates
a
PVC
such
as
a
claim
and
system
means
that
right.
It's
need
to
create
those
PV
objects
to
represent
those
volumes
and
the
system
will
binding.
These
two
objects.
B
Thank
you
so
moving
on
I
mean
we
covered
a
couple
of
things
we
covered
like
what
other
differences
between
imperative
approach
with
and
the
decorative
approach
that
containers
have
and
I
think
that's
something
to
consider
you're
designing
the
architecture
about
completing
a
task
we
also
covered
like
how
does
kubernetes,
abstract
storage
by
source
classes
or
p
BBC
mapping.
So
that
way,
your
application
is
portable,
independent
of
the
underlying
architecture.
Now,
let's
look
at
when
you
are
designing
your
architecture.
B
B
These
are
the
volumes
these
50
are
allowed
to
be
assigned
to
this
application,
these
50
or
for
this
other
applications
and
the
two
shall
never
converge,
because
you're
worried
about
workload,
incompatibilities
or
because
processors
may
be
shared
on
an
external
system,
so
mapping
the
same
parallels
to
the
container
world
in
containers.
You
actually
can
do
a
very
similar
thing.
B
B
So
pre
provision
and
sometimes
also
called
static
provisioning
is
where
a
storage
admin
can
pre,
create
a
set
of
volumes
and
whenever
a
container
gets
deployed
and
asks
for
a
volume
through
a
storage
class
and
a
PVC
mapping,
the
only
option
is
one
of
the
pre
created
volumes.
If
the
volume
doesn't
exist,
the
request
fails.
If
the
volume
exists,
the
request
goes
through,
but
there
is
no.
You
cannot
create
more
than
what
you
were
allocated.
So
it's
an
interesting
way
of
creating
that
paradigm.
You
can
control
how
different
things
are
mapped.
B
This
is
very
in
this
case
comes
in
when
you
have
like,
restores
or
backups,
and
then
you
have
a
very
specific
relative
mapped
out,
so
that
is
also
part
of
pre
provisioned
or
static
provisioning
in
the
dynamic
provisioning.
The
biggest
difference
is
that,
depending
on
the
storage
policies
across
the
environment,
you
may
allocate
a
set
of
storage
pool
and
say
as
long
as
this
like
a
one
terabyte
tool.
B
Dear
application,
admin
have
added
create
as
many
volumes
create
whatever
size,
but
this
is
the
area
and
you
can
just
use
one
terabyte
of
pool
or
you
can
allocate
multiple
sets
of
pools.
Who
say
one
is
my
SSD
one
is
my
spinning
dry
7.5
15
K
dries
whatever
the
pool
configuration
is,
but
the
actual
volumes
are
not
pre
created.
They
are
created
on
demand
when
a
container
spins
up
or
a
workload
is
deployed.
B
So
again,
it
depends
on
what
are
the
policies
across
your
environment
for
managing
VMs,
and
if
you
want
to
translate
the
same
policies,
the
same
level
of
controls,
they
can
be
mapped
to
you.
The
container
side
and
container
supports
both
of
those
policies
itself.
We've
seen
both
models
being
viable,
but
the
biggest
difference
comes
in
like
if
you
are
running
workloads
on
pram
or
you're
running
workloads
in
the
cloud.
C
B
So
it
gives
you
those
controls
within
that
within
storage
class,
depending
on
the
type
of
storage
provider
you're
working,
they
could
be.
Custom
parameters
also
pass
to
expose
certain
vendor
specific
information
also,
but
at
a
base
level
there
is
a
general
set
of
parameters
that
can
define
what
kind
of
service
the
application
needs.
C
B
Before
we
get
into
this,
so
we
have
we've
thought
about
the
architecture
we're
starting
to
deploy
applications.
We
have
figured
out
we're
going
to
use
dynamic,
provisioning
or
static
provisioning.
Now
we
start
deploying
applications,
an
application
start
consuming
storage.
Then
the
question
becomes:
how
do
you
maintain
state
where,
because
of
the
dynamic
array
of
the
environment,
when
you
scale,
you
really
don't
scale
beyond
the
certain
level
of
controls
that
you
have
so
on
day?
Three
will
I
want
to
talk
about
more
about
how
do
you
send
boundaries
and
controls
in
that
in
an
environment?
B
So
one
of
the
things
we
can
do
is
set
quotas.
When
you
can
set
quotas
on
how
many
PVCs,
an
individual
namespace,
can
allocate
where
it's
growing
or
scaling
or
scaling
up
and
scaling
down,
and
in
that
case
you
can
look
in
this
example
can
say
there
are
five
PS
and
the
total
capacity
cannot
be
more
than
50
gigs.
Now
the
application
has
flexibility
to
define
how
many
of
those,
but
the
total
is
capped
at
50.
B
The
next
level
of
control
we
can
look
at
is
limit
range
so,
depending
on
what
type
of
box
you
want
to
give
for
the
application
admins
another
way
to
do
it
is
that,
like
specially
coming
from
a
VM
world,
particularly
storage
admins,
there
was
a
general
rule
depending
on
the
scalar
say
any
volume
less
than
hundred
gigs
go
ahead,
and
it's
automated
you
can
create
it
by
yourself
anything
over
100
gigs.
Well,
let's
talk
about
it
because
I
may
need
to
do
some
capacity
planning
or
things
around
it.
B
B
So
if
you're,
a
storage
art
when
you're
controlling
what
your
scale
is
going
to
be,
this
is
another
way
where
you
can
define
certain
limits,
depending
on
what
your
corporate
policies
are,
how
you
want
to
manage
growth,
how
you'll
manage
scale
and
how
you
make
sure
the
applications
don't
step
on
each
other.
Given
a
lot
of
the
environment
is
going
to
be
shared,
at
least
on
the
back
end,
so.
B
Here's
the
cheat
sheet,
so
we
talked
about
pvp
VCS.
We
talked
about
static,
provisioning,
dynamic
provisioning.
We
talked
about
CSI
drivers.
Essentially,
a
lot
of
these
concepts
are
very
similar.
They
have
different
names.
There
are
different
titles,
but
the
end
of
the
day.
The
level
of
controls
are
more
dynamic,
but
they
can
be
translated
to
something
that
you're
already
aware
of
so
we
start
with
the
storage
class.
A
storage
class
is
a
storage
profile
in
containers.
B
The
main
goal
is
to
abstract
application
from
any
physical
characteristics
of
a
storage.
You
don't
care
about
that.
It's
FCI
Scaasi,
all
you
care
as
I,
am
writing
into
the
storage
class
and
when
application
moves
for
an
environment
a
to
environment
B.
As
long
as
that
storage
class
is
available,
I
am
fine.
I'm
not
worried
about.
What's
serving
that
storage
class
next
thing
is:
PV
is
more
about
kind
of
going
back
to
the
imperative
way
of
modeling
of
request.
Pv
is
an
actual
storage
object,
saying
here's
my
volume.
This
is
how
you
map
it.
B
So
it's
almost
like
a
volume.
It's
an
object
that
is
representing
volume
in
containers.
Pvc
is
a
request
for
a
volume
again
going
back
to
the
data
models.
This
is
you
request,
and
then
you
get
it
and
kubernetes
works
on
achieving
that
state
controller.
Is
that
manages
the
whole
thing
on
how
to
get
to
the
per
state
that
was
requested?
If
the
resources
are
not
there,
it
will
keep
trying
versus
I
failed.
There
will
be
timeouts,
but
that
it
works
on
it,
static,
provisioning
and
dynamic
provisioning.
B
Depending
and
again,
your
policies
for
the
environment
that
you're
using
for
VM
and
containers
you
can
leverage
that
static
provisioning
allows
you
to
limit
provisioning
to
pre
carved-out
volumes.
Dynamic
provisioning
allows
you
to
create
dynamic
volumes
on
demand,
given
a
storage
pool
or
a
pool
of
storage
and
you'll
hear
multiple
terms:
around
CSI
drivers,
entry
drivers,
the
biggest
difference,
is
entry.
Drivers
was
previously
the
way.
Storage
storage
partners
integrated
into
containers.
Csi
is
the
new
way
and
a
lot
of
drivers
are
moving
the
biggest
difference
being
entry.
Drivers
were
part
of
the
kubernetes
stack.
B
Csi
drivers
are
external
interfaces
which
partners,
storage
partners
write
to
it,
but
that
if
that
term
comes
up
it
essentially
is
a
storage
interface
that
storage
partners
and
vendors
use
to
integrate
into
the
container
stack
itself.
So
hopefully,
this
helps
you
move
and
translate
terminology
from
A
to
B
basic
concepts
around
how
you
can
look
at
containers,
I,
look
at
storage
and,
if
you're
used
to
certain
practices
and
an
operational
level
or
an
architecture
level
on
a
VM
goal.