►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everyone
welcome
to
cloud
native
live
where
we
dive
deep
into
the
code
behind
cloud
native.
I'm
annie
talvasto
and
I
am
a
cncf
ambassador,
as
well
as
the
product
marketing
manager
cast
ai,
a
kubernetes
cloud
cost
optimization
company
very
much
a
welcome
on
my
part.
So
every
week
we
bring
a
new
set
of
presenters
to
showcase
how
to
work
with
cloud
native
technologies.
A
They
will
build
things,
they
will
break
things
and
they
will
answer
your
questions
join
us
every
wednesday
at
11
a.m.
Et
so
this
week
we
have
the
pleasure
to
have
alex
jai
corp,
kai
porp.
Hopefully
I'm
not
even
butchering
the
name.
You
can
give
the
correct
pronunciation
shoe
soon
hear
us
with
us
to
talk
about
a
very
exciting
topic,
so
join
us
for
kubecon
plus
cloud
nativecon,
virtual
north
america
october
11th
to
15th
to
hear
the
latest
from
the
cloud
native
community.
A
B
Thank
you
so
much
anna
and
good
morning,
good
afternoon,
good
evening,
wherever
you're
watching,
I'm
really
excited
to
be
to
be
presenting.
Today
and
and
hopefully
you
wouldn't
have
jinxed
the
demo
guards
and
my
demo
will
just
work.
B
Great
okay,
if
we
can
switch
to
the
slides.
B
Brilliant,
so
I'm
going
to
be
talking
today
about
kubernetes
and
persistent
data
and
stateful
workloads,
which,
which
I'm
sure
is
something
which
is
a
very
you
know,
commonly
a
very
common
pain
point
in
in
many
use
cases
when,
when
using
kubernetes.
B
So
before
we
start
a
little
bit
a
little
bit
about
myself,
my
name
is
alex
kirkhoff,
I'm
very,
as
you
can
tell
I'm
very
passionate
about
storage,
I'm
the
founder
and
ceo
of
storage
os
where
we're
building
a
software
defined
cloud
native
storage
platform.
B
But
I
also
have
two
hats:
I'm
I'm
the
co-chair
for
the
cncf
storage
tank,
that
was
formerly
the
cncf
storage
sig
and
basically
my
background
is
is
in
engineering
and
infrastructure,
and
I
did
that
for
25
years
before
the
the
startup
bug
got
me
and-
and
you
know
promoted
me
into
this
into
this
into
this
direction
and
adventure
which
is
which
is
pretty
cool,
as
always,
we'll
try
and
keep
this
interactive.
B
So
if,
if
there
are
questions,
please
feel
free
to
stick
them
in
the
chat
and
I'll
try
and
answer
them
as
we
go
along
or
other
at
an
opportune
moment
in
the
presentation,
I'm
going
to
do
a
little
shameless
plug
with
my
with
my
co-chair
hat
on
I'd,
like
to
just
sort
of
mention
that
the
a
lot
of
the
topics
that
we're
talking
about
today
are
the
sort
of
topics
and
and
technical
work
that
we
do
as
part
of
the
tag
storage
in
in
in
the
cncf
we
meet
every
couple
of
weeks
and
all
the
calls
are
open.
B
Okay,
with
that
plug
out
of
the
way,
I'm
going
to
talk
a
little
bit
about
just
to
set
the
scene,
the
the
the
journey
to
cloud
native
that
we
see
a
lot
of
organizations
big
and
small,
doing
to
when
they
when
they're
when
they
start
when
they
first
adopt
this.
This
this
this
new
paradigm
and
really
you
know
this
is
kind
of
obvious.
But
obviously
you
know
developers
starting
off
with
with
containers
is.
The
first
is
the
first
step.
B
The
big
thing
that
containers
do
is
it
kind
of
it
breaks
that
lock-in
to
individual
servers
right
so
so
we
we
now
have
portable
codes
that
can
run
anywhere
and
obviously,
by
allowing
codes
to
run
anywhere
you
you
enable
the
ability
to
automate
code,
and,
of
course
you
know,
that's
where
kubernetes
comes
in
and
kubernetes
is
now
the
de
facto
container
orchestrator
that
allows
the
automation
of
applications
in
in
just
about
any
environment.
B
In
fact,
you
know
you
can
think
of
kubernetes
as
a
layer
that
abstracts
the
infrastructure
and
provides
developers
with
a
way
of
composing
what
their
application
needs.
So
so
so
developers
can
now
say
my
application
is
formed
of
these
containers
and
it
needs
this
amount
of
cpu
and
this
amount
of
memory
and
these
sort
of
networking
requirements
and
kubernetes
can
just
go
ahead
and
make
that
happen
and
can
also
automate.
You
know
not
just
the
deployment
but
also
scaling
healing
and
and
a
variety
of
other
advanced
features
too.
B
So
you
know
there's
there
are
all
of
the
self-managed
and
you
know
common
distributions
that
we
see
with
with
with
kubernetes.
You
know,
products
like
rancher
and
openshift,
and
and
and
even
you
know,
simple
things
like
like
cube
adm,
where,
where
we
can
provision
and
manage
our
own
kubernetes
clusters,
of
course,
there
are
kubernetes
services
which
are
available
in
in
all
the
public
clouds,
and
there
are
more
and
more
you
know,
managed
service
providers
and
and
and
service
providers
of
all
sizes
providing
managed
kubernetes
services
too.
B
And
of
course
you
know
you
have
you
also
have
environments
running
on
laptops,
so
the
the
nice
thing
about
using
kubernetes
means
that
you
can
have
the
same
bit
of
yaml.
That
defines
your
application
and
whether
you're
running
it
on
your
laptop
on
premise,
on
big
bare
metal
environments
in
the
clouds
and
managed
service
providers,
or
in
fact
you
know
using
any
number
of
of
the
certified
cncf
distributions.
B
You
get
the
same,
you
get
the
same
user
experience
and
the
application
can
can
run
everywhere.
B
So
when,
when
we're
talking
about
some
of
the
applications
and
and
and
you
know,
we're
we're
quoting
a
data
dog
survey
here
in
terms
of
you
know
the
top
containers
that
are
that
are
running
in
in
in
people's
environments.
We
kind
of
see
that
you
know
there
are
some
platforms
which
are
which
don't
require
statements
on
platforms
which
are
ephemeral.
We,
we
obviously
have
a
lot
of
most
most
end.
Users
start
with
some
sort
of
stateless
or
or
ephemeral
workload.
B
You
know
perhaps
nginx,
perhaps
perhaps
red
is-
and
you
have
you
know.
Things
like
nginx
can
is,
is
really
easy
to
deploy
without
without
storage
and
it's
kind
of
easy
to
create
and
delete
instances
of
of
the
product,
and
the
same
sort
of
thing
applies
for
redis
and
in
a
very
in
a
very
simple
in
a
very
simple
configurations.
B
However,
we'll
talk
a
little
bit
about
why
applications
need
state
and
why,
I
think
you
know
all
applications
need
to
store
state
somewhere.
So
that's
the
spoiler,
but
the
the
the
key
thing
here
is
that
ephemeral
workloads
kind
of
have
problems,
because
they
always
need
to
refer
to
something.
That's
going
to
be
storing
data
somewhere
right
and
that
can
be
a
service.
It
can
be.
B
A
database
can
be
an
object
store,
it
can
be
a
file
system
and
and
therefore
what
we,
what
we
end
up
seeing
is
a
lot
of
legacy
environments.
You
know
whether
it's
it's
simple
ec2
instances
running
in
in
your
cloud
or
vms,
running
alongside
your
your
your
kubernetes
instance
and,
of
course,
the
the.
B
What
this
means
is
that
even
the
applications
that
can
run
ephemerally
tends
to
be
running
in
a
less
optimal
way,
because
those
those
systems
can
now
can
can
now
not
use
the
a
storage
system
that's
available
to
them.
So,
for
example,
you
know
recovery
times,
for
these
applications
can
be
longer
and
it
can
be.
It
can
take
a
lot
of
time
to
warm
up
these
systems
like
like
caches,
like
redis,
for
example,
and
so
you
kind
of
end
up
with
a
ton
of
scaffolding
that
is
put
around
these
systems.
B
You
know
and
we
we
start
detracting
from
the
benefits
that
kubernetes
provides.
So,
for
example,
you
know
one
of
the
one
of
the
workarounds
that
we
kind
of
commonly
see
is
where
we
we
remove
the
ability
of
kubernetes
to
dynamically
place,
application
workloads
based
on
you,
know,
capacity
or
or
or
utilization
of
the
nodes
and
and
we
we
start
tying
down,
applications
to
individual
nodes,
and-
and
this
is
this
is
a
really
big
challenge,
because
the
whole
point
of
of
kubernetes
is
there
to
to
abstract
away
the
infrastructure.
B
But
what
we
see
is
storage
in
in
to
a
large
extent,
that
is,
and
still
is
something
that
you
present
and
bind
to
a
server
and
what
we're
and
what
we
need
to
to
move
away
from
and
what
we
need
to
start
thinking
about
is
how
do
we
make
storage
composable
and
how
do
we
start
making
storage
bounds
to
the
application,
because,
at
the
end
of
the
day,
it's
the
application
that
needs
to
move
around?
It's
the
application
that
needs
to
be
dynamic.
B
So
so
here's
the
the
sort
of
you
know
my
premise
and
it's
it's
it's
not
always
it's
not
always
obvious,
and
it's
not
always
a
you
know
a
popular
statement
but
I'll
I'll
go
ahead
and
say
it.
B
You
know,
I
think,
all
applications
store
state
somewhere
right,
even
even
even
the
most
simplest
of
applications
will
store
data
in
a
file
or
a
database
or
an
object,
store
or
a
key
value
store
or
a
message,
bus
or
streaming
or
or
something
right,
there's
always
going
to
be
something
there
and
the
question
is
then,
once
you're
using
kubernetes.
B
How
do
you
make
take
advantage
of?
How
do
you
take
advantage
of
kubernetes
to
to
actually
automate
the
the
storage
and,
and-
and
the
answer
is
you
know,
cloud
native
storage
and
there's?
There's
there's,
obviously
a
wide
variety
of
of
of
options
here?
B
What
we're
going
to
focus
on
a
little
bit
today
is
is
software-defined
options,
because
you
know
we
talked
about
all
of
the
different
ways
that
people
can
use
kubernetes,
whether
it's
you
know
on
laptops
in
in
managed
services,
in
cloud
providers,
on
prem,
etc,
etc,
and
and
therefore,
if
you've
made
your
application,
portable
you've
made
your
application.
Composable
you've
got
composable
memory
and
compute
and
networking.
B
B
Now
that
that
developers
can
compose
what
they
need
in
terms
of
cpu
memory
and
network,
you
also
have
the
ability
now
for
developers
to
compose
what
they
need
from
the
storage
and
and
have
that
storage
be
application-centric
and
fundamentally,
it
allows
you
to
it
allows
developers
and
devops
teams
to
to
move
any
of
the
applications
and
take
advantage
of
kubernetes
for
any
application,
and-
and
specifically,
you
know,
build
anything
as
a
service,
because
the
the
other
effect
of
of
being
able
to
compose
this
is
that
you
can
now
create
a
database
as
a
service
or
or
say
a
message.
B
Bus
as
a
service
or
or
even
you
know,
with
with
with
some
of
the
with
some
of
the
cncf
projects
like
kubert,
for
example,
where
you
know
kubernetes
can
actually
manage
vms.
You
can
even
create
infrastructure
as
a
service.
You
know,
and
in
fact
we
certainly
have
clients
managing
you
know,
vms
in
in
in
that
sort
of
environment.
B
So
what
we're
kind
of
saying
with
a
software-defined
cloud-native
storage
is
kind
of
treating
persistent
data
like
networking
technologies,
and
this
is
kind
of
a
given
right,
so
so,
whether
if
in
in
all
of
the
different
environments,
you
know
you
have
a
variety
of
different
cni
providers
which
effectively
give
you
the
capability
of
having
software-defined
network
systems
that
that
provide
meshes
that
provide
service
discovery
that
provides
routing
and
and
and
services
and
kubernetes,
and
all
those
services
run
natively
as
demon
sets
and
people
just
don't
think
about
it.
B
It's
one
of
those
things
it's
just
there.
What
we're
basically
saying
is
that
you
can
have
the
same
sort
of
things
with
the
software
defined
storage.
So,
of
course
you
know,
storage
us
is
one
of
those,
but
again
with
my
cncf
go
to
our
hat
on.
You
know.
There
are
obviously
a
number
of
different
projects
in
this.
In
this
space,
but
effectively
we
can
have
an
operator
or
a
demon
set
that
can
operate
in
these
environments
and
what
we,
what
we
then
get,
is
we
get
the
ability
to
effectively.
B
You
know,
abstract
the
storage,
that's
in
your
kubernetes
environment
and
provide
the
platform
agnostic
way
for
applications
to
access
the
storage.
The
the
key
thing
here
is:
you
now
have
that
portability,
so
applications
can
move
to
any
nodes.
Nodes
can
fail,
and
that's
a
really
important
usage
pattern
here
right
because
in
kubernetes
clusters,
if
you're
going
to
you,
know
upgrade
versions
if
you're
going
to
patch
versions,
if
you're
going
to
use,
say
spot
instances
etc.
B
You
generally
have
dynamic
clusters
where
nodes
come
and
go
and
nodes
can
be
upgraded
on
the
fly
so
so
applications
just
move
around
a
lot
more
in
a
kubernetes
world
and
therefore
being
able
to
to
have
that
that
that
you
know
in
in
a
similar
way
that
you
can
sort
of
create
a
service
mesh
in
the
networking
space.
You
kind
of
need
you
kind
of
effectively
have
the
same
sort
of
space,
the
same
sort
of
mesh
in
in
the
storage
space
that
allows
you
to
access
the
storage
from
everywhere
and
kubernetes
has
done.
B
You
know
a
really
good
job
of
creating
the
concept
of
storage
classes
and
storage
classes,
effectively
define
a
way
of
dynamically
provisioning
volumes
and
accessing
those
volumes.
So
a
storage
class
is
kind
of
a
very
fancy
way
of
saying.
B
This
is
a
name
that
I
give
to
a
group
of
due
to
a
group
of
volumes
it
it
tends
to
refer
to
a
driver.
Almost
every
kubernetes
deployment
nowadays
will
have
some
sort
of
default
storage
class,
but
the
but
the
nice
thing
here
is:
you
can
create
storage
classes
with
different
services.
You
know,
of
course,
depending
on
the
the
projects
you're
using
and
the
cloud
providers
you're
using
to
actually
do
different
things
for
different
purposes.
B
So
so,
for
example,
you
may
have
a
storage
class
that
you
use
for
for
development
workloads
where,
where
perhaps
you
you're
you're,
not
actually
interested
about
availability
or
or
or
replicas,
but
you're
interested
in
just
making
sure
that
the
date
is
available
across
all
of
the
nodes.
You
might
have
a
production
system
where
you
you,
you
want
to
focus
on
availability
and
you
want
data
to
be
replicated
across
different
nodes
in
the
cluster.
B
You
know
to
protect
against,
say,
disk
failures
or
node
failures
or
or
that
sort
of
thing
you
may
use
storage
classes
to
defying
a
security
level
where,
where
perhaps
you
might
have,
you
know
certain,
are
back
rules
or
policies
or
or
encryption
enabled,
and
you
might
also
you
know,
have
storage
classes
that
affect
things
like
the
the
data
redund,
the
data
redundancy
or
the
or
the
data
compression
capabilities,
for
you
know,
say
archive
or
or
or
data,
which
is
which
is
not
often
used
or
very
cold,
and
just
as
a
and
just
as
an
example,
you
know
I've
got
a
storage
class
listed
here
on
the
left.
B
B
Csi
is
the
container
storage
interface,
which
kubernetes
will
use
as
a
as
a
standardized
api
to
to
talk
to
a
variety
of
different
systems,
and
I
think
at
present
counts.
There
must
be
50
or
60
different.
Different
csi
drivers
out
there
and
you'll
then
have
a
number
of
parameters
that
might
define
you
know
things
like
secrets
or
or
the
number
of
replicas
or
or
things
like
that,
which,
which
would
which
might
be
specific
to
you,
know
a
certain,
a
certain
storage
driver
but
effectively.
B
That's
that's
where
you
know
the
the
definition
of
storage
stops
right
because
from
then
on,
applications
can
just
use
persistent
volume
claims
and
then
persistent
volume
claim
is
effectively
just
a
way
of
saying.
Oh
an
application.
B
I
want
to
have
data
which
is
persistent
and
stateful,
and
I
want
to
give
it
a
name
which
I
can
then
reference
in
my
applications.
So
in
this
case,
for
example,
the
persistent
volume
claim
is
is
the
is
the
box
on
the
right
and
we
have
we're
creating
a
pvc
which
is
called
mysql,
pvc,
presumably
for
mysql
database
and
in
general.
B
The
only
thing
that
that
you'll,
that
you'll
need
to
specify
is
something
simple
like
the
size,
because
everything
else
gets
inherited
through
the
storage
class,
which
in
this
case
you
know
we're
referring
to
the
production
storage
class
defined
on
the
left
and
and
the
thing
is
you
know,
using
these
using
these
capabilities,
you
can
do
a
lot
of
advanced
things,
so
some
systems,
for
example,
supports
the
use
of
of
encryption
and
have
automation
with
kubernetes
secrets
or
external
key
management
services
to
to
automatically
encrypt
the
data.
B
Typically,
that's
done
through
the
use
of
some
sort
of
labels
or
other
parameters,
as
you
can
see
in
this
in
this
example
here
and
applications
like
in
this
case,
mysql,
for
example,
can
can
rely
on
on
on
precision
date
and
they'll.
Just
continue
to
run,
you
know,
and
we
can
kind
of
see
the
scaffolding
and
those
legacy
environments
fading
out
into
the
background
and
kubernetes
coming
out
and
being
able
to
use
all
of
the
power
of
kubernetes
here.
B
And
if
you
look
at
the
example
piamel
on
the
right,
we
can
kind
of
see
we
can
kind
of
see
an
example
of
that
of
that
mysql
database
and
what
it
would
take
to
run
so
I'll
I'll.
Just
sort
of
talk
you
through
it
very
quickly.
B
Here
we
have
a
really
simple
definition
where
we're
saying
we're:
creating
a
mysql
instance
using
the
mysql
container,
we're
defining
a
mount
point
which
is
which
is
effectively
a
unix
part
within
the
container
namespace,
that's
going
to
mount
amount,
that's
going
to
mount
a
volume
and
that
volume
is
called
my
sql
dash
data.
B
And
then
what
we're
saying
is
we're
saying
that
the
volume
mysql
data
is
actually
to
use
the
persistent
volume
claim
called
mysql
pvc.
So
so
what
what
happens
in
this?
In
this
instance,
when
the
when
the
container
is
being
scheduled,
is
that
the
the
attach
request
will
be
issued
via
the
csi
api
kubernetes?
Will
will
attach
the
the
volume
to
the
node
where
it
needs
to
run
mysql
and
then
that
will
be
mounted
and
put
into
the
container
namespace
and
effectively.
As
far
as
the
mysql
instance
is
concerned,
it's
it's.
B
It's
accessing
a
local
volume,
but,
of
course,
that
that
volume
is
is
actually
persistent
and
and
is
and
is
available
across
across
container
mounts,
and
if
the
demo
guards
smile
down
on
me
I'll
I'll
show
a
little
demo
of
running
in
my
sequel,
my
sequel
image
in
just
that
fashion.
In
a
minute,
another
thing
which
is
which
is
worth
pointing
out
is
that
volumes,
for
example,
with
with
kubernetes,
cannot
can
be
read,
write
once
or
read.
B
Write
many
read:
write
many
volumes
effectively
allow
a
volume
to
be
used
by
multiple
pods
at
the
same
time,
on
different
nodes-
and
this
is
you
know,
sometimes
this
could
be
implemented
via
nfs,
but
there
are,
you
know,
a
variety
to
different
file
systems
which
which
allow
these
services
and
one
of
the
key
things
here
is.
B
You
know
there
are
many
applications
that
that
benefit
from
from
having
a
shared
volume
that
they
can
refer
to.
Perhaps
it's
sharing
some
some
common
reference
data
or
some
common
config.
Sometimes
it's
just
you
know
using
a
file
system
as
a
as
a
message
bus
as
as
horrible
as
that
sounds
you.
You
often
have.
B
You
often
have
environments
where
you
have
a
workload,
a
workflow
of
of
of
transforms,
for
example,
where
you
know
one
application
hands
over
to
another
application
across
across
a
shared
file
system,
and
these
sort
of
things
are
are
very
common
work,
work
loads,
which
you
can
find
in
many
kubernetes
environments,
and
it's
it's
a
it's
a
very
effective
way
of
doing
it.
B
And,
of
course
you
know
you
also
have
you
also
can
unlock
a
lot
of
additional
functionality
using
the
persistent
storage,
for
example,
redis
becomes
more
than
just
an
ephemeral
cache
and
becomes
you
know,
full-blown
database
with
with
with
persistent
storage.
You
know
and
and
enables
a
whole
suite
of
of
different
and
advanced
use
cases,
and
the
other
thing
that
we
often
see
more
and
more
now
is
with
with
the
use
of
githubs,
is
the
ability
of
actually
having
a
standardized
way
of
deploying
applications
across
your
different.
B
B
But
what
you
can
have
is
you
can
have
storage
classes
with
the
same
name
in
each
of
those
different
environments,
but
defined
with
different
specifications
as
needed
by
those
by
those
environments.
B
So
you
can
have
the
same
the
same
piece
of
yaml
to
start
the
same
database,
for
example,
and
have
no
replication
on
your
laptop
and
have
you
know
replication
with
with
for
for
production
availability
when
it's
on
prem
and
maybe
add
encryption
if
you're
running
in
the
client,
for
example,
and
those
sort
of
things
mean
that
that's
you
know,
it
makes
it
that
much
easier
for
ci
cd
environments,
especially
when,
when,
when
managed
by
by
github's
processes
to
to
to
evolve
in
those
in
those
spaces.
B
Okay,
then
so
that
takes
me
neatly
on
to
the
demo.
So
this
this
is
the
base.
Where
things
get
a
little
scary.
I
will
stop
sharing
that
screen
and
I'll
share.
My.
B
Goes
wrong
I'll
I'll
talk
you
through
it
and,
as
usual,
just
feel
free
to
ask
questions
at
any
point,
so
I've
just
just
just
for
a
reference
of
of
alias
k2
to
cube
cuddle,
just
because
it's
easier
to
type.
B
B
So
here
I'm
looking
at
the
cube
system,
namespace,
which
obviously
has
you
know
things
like
psyllium
running
in
there,
which
is
you
know,
the
demon
set
for
the
networking,
you'll,
see
other
things
like
q,
proxy
and
and
core
dns,
for
example,
which
are
other
services
there,
and
in
this
case
I've
got
a
storage
usd
set
running
in
there
to
provide
to
provide
the
the
the
cloud
native
software
defined
storage
capabilities,
so
we'll
we'll
switch
that
to
the
default
namespace.
Instead,
I
just
want
to.
B
B
We
see
a
bunch
of
parameters
and
that's
really
it
and
when
we,
if
we,
if
we
switch
back
to
k9s
and
look
at
the
running
systems,
you'll
you'll
tend
to
see
something
like
a
csi
helper
here,
which,
which
has
a
number
of
different
csi
functions
in
there
to
to
do
things
like
provisioning
and
attach
volumes
and
and
that's
effectively
the
api
endpoint
that
kubernetes
will
be
talking
to
when,
when
looking
to
provision
the
volume.
B
So
on
the.
If,
if
you,
if
you
have
a
look
at
docs.surgeries.com,
you
have
a
whole
section
of
use
cases
where
we
have
put
together.
You
know
a
number
of
simple
examples
covering
my
sequel:
postgres
redis,
you
know
kafka
jenkins,
even
cute,
and
those
are
those
are
some
some
fun
things
to
to
try.
If,
if
you
want
for
today,
I'm
going
to
be
looking
at
a
my
sequel,
my
sequel
demo,
so
what
we
have
in
our
mysql
demo
is.
B
We
have
a
mysql
service
that
that
uses
ports
3306
in
this
case
and
allows
us
to
access
mysql
transparently
within
within
the
environment.
There's
a
little
bit
of
config
for
my
sequel
and
then
we
define
a
stateful
set.
So
a
stateful
set
is
effectively
one
of
the
one
of
the
objects.
One
of
the
management
controller
objects
that
kubernetes
supports.
It's
a
stateful
set
is
what's
used
when
we're
defining
stateful
workloads
and
kubernetes
does
does
a
good
job
of
making
sure
that
stateful
workloads
have
extra
functionality
like,
for
example,
it
protects.
B
It
protects
stable
workloads
from
from
running
in
multiple
instances,
and
it
protects
them
from
partition.
Events
and
things
like
that,
as
as
one
of
the
few
things
as
one
of
the
things
that
differs
between,
say,
stateful
sets
in
the
standard
container
or
deployment
and
what
we
can
see
with
the
staple
set
similar
to
the
to
the
example
that
we
were
just
looking
at
is
we
have
a?
B
B
So
what
I
will
do
is
I
will
just
look
to
create
that
my
sql
workload
I'll
just
switch
to
the
default
namespace.
That
will
be
obvious.
Okay,
so
we
created
them.
We
can
see
the
containers
creating,
there's
a
client
container
in
the
mysql
database
container,
which
is
which
is
just
creating
now.
What
we
can
see
is.
B
The
we
have
the
my
sequel
database
has
created.
A
persistent
volume
claim
called
data
mice,
equal
zero,
and
if
we
describe
the
pvc.
B
B
We
can
effectively
see
that
kubernetes
has
mounted
the
volume
into
the
carbonate
into
the
mysql
namespace
as
far
live
mysql.
So
as
far
as
as
far
as
the
pod
is
concerned,
it's
just
running
with
a
persistent
volume
under
violet
mysql.
It
doesn't
know
it's
very
that's
a
persistent
volume.
It's
completely
abstracted,
it's
just
another
fast.
It's
just
like
another
local
file
system.
B
B
I
will
show
the
databases,
so
that's
those
are
just
like
the
standard
databases
that
that
we
would
have
in
a
in
a
simple
mysql
system.
What
I'm
going
to
do
is
I
am
going
to
create
a
database
and
I'll
go
with
something
more
creative
than
alex
and
call
this
cncf
live.
B
And
now,
when
we
show
databases
cncflive
is,
is
there
listed
as
a
database?
So
what
I'm
going
to
do?
What
I'm
going
to
do
is
we'll
we'll
start
by
actually
doing
something.
You
know
pretty
drastic
in
a
normal
environment.
B
If
we,
if
we
deleted
the
stateful
set,
we
would
obviously
lose
all
the
data
because
it
would
just
be
ephemeral
data
and
that
and
and
that
that
database
that
we
just
created
would
be
gone
for
good.
But
what
we'll
do
is
we'll
we'll
delete
the
database
and
we
can
see
the
database
terminating
within
within
k9s.
B
B
And
that's
that
took
a
couple
of
seconds.
I
think
that's
just
downloading
the
container
and
what
we
can
see
is
if
we
go
to
show
the
databases.
B
B
Now
what
we
also
just
just
to
kind
of
take
that
demo-
and
this
is
a
really
simple
and
a
very
boring
demo,
but
but
it
it
does
show
sort
of
the
the
the
flexibility
and
and
the
and
the
power
of
of
having
that
cloud
native
storage.
But
what
we'll
do
is
just
to
just
to
sort
of
prove
that
I'm
not
actually
you
know
making
this
up
and
and-
and
you
know,
cheating
in
any
way
will
will
actually
cordon
the
nodes
that
the
workload
is
working
on.
B
And
this
will
kind
of
give
us
an
idea
of
what
of
what
the
the
availability
will
look
like
and
I'm
actually
going
to
terminate
it.
I'm
actually
going
to
terminate
that
that
pod
now
so
that's
been
deleted.
B
B
B
B
You
have
a
fully
service.
That's
that's
automated
with
the
power
of
kubernetes
and
persistent
volumes,
and
this
is
something
which
is
available
in
all
of
your
clusters
today.
So
I
strongly
suggest
that
you
go
out
and
try
it
and
if
you
have
any
questions
happy
to
answer
them.
A
Perfect,
I
think
the
boring
and
simple
demos
are
usually
the
best
as
well
yeah.
So
now
is
the
time
for
the
audience
to
to
ask
questions
if
I
got
that
correctly,
so
so
ask
away
people
and
and
leave
the
questions
to
the
chat
area.
So
we
can
get
some
conversation
going
on,
of
course,
as
well
waiting
waiting
looking
forward
to
the
questions
from
everyone.
C
A
I
know
I
know
exactly
the
feeling.
I
think
I
have
every
time
I
I
do
a
demo
and
if,
if
there's
something
that
needs
to
like
spring
up
or
what
not
wordpress
or
anything
that
takes
like
few
minutes
when
I
try
it
out
before
the
demo,
it
takes,
let's
say
one
minute
to
two
minutes
and
then
during
the
demo
it
always
takes
seven
minutes,
and
I'm
just
so
typical.
A
Yeah
but
while
we
wait
for
the
audience
questions,
I
can
maybe
ask
a
few
to
get
the
conversation
started.
A
Yeah,
so
you
mentioned
in
the
beginning
that
there's
a
lot
of
cncf
projects
in
the
space
that
are
doing
a
great
work
and
are
doing
kind
of
interesting
things.
So
what
are
your
favorites
and
why.
B
So
that's!
Okay!
That's!
That's!
That's
a
very
good
question.
So
when
we
talk
about
business
and
storage
in
in
the
cncf,
it
covers
actually
quite
a
wide
variety
of
different
technologies.
So
you
know
persisting.
Data
can
be
done
in
any
number
of
ways.
The
most.
The
most
obvious
thing
is
a
is
volumes
where
we
have.
B
You
know,
block
stores
and
file
systems,
but
we
also
have
you
know
a
huge
number
of
systems
which
are,
of
course
accessed
via
apis
and
that
can
be
databases,
key
value
stores,
object
stores,
for
example,
and
so
when,
when
we
one
of
the
one
of
the
things
that
we
did,
one
of
the
first
things
we
did
as
part
of
the
seiko,
which
is
now
the
tag,
is
to
create
a
cloud
native
storage
white
paper.
B
That
kind
of
defines
all
of
those
different
options
and-
and
both
you
know
the
the
data
parts
of
how
you
access
those
different
systems,
but
also
the
control,
plane
management
and
how
you
automate
things
like
dynamic,
provisioning
and
access
of
these
of
these
different
systems,
and
we
actually
also
defined
because
you
know
one
of
the
interesting
things
here
is
that
for
the
first
time
ever
developers
actually
get
to
choose
what
storage
systems
they
need
that
they
they
want
to
use.
So
it's
it's
it's
more
complicated
than
you'd.
B
Imagine,
there's,
there's,
obviously
a
lot
of
different
options
available
for
for
different
use
cases,
and
so
you
know
we
we
kind
of
encourage
users
to
understand
what
attributes
their
application
requires
from
from
their
from
their
system
to,
and
we
define
the
number
of
attributes
like
availability,
and
you
know
performance
and
durability
and
data
protection,
these
sort
of
things
which
which
which
which
can
affect
what
what
what
you
need
out
of
your
storage
system.
B
Some
of
the
some
of
the
projects
that
we
have
in
the
tag
storage
includes
things
like
xcd,
which
is
which
is
obviously
a
key
value
store,
and
it's
it's.
It's
used,
as
as
I
guess,
the
brains
of
of
every
kubernetes
cluster
out
there.
There
are
projects
like
ti,
tikv
or
tai
kv,
which
is
which
is
a
distributed,
which
is
another
distributed
key
value
store.
B
There
are
also
products
like
vitesse,
which
are
which,
which
came
out
of
youtube,
and
it's
a
distributed
database,
for
example,
and
we're
actually
talking
about
some
of
these
things
and
some
of
the
different
storage
attributes
in
in
our
kubecon
presentation
in
I
guess,
just
over
a
month
away,
so
attend
that
as
well.
If
you
want
to
hear
more
about
about
those
different
projects,.
A
Perfect
nice
plug
there
as
well
for
kubecon
and
collaborative
con,
that's
upcoming
in
a
month
yeah
and
I
think,
there's
an
audience
question
which
is
very
exciting.
I
will
just
read
it
out
loud,
so
you
can
get
to
answering.
Will
you
share
some
observations?
The
story,
preferences
or
recommendations
for
distributed
storage
in
kubernetes
they'd,
especially
in
be
interested
in
anything
related
to
multi-cluster,
kubernetes
persistence.
For
example.
Do
you
tend
to
prefer
application?
B
Okay,
so
there's
there's
a
bit
to
unpack
there
again,
the
the
question.
The
question
is
not
about
you
know
it's
hard
to
make
a
recommendation
one
way
or
another
simply
because
there
are
lots
of
different
systems
available
and
and
they're
optimized
for
for
different
use
cases.
So
you
know
some
systems
might
be
optimized
for
for
latency
and
and
transactions.
Others
might
be
optimized
for
sequential
throughput
and
and
analytics,
for
example,
and
and
they
would
be
very,
very
different
systems.
So
it's
it's
hard
to
make
a
generic
recommendation.
B
The
the
reality
is
that
there
are
that
there
are
a
number
of
different
file
systems,
software-defined
storage
systems,
object,
stores,
databases,
etc.
That
fits
different
use
cases.
So
more
than
anything
else
understand
the
use
case.
That's
it
application-centric
storage,
I
think,
is
the
is
the
key.
The
the
point
behind.
That
is
that
if
you
have
an
application
which
is-
and
you
want
to
be
able
to
compose
it,
you
need
to
actually
link
it
to
the
storage
and
we
have
in
in
kubernetes.
B
We
have
like
we,
we
discussed
today
the
concept
of
volumes
and
and
that's
probably
the
most
mature
functionality,
but
application.
Centric
storage
can
also
refer
to
things
like
object
stores
and
there's
there's
now
the
cozy
init
initiative,
which
is
which,
which
enables
the
the
orchestration
of
things
like
object,
store,
buckets
and
and
access,
and
I
can
can-
can
define
those
sort
of
access
methods
as
well.
B
B
Databases
and-
and
things
like
that,
as
well
in
terms
of
in
terms
of
multi-cluster,
that's
certainly
a
a
a
fairly
immature
process.
But
what
we're
seeing
in
in
a
lot
of
environments
is
that
the
customers
or
enterprises
and
organizations
are
deploying
a
larger
number
of
smaller
clusters
and
perhaps
clusters
for
you,
know
specific
applications
or
specific
projects.
B
Rather
than
have
these
these
huge
multi-talented,
you
know
big
scalable
clusters,
so
I
think
more
than
ever
before
there
is
the
need,
and
therefore
you
know,
projects
will
be
working
on
this
to
to
provide
the
capability
to
consume
storage
across
clusters,
but
also
to
to
replicate
and
move
data
across
across
clusters
and
we're
we're
kind
of
seeing
also
some
work
being
done
in
in
hybrid
environments.
B
Where
we're
looking
at
the
ability
of
sharing
storage
between
kubernetes
and
say
you
know
traditional
traditional
systems,
whether
it's
it's
because
those
traditional
systems
haven't
yet
been
made
the
transition
into
kubernetes
or
because
you
know
they
can't
be
migrated
for,
for
whatever
reason
you
know
perhaps
they're
using
some
old
code
or
something
so
so
I
think
I
think
that
is
that
is
always
going
to
be.
A
factor
when
it
comes
to
sort
of
api
versus
volumes
is
the
sort
of
the
last
bit
of
that
question
again.
B
I
don't
think
there's
a
particularly
good
answer
for
that,
in
the
sense
that,
even
if
you're
going
to
process
storage
say
with
a
key
value,
store
or
you're
going
to
purchase
storage
with
with
an
object
store,
ultimately,
that
object
store
is
going
to
be
using
a
volume
or
a
file
system
at
some
point
in
the
back
end.
So
so
it
it
kind
of
depends
on
where
you
are
in
the
in
the
platform
owner
stack
right.
B
If,
if
you're,
if
you're
the,
if
you're
the
person
responsible
for
building
the
database
as
a
service,
you
probably
are
going
to
want
to
focus
on
the
volumes
and
if
you're
the
person
who's
wants
to
consume
the
database
as
a
service,
you
probably
only
care
about
the
database,
and
so
it
it
really.
You
know
that
that
that
answer
is
is
kind
of
conditionless
to
where
you
sit
in
the
in
the
in
the
stack
and
and
what
your.
What
your
focus
is.
A
Perfect
very
informative
and
good
answer.
Hopefully,
qr
courtier
got
what
they
wanted
out
of
there,
hopefully
pronouncing
a
very
difficult
name
correctly
here
again.
A
A
Maybe
while
we
see
if
anyone
else
has
anything
to
ask,
I
have
another
question,
I'm
always
interested
in
because
we
usually,
I
think
these
kind
of
discussions
focus
on
okay,
what's
happening
currently
in
the
cncf
landscape,
what's
happening
in
these
projects
and
everything.
So
where
do
you
see
the
future
of
all
of
these
projects
as
well
as
storage
and
kubernetes
going?
Where
do
you
think
it's
gonna
be
going
in
one
to
a
few
years?
From
this
point
onwards,.
B
B
So,
as
you
know,
I
kind
of
say
this
a
lot
and
it's
it's
it's
people,
people
in
in
in
my
team
kind
of
roll
their
eyes
every
time
I
say
this,
but
I
I
strongly
believe
cloud
is
not
a
place
in
the
sense
that
what
I
think
people
want
out
of
cloud
environments
is
the
the
on
off
consumption
model,
the
the
self-provisioning,
the
automated
deployments
and
automated
operations,
and
I
think
you
you're
you're
you're
able
to
get
that
now
through
a
number
of
different
services,
not
least
of
which,
of
course,
is
kubernetes
because
effectively.
B
You
know,
kubernetes
gives
you
that
that
composable
environment,
which
can
be
running
everywhere
from
your
laptop
to
big,
bare
metal
boxes
to
vms.
B
So
so
what
I
think
is
we'll
we'll
see
a
lot
more
focus
on
the
requirements
for
application-centric
storage,
we'll
see
a
lot
more
focus
on
data
mobility
and
the
ability
to
move
applications
between
different
environments.
So,
for
example,
a
very
common
pattern.
That's
that's!
B
Coming
up
nowadays
is
being
able
to
develop
on
prime
and
deploy
in
the
cloud
or
develop
in
the
cloud
and
deploy
on-prem,
for
example,
we'll
also
see
the
use
of
storage
becoming
key
in
diagnostics
and
and
and
other
debugging
purposes,
so
so,
for
example,
the
ability
to
have
copies
of
data
which
which
are
used
for
analytics
or
or
diagnostics
separate
to
the
production
environment.
B
So
so
you
know
the
concept
of
cloud
native
disaster
recovery
and
in
fact,
that
that
is
a
document
that
we're
working
on
that
that
we've
been
recently
working
on
in
the
sig
and
and
just
and
just
published,
which,
which
kind
of
covers
the
the
concept
of
having
you
know,
using
the
automation
and
using
the
composable
environments
to
to
actually
create
a
distributed
distributed
system
which,
which
would
cross
failure,
domains
and
and
be
able
to
automatically
survive
and
and
have
and
have
quick
recovery
processes
across
all
of
those
environments.
A
Yes
sounds
absolutely
lovely
looking
forward
to
the
future
as
well,
then
for
sure
and
then
there's
a
really
lovely
comment
from
from
hemanskata
saying
thanks
for
the
nice
presentation,
I
very
much
agree.
Thank
you
so
much
for
a
really
wonderful
information
packed
and
then
also
linux,
pizza
cats
says
hi
hi
back
to
you,
linux,
pizza
cats,.
A
A
big
portion
here
so
is
there
any
other
questions
from
their
audience
now?
Is
I
think,
one
of
your
last
moments
to
shoot
them
away
to
get
anything?
If
there
is
in
your
mind,
alex
do
you
have
any
final
comments?
Words
things
to
mention.
B
The
one
thing
I'll
say
is:
storage
is
kind
of
becoming
ubiquitous
in
in
kubernetes
and
the
whole
concept
of
you
know
not
having
stateful
workloads
or
not
or
or
feeling
afraid
of
stateful
workloads.
B
I
think
it's
something
that
that
should
just
go
away
for
good
the
once
once
you
see
the
benefits
of
the
automation
in
kubernetes,
you
obviously
want
to
have
that
automation
all
the
way
down
to
every
point
in
your
stack,
including
the
storage,
and
that
kind
of
enables
you
to
build
anything
as
a
service
and
to
move
stateful
workloads
from
traditional
environments
into
kubernetes
as
well.
I
think
the
other
key
thing
here
is
facts.
B
A
I
think
we're
having
some
technical
difficulties.
Oh
you're,
back
perfect.
B
B
I
I
was,
I
was
just
saying
just
just
finish
off
the
comment
before
we
finish,
that
developers
can
use
storage
like
a
superpower,
because
storage
can
enable
so
many
use
cases
whether
it's
you
know,
protecting
your
data
creating
highly
available
applications
providing
the
ability
to
have
data
mobility
and
things
like
that
which
which
which
effectively
they
now
have
the
ability
to
choose
on
their
own,
because
most
of
these
systems
are
are
software
defined
and
effectively
can
be,
can
be
deployed
everywhere.
So
I'll
just
end.
On
that
note,.
A
Perfect,
I
think
it's
a
really
wonderful
note
to
end
on
and
since
there
wasn't
any
immediate
new
questions,
let
me
just
wrap
things
up
for
today.
So
thank
you
so
much
everyone
for
joining
the
latest
episode
of
cloud
native
live.
It
was
really
great
to
have
alex
talking
about
communities,
persistent
data,
the
bridge
for
legacy
applications.
Thank
you
so
much
for
being
here,
yes,
and
we
also
really
love
the
interaction,
the
questions
from
the
audience.
Thank
you,
everyone
for
commenting,
attending
and
and
being
here.