►
From YouTube: You Have Stateful Apps - What if Kubernetes Would Also Run Your Storage? - Annette Clewett
Description
You Have Stateful Apps - What if Kubernetes Would Also Run Your Storage? - Annette Clewett & Sudhir Prasad, Red Hat
Kubernetes supports Stateful Applications by connecting to your existing storage. But what if you don’t have any? Or the storage capabilities differs between your environments? Wouldn’t it be nice if Kubernetes itself would be able provide storage services without any external dependency from Day1?
gluster-kubernetes is an umbrella project, currently being submitted for inclusion in CNCF, tying together various open source technologies to do just this. It takes the concept of “container-native storage” literally and orchestrates containerized GlusterFS, a scalable, software-defined storage solution to provide object storage, file storage and block storage for your applications. In this session you will learn about the components in play and how they make Kubernetes provide Persistent Storage and S3 Object Storage that scales with the cluster and runs everywhere.
About Annette Clewett
Red Hat Storage Architect with broad knowledge across a spectrum of technologies – network, storage, virtual, and platform. Have successfully delivered countless studies that improved end-user experience and created more efficient and available infrastructures. Current projects include creating and documenting reference architectures for container-native storage in the cloud, on virtual, or bare metal.
About Sudhir Prasad
Sudhir drives Container Native Storage and Container Ready Storage Red Hat portfolio for Kubernetes. Before joining Red Hat, Sudhir led Product Management and Strategy at Violin Memory and led Manageability product portfolio for automation & orchestration at NetApp. Before moving to product management, Sudhir was Principal Engineer & Software Architect at NetApp and HP. As engineering lead his focus was on system architecture & design, high availability, manageability, simplicity, and workflow automation
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.
A
I
am
Sudhir
Prasad
product
management
director
for
container
stories
at
Red,
Hat
I
have
with
me
a
knit
Cluett.
She
is
senior
Software,
Architect,
very
well
versed
in
kubernetes
and
storage,
civil
lead,
the
demo
for
us.
We
also
have
Michael
Adam,
who
is
heading
the
manager
and
lead
for
CNS
engineering,
Jose
and
Erin,
who
actively
contribute
on
and
developer
in
the
cns
world.
So
if
you
guys
have
any
deeper
question,
they
will
definitely
be
staying
here
for
after
the
session
to
talk
about
it.
A
A
So
if
we
look
at
the
persistent
storage
right
and
I
categorize
them
in
in
three
broad
categories,
the
first
one
is
basically
the
platform
infrastructure
needs
right.
Its
registry
logging
metrics,
if
you
have
other
management
application
things
like
that
right.
This
is
basically
persistent.
Storage
needs
for
running
the
infrastructure.
Writing
the
component
kubernetes
platform
itself
and
the
second
one
is
your
application.
Persistent
needs
the
data,
you
know
input
data.
A
What
you
need
are
the
results
of
analytics
and
things
like
that
and
the
last
one
is
mostly
a
local
storage,
I,
ephemeral,
storage
and
traditionally
for
persistent
storage.
We
have
focused
on
the
first
two
one
of
them.
Can
we
run
the
platform?
Can
application
get
persistent
storage?
There
is
some
work
going
on
to
really
make
the
local
storage?
Also
persistent?
That's
not
yet
there,
but
you
know
it
will
be
there
shortly.
A
So
there
are
various
solutions
for
persistent
storage,
and
you
know
anyone
and
every
storage
company
have
some
persistence,
storage,
container
and
extremely
confusing
right.
You
know
and
I'm
sure
they
all
have
unique
value
proposition
into
them
right.
They
know
something.
Some
of
the
application
do
better
for
some
specific
application.
Some
of
them
do
good,
for
some
infrastructure
needs
right.
What
we'll
discuss
here
is
that
what
is
the
design
pattern?
They
are
following
and
what's
the
trend
and
what
are
the
advantages
for
advantage
at
a
general
broad
category?
A
The
first
one
is
very
simple
right.
This
is
how
everything
started
that
you
know.
Kubernetes
came
as
a
platform.
People
wrote
their
driver
or
a
plugin,
and
then
they
have
a
legacy:
storage
or
existing
storage
or
the
storage
from
the
cloud
provider
and
then
kubernetes
platform.
The
containers
can
get
the
persistent
volume
from
the
platform.
A
The
key
to
note
here
is
that
you
know
we.
You
already
had
the
storage,
it's
a
separate,
independent
subsystem
and
you're
trying
to
make
that
work
for
your
containers.
That's
the
biggest
advantage
that
you
have
the
storage.
You
can
leverage
it.
You
can
focus
on
the
new
platform,
but
the
disadvantage
of
this
approach
is,
you
know,
still
as
different
subsystem.
It's
not
part
of
your
platform.
You
can
definitely
use
it,
but
it's
not
you're,
not
taking
advantage
of
the
newer
paradigm
with
your
storage
subsystem.
The
second
paradigm
is
basically,
you
know.
A
Let
me
talk
about
this
with
me.
You
may
have
heard
about
CSI
interface
right
that
you
know
these
plugin.
You
know,
then
there
are
different
orchestration
engines,
you
know,
and
these
plugins
doesn't
work.
Interchangeably
between
them
means
like,
let's
make
it
a
standard,
and
this
is
CSI
initiative
that
a
all
these
drivers
should
be
talking
to
one
interface,
so
you
can
use
kubernetes,
you
can
use
mesosphere
and
things
like
that,
but
the
general
principles
stay
same
today.
A
I
wanted
to
create
a
plugin
with
my
existing
storage
subsystem
or
my
storage
subsystem,
our
newer
one
and
then
make
it
work.
The
second
one
is
basically:
can
we
make
it
API
driven?
We
don't
really
need
storage
admin
to
really
give
developers
to
storage
every
time
they
need
it
right.
So
this
one
is
basically,
you
know
how
we
can
publicize
an
API
through
service
broker
or
a
service.
You
know
where
developers
can
go
and
then
get
their
own
storage
as
long
as
admin
has
given
them
the
privilege
or
the
quota
they
can
through
the
api's.
A
A
The
third
one
is
much
more
interesting,
and
this
is
where
we
will
do
deep
dive
and
I
do
a
live
demo
of
that
one
right
can
be
merged
storage
subsystem
as
make
it
as
invisible,
but
an
integral
part
of
the
kubernetes
platform
itself.
Here
you
run
the
storage
on
top
of
kubernetes
platform.
You
have
multiple
nodes.
You
know
like
one
cluster,
some
of
the
node,
just
like
it's
hosting
an
application,
it's
also
hosting
your
storage
service.
A
A
I'll
go
a
little
bit
deeper
here,
so
you
have
multiple,
a
kubernetes
cluster.
You
have
multiple
pods.
One
of
these
parts
will
be
running
your
storage,
node
right
and
here
I'll.
Take
an
example
of
Red,
Hat,
container
native
storage,
I'm
more
familiar
with
that,
because
I'm
product
manager,
for
that,
so
you
will
have
different
nodes.
A
You
know,
depending
on
how
many,
how
much
scale
you
need
your
multiple
pods,
you
know
or
multiple
node
of
the
clusters,
but
the
key
is
that,
just
like
your
application
is
running
on
top
of
kubernetes
platform,
you
have
storage
running
on
top
of
kubernetes
platform
right.
You
get
many
advantages
with
that
right
because
you
are
taking
the
full
advantage
of
comment
is
orchestration
itself.
It
will
maintain
this
state,
it
will
scale
it
just
like
it
can
scale
other
applications.
A
You
have
one
control
plane,
one
management
plane
and
though
storage
is
a
little
bit
special
because
attach
to
that
data
and
it's
little
bit,
but
you
know
it
will
be
kind
of
integral
part
of
the
platform,
because
you're
running
on
top
of
the
kubernetes
platform
right,
it
can
run
anywhere
wherever
kubernetes
runs,
so
it
can
run
on
the
private
cloud
public
cloud
virtual.
They
are
metal
hybrid.
Whatever
you
take
right,
that's
the
advantage
of
taking
full
leverage
of
the
platform
itself.
A
The
other
advantage
you
get
is
that,
since
you
were
running
as
a
container
right
container
itself
has
its
own
value
proposition
right,
the
imagine
deploying
a
storage,
it
is
standalone
appliance.
It
always
takes
some
time
effort
here.
You
can
do
that
in
minutes
right,
it's
just
another
container.
You
can
deploy
that
upgrade
that
it
has
full
isolation.
You
can
do
rolling
upgrade
things
like
that
right.
A
B
Yep,
okay,
can
you
hear
me
now
yeah?
Okay,
thank
you.
So
there
yeah
I
want
to
sort
of
go
first
through
the
demo
that
we're
gonna
I'm
going
to
do
and
then
I'll
actually
do
it.
It
will
be
a
live
demo.
It
might
look
I've
set
it
up
so
that
it
can't
go
wrong
right,
but
but
you'll
be
able
to
see
it
and
it's
it's
pretty
cool.
B
So
let
me
just
move
on
here,
so
we
are
going
to
go
through
what
Sudheer
called
the
the
pattern,
where
we're
actually
using
the
platform
for
the
storage,
the
storage,
it's
some
from
kubernetes.
The
point
of
view
is
just
another
workload
which
you
know
makes
it
pretty
pretty
good,
because
at
that
point
you
know
OpenShift
or
kubernetes,
I'm
just
to
be
clear:
I'm
going
to
be
using
an
open
shift
environment
to
show
this,
but
it
is
a
workload
in
it.
It
has
all
the
advantages
of
being
on
the
the
platform.
B
I
want
to
just
sort
of
make
it
simple
and
clear
that
there's
there's
no
magic
here.
We
still
need
real
storage
somewhere
and
the
storage
that
we're
going
to
consume
is
connected
to
the
open
shift
nodes
or
the
kubernetes
nodes
that
we
want
to
create
the
cluster.
The
storage
cluster
with
that
storage
can
be
all
of
the
storage
types
that
you
can
put
into
a
piece
of
hardware.
It
could
be
SSDs
that
could
be
each.
You
know
hard
disk,
it
could
be
in
via
Me's
I
mean
it
could
be
whatever
storage.
B
The
main
thing
is
that
for
each
cluster
that
you
create-
and
this
is
a
Gloster
cluster-
you
want
to
use
the
more
storage,
so
it's
conceivable
that
I
could
offer
to
to
the
developers
for
dynamic
provisioning.
I
could
offer
a
fast
cluster
say.
Think
of
like
AWS
right
I
can
have
a
cluster
made
of
I
1
EBS
volumes
and
I
could
have
another
cluster
made
of
you
know.
B
Gpt,
GP,
2
or
or
a
slower
storage
type
and
I
could
offer
that,
and
then
you
know
based
on
their
their
rights,
they
could
make
decisions
about
which
which
storage
they
want
to
use.
The
the
other
thing
to
do
this
point
out
on
here
is
that
this
is
a
simple
architecture.
A
simple
Gloucester
architecture
called
replica
3.
It
does
require
that
there
are
three
openshift
nodes
involved
or
kubernetes
knows.
There's
you
need
to
have
three
at
this
point
in
time.
B
B
But
anyway,
the
the
the
fast
and
the
slow
that
would
take
six
nodes
to
deploy
that
so
the
the
demo
that
I'm
gonna
do
here
so
I
mean
I've,
been
watching
on
two
Mo's
this
week
and
they're
in
there
they're
good.
But
sometimes
you
can
get
a
little
lost
in
the
CLI,
so
I'm
gonna
do
a
demo.
That's
gonna
be
sale
I,
but
I
wanted
to
give
you
some
context
before
that.
So
my
my
kubernetes
open
shift
environment
here
has
a
master
node.
B
It
has
infra
node
the
infra
node
houses,
the
the
registry,
the
router
and
then
I
have
three
app
nodes
and
those
app
nodes
are
where
I'm
going
to
deploy
the
cns.
There
will
be
you'll,
see,
you're
gonna,
see,
there's
going
to
be
cluster
pods
and
then
very
important
for
the
service
that
that
Sudhir
discussed
is
the
haqqani
api.
So
there
will
be
a
pod
that
Kenny
runs.
B
Then
it
the
the
Keti
pod
is
not
tied
to
any
one
node
and
that's
very
useful,
because
if
the
Cuddy,
if
the
node
that
the
heck
a
teapot
is
Down,
Goes
Down,
the
hickety
pod
will
recreate
itself
on
another
available.
Node
and
it
will
remount
at
state,
so
we
see
here
just
pointing
out
that
these
you
know
this
is
how
we're
going
to
create
the
cluster
we're
going
to
deploy
pods
on
to
the
to
the
three
AB
nodes
in
terms
of
Hettie.
B
What
makes
this
I
think
a
really
useful
approach
is
that
at
the
developer
view
they
just
see
the
the
ability
to
create
dynamic
storage
and
they
do
that
via
something
called
a
storage
class
resource,
and
this,
this
storage
class
is
really
the
glue
between
openshift
and
the
storage
provisioning.
You
see
in
there
that
the
provisioner
is
Gluster
FS,
so
kubernetes
has
that
provisioner,
and
you
also
see
that
there
is
a
route
there.
That
is
the
Hettie.
That
is
the
route
to
the
Cutty
service.
B
B
You
know
Peavey's
persistent
volumes
on
our
storage,
so
we
secure
it
via
again
an
open
chef
resource
called
a
secret
and
that
that
makes
up
the
stores
class
that
this
again
is
completely
a
kubernetes
OpenShift
resource
and
we're
going
to
use
it
to
the
left
there.
You
just
see
that
you
know
Keti
is
in
the
middle
when
open
stuff
calls
in
for
a
new,
a
new
persistent
volume.
It
goes
through
Katie
when
I
delete
that
project
it's
deleted
with
a
project
and
that
Katie
does
that
work
to
will
also
see
the
heck.
B
Hettie
is
really
useful
for
inspection,
as
well
as
day
two
activities
all
of
your
day
to
adding
more
storage,
adding
more
to
clusters.
All
of
that
is
done
via
the
Hetty
CLI,
and
this
I
think
pretty
much.
We've
already
gone
through
this.
But
just
to
reiterate,
you
know
it's
three,
three
open
shift
or
three
kubernetes
nodes
per
cluster
are
required
because
of
the
replica
3,
so
the
lifecycle
again
I'm
going
through
these
slides.
B
So
you
know
what's
happening
when
I
do
the
demo,
but
the
lifecycle
of
this
is
a
developer
via
a
template
that
let's
say
they
want
to
create
I,
don't
know
my
sequel,
Postgres
application
in
the
template,
they're,
going
to
request
a
persistent
volume
and
in
that
persistent
volume
request
there
will
be
the
defined
storage
cost.
So
that's
really
again:
that's
just
the
glue
is
I
want
a
persistent
volume
from
this
storage
class
of
a
particular
size.
That's
submitted
via
the
storage
class
and
the
Ketty
route
to
the
to
the
storage
back-end.
It
goes
through.
B
B
So
the
first
thing
we
have
there
I
didn't
know
it's
going
to
bomb
the
screen,
but
that's
ok.
So
in
OpenShift
world
instead
of
using
cube,
let
or
cube
couldn't
cube
controller.
So
anyway,
instead
of
using
that
you
use
those
see
see
that's
how
often
I
use
the
other
point.
So
OC
is
essentially
equal
to
that.
So
I
say
you
know
what
do
I
have
so
I
have
already
I.
Did
this
a
couple
hours
ago,
creating
an
open
shift
here
and
we
have
the
m4
the
master,
and
then
we
have
the
three
nodes.
B
So
the
first
thing
I
need
to
do
or
I
can
do.
I
can
put
it
in
a
different
name
space
or
a
name
space
that
exists,
but
in
this
case
just
to
make
it
clean
I'm
going
to
create
a
new
name
space
for
my
deployment
and
I
call
it
container
native
storage
and
now
the
the
one
thing
I
do
need
to
do.
We're
gonna
see
that
the
Gluster
pods
are
going
to
use
the
hosts
networking.
So
we
need
to
give
the
daemon
set
privileged
access.
B
So
that's
done
via
that
and
then
I
just
want
to
show
you
quickly
here.
So
this
is
the
topology
file
I'm
sort
of
starting
from
the
bottom.
But
if
we
look
here,
this
is
a
node,
so
we
put
in
the
node
we
put
in
the
IP
address
that
IP
address
actually
is
equal
to
the
host
so
that
the
hosts
are
and
they're
going
to
have
the
same
and
I
mean
that
the
Gluster
pod,
when
it's
created,
is
going
to
have
that
that
IP
and
then
we
give
it
two
devices
important
thing
on
the
devices.
B
In
this
case
this
is
actually
on
AWS.
So
this
is
an
EBS
volume,
but
you
can.
You
can
put
as
many
storage
devices
just
comma
separated
as
you
want
in
there
there's
reasons
that
let's
say
you
wanted
one
terabyte
for
your
cluster.
You
may
want
to
do
it
in
250
gigabyte
chunks,
so
that
you
know
if
you
need
more
storage
and
you
need
to
add
more
storage
to
your
cluster.
You
just
add
another
250
gigabytes,
so
it's
it
is
useful
and
it's
not
technically
required
to
to
have
the
storage.
B
B
So
here's
my
new
project
and
I'll
start
to
see
the
the
Gluster
pods
coming
up
here
again
there
there
will
be
end
up
there'll,
be
one
on
each
one
of
the
the
node
zero
one.
Two
three
that
I
showed
you
and
they're
starting
to
come
up
once
they
are
available,
then
we'll
it'll
go
on
to
the
Ketty
deployment
and
I.
B
Don't
I'll
just
mention
it,
because
I
don't
want
to
go
back
and
forth
too
much
of
it.
But
remember
on
this
slide:
I
showed
you,
you
know
the
hickety
route
and
when,
when
we
get
done
with
the
deployment
here
we'll,
actually
it
will
automatically
create
that
route
that
we're
going
to
use
in
our
storage
class.
So,
let's
see
how
we're
doing
here
got
one
up.
B
B
You
know
this.
This
does
take
a
little
bit
of
time,
but
when
you
think
about
what
it's
going
to
do
here
and
and
this
CNS
deploy
is
a
Red
Hat
script,
it's
it's
essentially
just
a
very
large
script,
but
this
this
is
very
useful
and
I
just
wanted
to
mention
today
we're
just
going
to
be
looking
at
file
volumes
of
the
type
volumes
of
the
type
file.
B
The
the
latest
CNS
images
are
what
we
call
CNS,
but
essentially
Gloucester
images
that
that
can
be
used
on
McKenney
also
support
I
scuzzy
targets,
as
well
as
the
s3
API.
So
you
know
it.
We
started
with
a
file
because
that
that
is
the
most
sort
of
commonly
used,
so
we're
ready
to
create
and
provide
glossary
volumes.
Let
me
just
quickly
go
back
here
and
show
you
what
we
have
now.
B
It
looks
like
it's
still
killing
off
one
of
them
here,
but
I
just
want
to
point
out
this
route
here.
Okay,
so
that's
the
the
route
and
it
didn't
paginate
really
well,
because
it's
just
a
little
too
big,
but
you
can
see
that
now,
when
I
do
the
pods,
you
can
see
that
I've
got
three
Gloucester
pods
and
a
caddy
pod,
and
if
you
look
at
it
each
one
of
the
Gloucester
pods
is
on
a
this
is
the
IP
address
that
was
in
the
topology
JSON
file.
B
B
We
can
see
that
this
is
our
cluster
that
we
just
created.
We
can
see
that
we
actually
have
one
new
volume.
This
is
a
Hettie
DB
storage.
The
Hettie,
DB
storage,
is
how
the
Peavey's
are
kept
track
of
and,
like
I
said,
if,
if
the
node
the
hickety
is
on
the
haqqani
pod,
it
will
recreate
itself
on
a
new
availability
zone
or
a
new,
a
new
machine,
and
it
will
remount
this.
B
So
very
important
I
just
want
to
show
you
what
the
JSON
looks
like
or
the
AMA
looks
like
for
the
secret.
That
key
is
I,
didn't
point
it
out,
but
when
we
did
seen
us
deploy,
we
gave
it
a
an
option
called
admin
key.
So
we
set
that
password-
and
this
is
the
basics
before
encoding
of
that
password.
So
we're
gonna
go
ahead
and
we're
going
to
create
that
resource.
This
is
an
open
ship
to
resource.
So
now
we
have
a
CNS
secret.
We
also
need
our
cluster
ID
for
our
storage
class.
B
So
that's
our
cluster
ID
again.
This
is
a
Ketty
CLI
command
very
useful
for
for
listing
what
you
have,
and
this
is
our
storage
class.
We
I
showed
you
an
example,
but
this
is
a
this.
Is
you
know
the
example
for
this
deployment?
So
we
have
our
route.
We
have
our
cluster
ID.
If
you
were
doing
this,
you
would
have
had
to
copy
that
cluster
ID
and
put
it
in.
B
But
this
is
you
know,
I,
it's
it
I
did
it
so
that
it's
already
there,
so
we
don't
have
to
do
that
and
we
haven't
seen
a
secret.
So
we're
ready
to
go
on
that,
so
we're
gonna
go
again
and
create
that
resource.
That
resource
is
again
a
kubernetes
OpenShift
resource
storage,
cost
name
just
one
thing
on
the
stores
class
name,
even
if
you're
doing
evaluations.
Maybe
it's
just
me
but
try
to
do
stores
class
names
that
explain
what
it
is
so
like.
If
your
AWS,
you
know,
maybe
put
gp2
into
the
storage
class
name.
B
If
you
just
put,
you
know,
Gluster
that
doesn't
doesn't
say
much
about
what
kind
of
storage
is
so
we
now
and-
and
the
other
thing
I
didn't
point
out
when
we
were
looking
at
it-
is
that
there's
an
annotations
in
the
source
class
that
you
can
add
that
will
make
that
the
default
stores
cost?
What
that
means
is
that
if
I
am
in
my
template,
you'll
see
that
the
template
I'm
going
to
show
you
I
do
have
it.
I
do
have
the
annotation
in
there,
but
you
don't
need
it.
B
B
So
what
we're
going
to
do
now
is
we're
going
to
go
ahead
and
use
we're
going
to
use
this
storage
class
and
and
create
some
storage
for
a
my
sequel
deployment.
So
I
created
a
a
name
space
right
now
in
that
namespace
I'm,
just
gonna
get
it
ready,
so
we
can
watch
it.
There's
nothing
in
it
right
now,
so
we're
going
to
deploy
it
via
the
template.
B
So
let
me
just
show
you
where
it
shows
up
in
the
template.
So
all
we
have
to
do
as
a
developer
now
is
to
include
this
in
our
template
and
in
our
case,
because
I
have
a
default
storage
class.
You
wouldn't
even
have
to
put
this
annotation
in
here.
I
think
it's
sort
of
good
practice,
because
it's
pretty
easy
to
change
a
storage
class
to
not
be
default
for
some
reason.
So
at
least
you
have
it.
B
The
other
thing
we
have
is
a
readwrite
once
important
concept
is
that
the
Gluster
file
volumes
support
read/write
mini
you
know
you
could
have
pods
writing
two
to
one
file
on
a
a
read/write
mini.
This
is
a
read/write
once
because
it's
the
database,
but
the
the
access
modes
are
read,
write
once
read,
write
mini
and
there's
another
one.
That's
that
I!
Don't
remember
right
now
that
it's
not
you
Zuri
often,
but
you
do
specify
that
and
then,
very
importantly,
you
specify
the
size
you
can,
via
in
day
2
activities
or
day
2
task.
B
B
If
we
go
back
to
2
here
we
start
to
see
the
the
deployment,
and
if
we
go
to
the
storage,
we
see
that
we
already
have
our
PV
I
might
be
sort
of
small
I'll
show
it
to
a
different
way.
I
can
show
you
in
CLI,
but
it's
already
been
claimed
via
the
the
CNS
gold
storage
class
and
it's
ready
to
be
used,
go
back
to
our
pods.
So
it
looks
like
that.
We're
still
sort
of
running
this,
usually
that
my
sequel
deployment
goes
pretty
quick.
B
I,
just
I
want
to
show
the
so
if
we
get
returned
here,
you
see
that
I
can
see
that
my
PV
is
bound
and
again
it
tells
me
it
tells
me
the
name
of
the
PVC.
So
in
OpenShift
or
kubernetes
resources
you
have
a
PV
resource
and
you
have
a
PVC
resource.
This
is
a
PVC
resource
that
we
just
created,
but
it
automatically
creates
a
PV
and,
what's
cool
about
that
is
when
you
delete
the
PVC,
the
PV
has
gone
to
it's
not
hanging
out.
B
B
If
I
then
get
a
little
right
now,
what
I
want
to
do
so?
I
want
to
track
this
volume
that
I
see
mounted
in
the
pod
all
the
way
back
to
cluster
so
I'm,
going
to
now
log
in
to
cluster
and
again
we're
back
in
our
container
native
storage
project.
We
log
in
to
the
the
first
we
can
log
with
cluster.
If
you've
ever
used
cluster,
you
can
run
the
the
Gloucester
commands
and
this
the
commands
were
running
right
now
would
be
these
I
mean
cluster.
B
Just
like
OpenShift
has
no
idea
about
Gloucester
Gloucester
has
no
idea
about
open
chef
for
kubernetes,
so
this
this
is
exactly
the
same
command.
I
would
run
in
a
cluster
cluster
that
had
nothing
to
do
with
with
what
we're
seeing
today.
So
we
see,
we
do
see
our
kettie
volume
up
here
at
the
top,
the
very
first
one,
a
caddy,
DB
storage,
and
then
we
see
the
the
volume
that
we
just
created.
We
also
see
that
there
are
three
bricks.
B
So
what
we're
gonna
do
now
in
the
last
activity,
we're
going
to
do
is
just
get
used
to
Katie
again
to
get
more
detailed
information
about
that
volume.
We
we
get
information
about
its
volume,
ID
cluster
ID,
where
it's
mounted
and
it's
replicas
3.
If
you
had
day
2
activities
all
this
would
be
important
to
you.
If
you
wanted
to
increase
your
storage.
Add
more
to
your
cluster.
Add
another
cluster
will
actually
not
add
another
cluster.
B
A
B
Yeah
I
can
speak
to
that.
We
all
this
entire
year
have
been
doing
performance.
Benchmarking
and
the
thing
you
need
to
I
guess
be
you
need
to
realize
is
we
are
doing
replica
three
and
it's
absolute
consistency
so
compared
to
a
single
right,
you're
writing
three
times
right
so
and
that's
good
and
bad.
If
I'm
in
a
double
US
environment,
say
I'm
across
two
different
regions
can
tell
you
because
I've
done
the
latency
testing.
Those
reasons
are
not
in
the
same.
They
are
not
in
the
same
data
center.
B
In
some
cases
they
can
have
like
a
millisecond
of
delay,
which
is
about
twenty
thirty
miles.
In
that
case,
you
know
your
slowest
right
is
going
to
control
your
right,
speed
and,
in
general
reads
no
problem
at
all,
but
because
I
read
is
is,
is
a
single,
it's
not
a
replica
three,
but
but
the
rights
you
know
you
do.
We
have
a
maximum
of
five
millisecond
latency
budget
diameter
between
the
replicas
and.
A
B
A
B
A
It's
so
we
took
the
default
route
right
now,
replica
three
right.
We
fully
intend
to
support
the
other
replicas
right
now,
we're
not
probably
sizing.
The
challenge
is
that
if
you're
running
on
top
of
the
platform
we
do
want,
you
know
the
kubernetes
can
reschedule
anywhere.
No,
it
can
go
down.
We
wanted
to
protect
there,
so
there
repent.
Then
there
are
options
like
replica
to
Plus.
You
know
arbiter
kind
of
approach,
so
we
will
be.
You
know
making
that
as
an
option,
because
Gloucester
already
supports
that
so
we'll
make
that
available.
Yeah.