►
From YouTube: Tutorial: Back to Basics: Hands-On Deployment of Stateful Workloads on Kubernetes - David Zhu
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Tutorial: Back to Basics: Hands-On Deployment of Stateful Workloads on Kubernetes - David Zhu, Google & Jan Šafránek, Red Hat
Ever wonder how to use a “volumeClaimTemplate”? Why you would choose a StatefulSet over a Deployment or vice versa? Complicated stateful applications are normally deployed via operators; however, it is critical to have a firm grasp on the Kubernetes primitives to understand, fine-tune, and debug your applications. In this tutorial you will learn about core Kubernetes storage and workloads concepts and how to use them to deploy stateful applications. You will get hands-on experience deploying both Cassandra and a test application on a Kubernetes cluster and learn how to debug some common errors in the process. You will develop mental models to understand the workings of StatefulSets along with how to compare them with other Kubernetes workload models such as Deployments and DaemonSets to determine the right workload for your purposes. Prerequisites: Laptop Basic UNIX command line experience
https://sched.co/MPgl
B
B
So
what
we're
going
to
be
doing
today
is
first
for
about
the
first
20
minutes,
we're
going
to
be
covering
some
basic
kubernetes
storage
concepts,
so
those
include
basic
workload,
concepts,
some
dynamic
provisioning,
debugging
techniques
and
how
to
use
cube
cuddle
and
then,
after
that,
we'll
have
a
hands-on
portion.
So
that's
about
20
minutes
in
where
you
can
login,
with
the
accounts
given
and
work
with
yon
to
actually
bring
up
a
cluster
and
bring
up
some
stateful
workloads
on
your
own,
all
right.
B
So
before
we
get
started
some
general
housekeeping,
we
have
some
TAS
that
have
positioned
themselves
around
the
room
who
have
graciously
volunteered
their
time
to
help
you.
So
if
you
have
any
issues
at
all,
say
your
Internet's
not
connecting
or
your
clusters
not
coming
up.
You
can't
find
a
certain
button.
Whatever
problem,
you
have,
please
raise
your
hand
and
look
for
one
of
these
TAS
to
help
you
ok,
so
they're
here,
for
your
help
feel
free
to
utilize
them,
however
necessary
I'm
gonna.
B
Please
ask
for
you
to
save
your
more
general
questions
for
the
end
of
the
talk,
so
we'll
leave
time
for
questions
at
the
end.
This
is
just
because
you
know
we
don't
want
to
slow
down.
We
don't
want
to
bog
down
the
hands-on
portion
or
the
concepts
for
for
questions
in
the
middle
and
one
loss.
One
final
thing
in
the
hands-on
portion
of
this
tutorial:
we
just
asked
for
you
to
not
work
ahead.
B
We'll
have
adequate
time
to
cover
all
of
the
material.
Yawn
will
be
going
at
a
fairly
comfortable
pace,
but
not
super
fast
and
so
yawn
we'll
also
be
covering
more
information
as
we
go
on.
So
if
you
work
too
far
ahead,
you
might
not
catch
like
the
conceptual
information
that
happens
as
we're
going
through
the
tour
all
right.
So
without
further
ado,
some
conceptual
information,
so
I
want
to
start
by
showing
you
a
basic
staple
workload.
B
So
in
this
example
here
our
sleepy
container
has
a
volume
mount,
and
this
is
called
data
and
that's
like
that's
the
volume
that
we're
mounting
into
our
containers
and
into
our
container.
So
here's
the
pot
that
we're
giving
it
and
you
can
see
that
we've
actually
defined
what
data
is
in
this
pod
specification
as
well,
and
we've
defined
it
to
be
a
reference
to
this
thing
called
a
persistent
volume
clamp.
So
you
might
be
wondering
what
is
that
persistent
volume
claim?
B
Well,
we
have
two
main
storage
objects
in
kubernetes,
one
of
which
is
a
persistent
volume
claim
and
one
of
which
is
a
persistent
volume.
So,
first
let
me
go
over
the
persistent
volume
claim.
So
this
is
a
user
object,
so
this
is
generally
created
by
a
user
along
with
their
workloads,
and
it
basically
represents
all
of
the
information
that
you
might
need
from
from
the
workload
like
the
request
for
storage
that
a
user
will
give.
B
So
in
our
example,
we
have,
as
a
user
I
just
want
a
disk,
any
disk
with
five
gigabytes
file,
system,
type
and
read/write
ones
right,
and
the
persistent
volume
which
is
kind
of
on
the
other
side
of
the
equation
is
the
storage
administrator
side
of
the
equation,
and
so
this
is
actually
a
reference
or
to
underlying
storage.
So
this
generally
has
some
more
information
associated
with
it.
B
In
our
example,
here
we
have
an
NFS
volume,
and
so
we
actually
have
the
IP
address
of
this,
and
if
the
underlying
disk
right-
and
so
we
can
find
the
volume
and
what
happens
actually
in
kubernetes-
is
that
these
objects
bind
together.
So
we
have
the
user
side,
the
one
that's
created
by
the
user,
the
precision
volume
claim
and
the
persistent
volume
and
they
bind
so
here's
a
quick
diagram
of
kind
of
how
it
works
in
the
system.
B
We
have
an
admin,
pre
provisioning,
persistent
volumes,
which
reference
persistent
disks,
okay
and
when
a
user
comes
in
and
runs
wants
to
run
their
workload,
they're
going
to
apply
their
workload
gamal
to
the
cluster,
so
that's
their
set
of
containers,
which
is
called
a
pod
and
that
references
of
PVC,
a
PVC
which
can
then
bind
to
the
most
appropriate
persistent
volume.
So
in
this
case
the
persistent
volume
claim
kind
of
finds
the
most
appropriate
persistent
volume
in
the
system
and
binds
to
it.
B
Alright,
so
that's
the
basic,
that's
the
basics,
and
then
we
have
dynamic
provisioning,
ok,
so
to
explain
dynamic
provisioning.
We
have
to
explain
one
more
API
object
and
this
is
the
storage
class,
and
what
this
is
is
a
representation
of
an
entire
class
of
storage.
So
in
our
example,
we
have
two
example:
storage
classes,
one
is
slow
and
one
is
fast
and
we
can
see
that
they
contain
some
parameters
for
each
saying
whether
we're
using
like
standard
hard
disk
drives
or
solid-state
drives
right.
B
So
we're
we're
kind
of
grouping,
persistent
volumes
and
what
we
can
use.
This
storage
clause
to
do
actually
is
here.
Here's
the
image
from
before
and
what
we
can
use
the
storage
cost
to
do
here
is
kind
of
like
the
admin
creates
the
storage
class,
but
now
no
longer
has
to
pre
provision
all
of
their
persistent
volumes.
B
So
what
happens
is
when
you
create
your
workload
and
your
Christmas
and
volume
claim
it's
going
to
reference
the
storage
class,
which
then
kubernetes
knows
how
to
use
the
storage
class
and
its
parameters
to
actually
provision
the
underlying
disk.
If
you're
on
a
cloud
and
generate
that
persistent
volume
object
that
references
that
disk
that
we
can
then
bind
with
okay.
So
what
are
some
of
the
benefits
of
dynamic
provisioning?
Well,
we
can
one
decrease
overhead
by
only
creating
the
disks
that
we
need
when
we
need
them
right.
So
that's
the
dynamic
part.
B
B
You
don't
have
that
kind
of
resilience
that
you
want
from
a
production
system,
so
we
have
some
higher-level
workload
concepts
in
kubernetes
that
can
help
you
give
you
some
higher-level
building
blocks
to
build
your
resilient
systems.
So
one
of
these
is
a
deployment,
and
what
this
does
is
it
just
runs
many
replicas
of
a
single
pod
template,
so
the
pod
that
we
have
before
it
just
runs
like
X,
many
of
them
right
when
a
plot
is
deleted.
It
replaces
it
you
can
scale
these
things
up
and
down
right.
You
don't
have
to
have
three
replicas.
B
You
can
have
five,
you
can
have
eight,
but
the
caveat
here
is
that
all
pods
share
the
same
PVC
okay.
So
if
we
look
at
this
image
here,
it
kind
of
shows
how
this
is
working.
So
all
the
pots
kind
of
reference,
one
PVC,
which
means
they
end
up
referencing
one
piece
of
storage-
and
this
is
a
pretty
big
caveat.
B
This
means
that
all
of
your
replicas
of
your
workload
are
actually
writing
and
reading
from
the
same
disk,
and
some
of
you
may
be
thinking
like
that's,
probably
not
what
I
want
right
so
a
lot
of
times.
What
happens
is
that
these
workloads
will
kind
of
stomp
on
each
other.
Some
of
them
will
refuse
to
start.
Some
of
them
will
crash
unless
you've
built
your
workload
specifically
to
all
read
and
write
from
the
same
data
volume.
This
is
probably
not
what
you
want.
So
for
a
little
bit,
more
storage
focused
higher
level
workload.
B
We
have
what's
called
a
stateful
set
and
that's
actually
very
similar
to
a
deployment
and
that
it
runs
many
replicas
of
your
pod.
But
the
difference
here
is
that
each
pod
gets
its
own
persistent
volume
claim,
and
this
is
generated
through
a
persistent
volume
claim.
Template.
Okay
and
Yan
will
actually
talk
about
this
a
little
bit
more
later.
So
we'll
see
an
example
of
that,
but
basically
what
that
gets.
You
is
that
each
pod
now
has
its
own
storage
back-end
right.
B
It
has
its
own
volume,
and
this
may
look
like
it
solves
all
your
problems,
but
actually
this
has
its
own
caveats
too,
in
that
the
pods
actually
generally
in
your
workload,
have
to
be
aware
of
each
other.
They
have
to
all
be
like
members
and
do
some
leader
election.
So
without
that
you
know
you
kind
of
your
replicas,
don't
really
know
how
to
interact
with
each
other.
Basically,
they
just
all
your
pods
need
to
have
some
method
of
being
aware
of
each
other
doing
some
active,
active
or
active
passive
membership.
B
Okay,
one
other
concept
that
we
need
to
cover
is
services,
okay,
and
so
what
this
is
is
basically
defining
a
logical
set
of
pots.
So,
generally,
a
service
is
related
to
our
higher-level
workloads,
in
that
it
kind
of
sits
in
front
of
it
and
what
it
does
is
defines
these
as
one
logical
set
and
gives
you
access
to
them.
B
So
we
have
a
couple
different
types
of
services,
the
standard,
one
kind
of
being
a
DNS
name
for
your
grouping
of
pods,
as
well
as
an
an
IP
address
for
your
for
your
grouping
of
pots
and
at
load
balances
between
them.
So
if
you
hit
this
IP
address
it
will
it
will
load
balance
between
your
pots
right
and
what
we
have
kind
of
a
weird
name,
but
the
load
balancer
service.
It
does
all
the
things
that
a
standard
service
does,
but
it
also
provides
you
with
an
external
IP.
B
So
this
allows
you
to
hit
that
kind
of
service
from
outside
of
your
cluster
as
well.
So
the
standard
service
is
for
inside
load
balancers
for
outside,
and
we
have
a
third
concept
called
a
headless
service
which
is
very
similar
to
a
standard
service,
but
it
doesn't
have
that
IP
and
DNS
name
at
the
top
level,
so
actually
we're
just
gonna
have
an
IP
and
DNS
for
each
pod.
B
B
But
so
here
are
some
useful
cube
control
commands
we
have,
and
these
are
the
ones
that
were
going
to
be
using
later
as
well.
We
have
apply
all
right,
this
just
kind
of
takes
your
yeah
mol
definition
and
puts
it
on
to
your
cluster.
We
have
delete
that.
Does
the
opposite
right!
It
removes
your
object
turn
your
cluster.
You
can
get
a
basic
list
of
API
objects,
you
can
describe
the
objects.
This
one
is
important.
B
Remember
describe
I,
think
a
lot
of
people
don't
know
about
it,
and
it
gives
you
much
more
information
that
helps
you
debug
your
cluster.
You
can
get
logs,
you
can
execute
commands
directly
on
your
containers
and,
of
course,
this
is
not
exhaustive.
We
have
a
link
here.
Slides
are
online.
You
can
go
and
find
all
the
rest
of
the
commands
as
well
in
your
own
time.
B
So
here
in
my
example,
when
I
do
a
cube,
control
and
get
pods
I
noticed
that
my
webserver
is
pending
and
it
notice
that
it's
pending
for
a
long
time
now.
This
is
something
that
we
don't
want.
So
what
I
do
is
I
use,
describe
and
I
describe
the
pots,
and
what
this
actually
gives
me
is
a
list
of
events,
so
I
can
see
that
the
pod
has
failed
to
schedule
because
it
has
an
unbound
PVC.
This
is
a
storage
object,
as
we
talked
about
earlier
right.
B
So
now
we
know
kind
of
where
the
culprit
is
so
we
go
in
and
we
describe
our
PVCs
on
the
cluster
to
find
out
more
all
right
and
when
we
do
that,
what
we
notice
is
that
provisioning
failed,
because
the
storage
class,
which
we
also
talked
about,
is
not
found
right.
So
this
kind
of
gets
to
the
root
of
the
issue
is
kind
of
a
contrived
example,
but
you
know
we
can't
find
the
storage
class.
So
what
do
we
do?
We
check
the
storage
clauses
on
the
cluster.
B
We
notice
that
there
is
none,
and
so
we
just
create
this
storage
class.
We
describe
it,
we
can
see
it.
Okay,
we've
put
the
we've,
put
this
storage
class
on
the
cluster.
Now
and
now,
when
we
actually
describe,
we
wait
like
a
couple
seconds
and
then
we
describe
our
webserver
and
we
note
that
you
know
it's
gotten
scheduled
and
it's
you
know
pulling
the
images,
it's
creating
things
and
it's
running
now.
B
So
what
actually
happened
is
we
don't
need
to
do
anything
else
besides
creating
that
storage
class,
because
kubernetes
is
self-healing
right
once
that
storage
class
exists,
the
PVC
and
its
loop
will
eventually
find
that
storage
class
and
heal
it
self
and
make
everything
work
and
like
connect
to
a
PV
like
it's
supposed
to,
and
then
the
pod
will
then
find
that
PVC
and
find
the
underlying
storage.
We
didn't
have
to
touch
anything
besides
resolving
the
underlying
error.
Okay,
so
that's
the
conceptual
part
done
and
now
yon
is
going
to
walk
you
through
the
hands-on
demo.
B
C
D
Well,
first,
we
need
an
opening
this
cluster-
everybody
of
you
got
tiny
piece
of
paper
with
looking
details,
so
go
to
this
webpage,
console
dot,
Cloud
Google
Chrome,
but
please
use
anonymous
windows.
Otherwise
it
will
conflict
with
your
use.
Your
own
Google
account,
if
so
anonymous
in
window
in
your
browser,
is
the
best
thing
to
do,
and
let's
actually,
what
I'm
going
to
do.
I
will
open
a
new
window,
though.
E
D
E
D
B
D
What
is
it?
It
doesn't
really
matter
which
a
B,
C
or
D
I
choose
I
choose
B.
It
doesn't
really
matter
just
because
Google
staff
confirmed
this
zone
has
the
right
amount
of
resources,
I
don't
need
to
configure
or
much.
We
will
get
free
notes,
let's
use
four
CPUs
with
15
gigabytes
of
memory.
That's
enough
Google
days
and
well,
that's
it!
Actually!
So
just
the
zone.
You
do
request
one
for
CPUs
and
create.
D
Now
it
takes
a
couple
of
minutes
to
create
the
cluster,
like
Google
machines
are
booting
up,
creating
a
cluster
joining
starting
logging,
starting
monitoring
everything
it
takes
a
couple
of
minutes.
So
let's
look
at
what
we
are
going
to
do
in
the
head
of
hands-on.
What's
the
goal
and
the
goal
is
to
run
a
very
simple
application
that
will
do
just
a
counter.
We
will
show
a
web
page
with
a
counter
every
you
remove
the
page,
the
counter
bumps
for
that.
D
For
that
we
will
start
Cassandra
database.
We
have
chosen
Cassandra
just
because
it's
really
easy
to
set
up
for
this
tutorial.
We
are
not
database
experts,
we
don't
endorse
Cassandra
and
in
any
way,
but
you
will
see
it
has
pretty
nice
features
and
it
works
pretty
well
infirmities.
So
that's
why
we
use
it.
It
behaves
the
way
we
want
it
to
behave
and
we
will.
The
rest
of
the
tutorial
will
be
on
this
github
page.
So
please
open
it.
D
D
D
D
D
D
The
Yama
file
for
the
stateful
set
is
pretty
long,
but
su
will
create
the
sickness
that
you
can
look
at
the
Yama
file.
It's
well
documented
and
it's
pretty
straightforward.
Here's
just
small
excerpt
we
will
ask
for
where
is
it?
We
will
ask
for
free
replicas
of
of
we
as
poor,
for
free
ports
in
the
safest
set
here
is
a
template
of
the
pot.
D
So
kubernetes
just
takes
this
template
and
copies
it
three
times
inside
the
template,
we're
on
Cassandra
image,
whatever
it
is,
and
we
mount
something
called
Cassandra
data
into
slash,
Cassandra
underscore
data
inside
the
pot
inside
the
container.
This
Cassandra
data
refers
to
a
persistent
volume,
claim
template,
so
each
pod
gets
its
own
persistent
volume
claim
it
will
be
named
Cassandra
this
data
and
we
just
ask
for
one
gigabyte
of
storage,
that's
readable
and
writable
by
single
port.
D
So
what
what
kubernetes
will
do?
We
will
create
the
fitful
set
with
a
template.
It
will
instantiate
the
templates.
We
will
get
three
ports
and
free
person,
volume
claims
now
dynamic,
provisioning
will
kick
in,
Google,
magic
will
happen
and
it
will
provision
free,
persistent
volumes
somewhere
deep
in
the
Google
Cloud,
and
we
will
have
persistent
volumes
in
our
permit.
Iskra,
the
persistent
volume
objects
in
our
kubernetes
cluster
and
each
of
them
get
bound.
D
It
gets
bound
to
our
claims,
after
that,
when
we
have
everything
set
up,
oops
kubernetes
will
start
the
pods
and
that's
where
kubernetes
talks.
It
starts
the
pots,
so
we
will
have
three
different
pots.
Each
of
them
will
have
each
own
Cassandra
daemon
with
its
own
volume,
but
if
you
write
something
to
the
one
to
one
of
the
pods
here,
if
you
write
something
here,
it
will
be
just
stored
here
and
if
we
want
to
read
the
value
from
the
different
pot,
it's
not
written
here.
D
So
that's
not
part
of
kubernetes,
but
part
of
the
configuration
of
the
state
was
said.
You
must
configure
the
application
to
join
somehow
to
form
a
cluster,
so
they
spread
the
data
and
I
don't
know:
do
some
redirection
or
act
effective
whatever
you
want,
but
this
is
not
part
of
kubernetes
kubernetes
will
not
do
that
for
you.
That's
your
job
in
Cassandra
case.
It's
super
simple.
D
D
What
this
I
never
had
it
I
never
saw
it
anyway.
We
start
cloud
show
what
happens
somewhere
in
Google
cloud.
New
VM
is
born
and
it's
starting
and
it
will
start
a
shell
Linux
command
line.
Shell,
don't
worry
and
it
will
connect
it
to
our
kubernetes
cluster.
That
is
this
tiny
icon
that
opens
it
in
a
new
window.
So.
B
D
D
D
B
B
E
E
B
So,
apologies
for
the
cloud
shell,
not
working
right
now.
What
Yan
is
doing
is
he
is
logging
into
the
G
cloud
SDK
on
his
on
his
machine
as
the
dev
account
that
we've
given
you.
So
if
you
have
the
G
cloud
SDK
installed,
you
can
follow
the
steps
that
he's
doing
right
now.
If
not,
please
just
wait
for
the
cloud
shell
to
provision.
It
will
finish
eventually.
E
B
D
E
E
D
D
D
D
It
creates
the
PVC.
It
plays
the
pot
and
the
white
until
it
started
completely
and
after
that
they
will
start
Cassandra.
One
wait
until
it's
completely
started
and
then
start
Cassandra.
You
can
configure
in
the
state
who
said
that
you
want
to
run
them
in
parallel,
but
then
it's
slightly
harder
to
build
the
cluster,
because
what
Cassandra
does
it
was
that
the
first
replicas
and
all
the
others
replica
will
connect
to
Cassandra
oh
and
join,
join,
join
it's
coaster,
while
it's
starting
you
can.
D
D
If
there
was
some
error,
we
would
see
some
error
in
these
events.
Everything
is
starting.
So
that's
good,
but
it's
starting
for
long.
So
we
what
we
can
do.
This
doesn't
work.
You
can
check
docks,
for
example,
class
and
we
get
locks
from
the
pot
or
if
we
used
a
chef,
it'll
follow
the
rocks.
Everything
is
already
started
so.
D
D
Let's
create
deployment
and
service.
If
I
look
at
the
pot,
we
have
now
one
extra
pot.
That's
the
application.
We
just
need
one
application,
that's
fine!
And
if
you
look
at
the
service
we
get
this
headless
service
named
Cassandra,
he
doesn't
expose
any
IP
address.
It
just
provides
the
DNS
names
for
our
Cassandra
ports
that
we
have
country
counter
as
a
service
service
of
type
of
balancer,
which
has
cluster
internal
IP
address
10
7
2,
4
138.
This
is
reachable
only
inside
the
comes
inside
the
cluster.
D
D
D
Worried
of
what
query
it
was
update,
some
counter,
how
many
items
it
go
and
how
long
it
was
each
bump
basically
means
we
need
to
update
the
counter
and
select
the
current
value,
and
you
can
see
the
IP
IP
addresses
of
the
database
servers
changing
with
each
reload.
They
are
free.
So
we
have
two
point.
Four
one
point,
four
and
open
eight
and
again,
two
point:
four
through
the
client
does
around
bobbin
between
the
database
servers
the
database
demons
and
that's
it.
D
D
What
we
do
we
execute
clip
control,
exec
that
exacts
a
command
inside
Cassandra,
OH
pot,
and
it
executes
note
to
status.
You
can
imagine
something
like
SSH
but
with
kubernetes
and
contain
runtime
instead
of
the
SSH.
So
we
executed
is
no
two
status,
which
is
which
gives
the
status
of
the
Cassandra
roster
and
Cassandra
knows
about
this
free
replicas.
All
of
them
are
up
and
running
and
everything
works,
and
we
can
and
application
explicitly
asked
to
store
three
replicas
of
each
counter.
So
here
we
can.
D
We
can
see
that
each
each
each
Cassandra
pod
owns
100%
of
the
data
and
what
we
are
going
to
do.
We
are
going
to
scale
up.
Our
country
is
super
popular
Cassandra.
Pods
are
super
busy
and
we
need
to
add
more
so,
let's
add
Ondra
what
you
cube-
controls
KO
this
replicas
for
and
what
are
we
scaling?
We
are
scaling
State,
vs,
/
Cassandra.
D
D
It's
still
using
free
replicas,
you
can
use
the
we
W
W
running
now.
We
should
have
four
IP
addresses
1.6
1.4
0.8,
2.4
yeah.
We
have
for
what
Cassandra
thinks
about
itself.
Is
this?
We
execute
the
note2
status
again
and
now
cassandra
thinks
it
has
4
replicas
and
each
of
them
owns
part
of
the
database.
So
a
cassandra
internally
did
some
reshuffling
of
the
data
and
spread
itself
across
more
nodes
and
that's
what
we
want
from
our
database
and
now
the
fun
part
they
are
going
to
kill
things,
for
example.
D
1.6
is
missing,
and
instead
of
that
we
have
2.5
5e
address,
so
ports
have
different
IP
addresses
whenever
they
start
was
important
for
for
us
that
the
DNS
record
is
still
the
same.
It's
still
Cassandra
1
dot
service
dot
whatever
so
it's
important
to
do.
Clients
use
the
I,
don't
use
the
IP
addresses
they
should
use
the
DNS
entries
because
they
are
stable,
IP
addresses
are
not
I,
didn't
show
it,
but
the
application
survived
and
it
should
arrive.
Also,
while
the
pod
was
down.
D
And
well,
that's
basically,
it
I
can
scale
down
back
to
free
replicas,
just
to
show
you
what
Cassandra
does.
But
it's
not
really.
This
is
not
really
important
for
the
tutorial
scale
back
to
free
replicas.
Well,
it
is
important
because
what
happens
kubernetes
always
close,
the
last
pot
in
the
state
was
set.
Oh,
it
killed
Cassandra
free.
D
D
D
So
that's.
Basically
the
tutorial.
The
things
to
remember
is
use
DNS
names,
not
IP
addresses
and
when
you
scale
up
or
down,
you
may
need
to
poke
the
application
to
tell
it
that
the
replica
with
very
few
replicas
or
the
replicas
that
just
died.
It's
never
coming
back
and
back
to
the
slides,
how'd
it
work
for
you.
Did
you
follow,
or
was
it
too
quick?
Any
problems.
D
E
D
D
It
came
down
with
some
manual
poking,
but
I
guess
you
can
find
use
cases,
but
it
won't
work,
but
Cassandra
will
not
behave
in
a
performance
or
perform
differently
than
you
would
expect,
because
all
the
databases
work
differently
in
different
conditions,
we'll
look
at
the
other
databases
and
state
facet
for
them
initially
before
that
it
would
show
MySQL
and
WordPress
yes
during
this
demo,
because
that's
what
everybody
knows
everybody
uses
everybody
knows
how
to
deploy
on
bare
metal.
Let's
try
main
component
is
and
very
quickly.
We
found
out
that.
D
D
D
It
forms
a
cluster
where
the
first
replica
is
readwrite,
but
all
the
others
were
all
read
only
but
WordPress
needs
all
the
connections
readwrite.
That
means
we
would
not
that
it
would
not
scale
basically
for
for
for
WordPress,
you
can
maybe
find
a
use
case,
but
it
would
care
for
you,
but
in
this
example,
it
will
create
a
read/write
metric,
just
the
master
and
all
the
others
are
just
slaves.
D
Maybe
you
can
find
also
a
difference.
It
was
set
for
my
school
I
didn't
find
them,
but
I
didn't
try
hard
enough.
I
confess
for
progress.
Postgres.
There
is
a
company
called
crunchy
data
which
provides
enterprise
support
for
Perth's
Postgres,
and
they
also
provide
a
nice
yama
files
how
to
run
for
space
instead
facets
they
look
nice,
but
we
give
interested
and
they
also
publish
an
operator
that
simplifies
the
deployment
and
actually
it
looks
solid.
Maybe
it's
what
you
want,
we
tried
mango,
you
can
find
couple
of
tetris,
for
it
looks
nice.
D
Instead
of
an
operator,
it
uses
a
sidecar
that
does
the
think
and
all
the
scaling
up,
scaring
down
logic,
I
found
just
one
glitch,
and
that
was
if
you
connect
to
you,
need
to
provide
a
connection
string
question
you
rate,
and
in
this
connection,
you're
a
URI.
You
must
specify
all
the
replicas
of
that's
fine
in
our
staff
asset.
We
have
stable
database
name,
DNS
names,
that's
fine,
but
what,
if
I
skill
up
the
application?
I
should
I
must
add
this
new
port
to
this
URI
I.
D
Believe
you
can
do
it.
It's
not
hard,
but
that's
something
you
need
to
think
about
and
they're
a
bunch
of
cloud
native
databases
like
I
just
pick
few
representatives,
but
there
are
many
more
and
you
can
find
them
here
in
compute
con.
So
you
can
go,
go
to
the
booth
area
and
ask
them
what
they
are.
What
the
features
are,
what
prom
problems
they
solve,
what
problems
they
don't
solve,
because
I
believe
there
is
no
write
database
like
you.
Should
you.
D
D
D
It
just
creates
the
objects
and
doesn't
care
about
them
too
much
and
the
other
approach
that's
being
more
popular
now
is
operator
operator
is
just
an
application
that
can
run
in
or
Craster's,
and
it
will
create
the
application
for
you
like
Cassandra
or
PostgreSQL,
and
it
will
also
monitor
it.
So
if
something
breaks
it
can
automatically
fix
it
again.
It
depends
on
the
operator.
D
Some
of
them
are
very
simple
and
don't
do
much,
but
some
of
them
can
be
pretty
smart
and
fix
a
lot
of
things
for
you
and
before
you
start
deploying
your
application
and
your
databases.
You
must
also
think
there
are
some
differences
to
the
bare
metal
work
that
you
are
maybe
used
to,
for
example,
updates
happen
completely
differently
in
kubernetes
than
in
the
burn
metal
and
when
Archie,
when
you
are
choosing
the
database
or
the
application,
you
must
think
how
I'm
going
to
apply,
update
citrucel
supports
rolling
update.
That
means
it
will.
D
It
will
go
from
the
last
replica
Cassandra,
for
example,
it
will
kill.
It
start
a
new
one
with
the
new
version,
then
it
will
go
to
Cassandra
one
kill
it
and
start
the
new
version
of
it
and
Cassandra
Oh
kill
it
and
stop
the
new
version
of
it.
That
looks
fine.
If
your
database
can
support
multiple
versions
of
itself
in
the
same
posture,
maybe
they
should
do
like,
because
that's
the
only
way
I
have
to
update
the
posture,
but
be
very
careful.
D
Another
thing
you
should
thought
you
should
think
about
before
deploying
something
stateful
is
the
networking
as
I
showed
you
IP
addresses,
are
completely
random.
They
change
only
the
DNS
names
are
stable,
so
should
the
client
resolve
a
DNS
name
before
every
connection
before
every
database
query
or
in
the
case
of
Cassandra
I,
found
out
that
it
automatically
changed.
It
automatically
discovers
IP
addresses
of
other
members
of
the
cluster
from
the
old
members.
So
if
I
pay
IP
address
changed,
the
client
occurs
that
automatically
without
any
configuration.
D
Without
anything,
that's
fine,
but
can
your
client
do
that
and
other
network
related
topic?
Is
the
network
partition?
If
you
have
two
data,
centers
connected
with
cable
cable
is
broken.
You
have
parts
of
your
database
on
different
networks.
They
can't
talk
to
each
other.
So
what
should
happen?
And
what
do
you
want
to
happen
in
your
application?
Actually.
E
D
This
can
behave
very
differently
than
in
bare
metal.
The
cutters
are
usually
easy.
You
can
find
some
way
how
to
dump
your
database.
It's
not
that
different
from
bare
metal.
But
how
do
you
restore
the
backup
because
kubernetes
it
will
create
a
persistent
volume
claims
for
you.
It
will
bind
them
to
empty
volumes.
D
D
You
should
practice
that
and
test
it,
that
your
approach
really
works
and
well
they
told
you
that
kubernetes
are
just
ephemeral,
they
come
and
go.
They
are
often
killed
when
a
node
goes
down
or
some
more
important
pod
comes
up.
So
what
your
database,
thus,
when
opposed
dies-
and
we
didn't
do
any
special
configuration,
so
in
our
case
in
Cassandra
it
could
happen
that
all
the
ports
could
be.
D
On
the
same
note,
so
if
the
note
goes
down
over
the
post
from
from
Cassandra
will
go
down
and
your
database
is
down,
so
you
should
probably
make
sure
that
they
spread
evenly
across
the
cluster.
Kubernetes
has
a
concept
for
that
called
anti
affinity,
and
it
can
also
help
you
to
spread
the
path
of
Cassandra
across
different
data,
centers
or
different
availability
zones.
So
we
should
plan
ahead
and
well.
I
hope
is
the
last
one.
It's
security.
D
Currently,
the
our
Cassandra
ports
were
not
secure
at
all.
You
can
connect
to
it
just
knowing
its
IP
address.
They
will
not
know
username
password,
you
can
add
usernames
passwords
certificates
or
whatever
easily
it's
not
the
different
from
Bell
Metro.
But
what
may
be
different
is
that
the
ports
are
running
on
random
nodes
in
the
cluster
and
you
don't
know
what
else
runs
on
the
node
and,
for
example,
in
our
example.
In
our
case,
we
have
this
web
application.
D
If
somebody
hacks
the
web
application
and
they
can
get
inside
the
container
and
if
they
find
some
security
issue
and
security
fees
happen,
they
can
probably
escape
the
container
and
get
to
other
processes
on
the
machine,
and
maybe
they
can
get
to
my
database
with
credit
card
numbers.
Instead.
Is
this
what
I'm
going
to
risk
or
should
I
do
something
better?
For
example,
I
can
dedicate
some
nodes
just
for
the
database,
so
all
that
you
should
consider
before
deploying
anything
stateful
in
kubernetes,
because
it
may
behave
completely
differently
than
environmental
case
I.
D
B
Just
thank
you
for
for
coming
to
our
state
for
sartorial
I.
Just
wanted
to
add
that
those
accounts
that
we
gave
you
I,
think
are
active
for
24
hours.
So
if
you
missed
any
part
of
it
or
you
want
to
try
out
some
of
the
extra
steps
that
that
we
did
not
cover,
if
you
go
to
that
github
repository,
there
are
some
extra
steps
you
can
try
them
all
out.
B
You
can
do
that
for
the
next
day
or
so,
besides
that,
where
we'll
be
here
for
questions,
if
you
have
any,
but
the
main
portion
of
the
talk
is
done
and
we
are
part
of
six
storage
in
kubernetes,
we
work
on
all
of
the
storage
related
things.
We
have
a
mailing
list
that
you
can
email
bi-weekly
meetings.
You
can
join
us
on
our
slack
if
you're
interested
in
contributing-
and
here
is
the
contact
information
for
me,
David
and
Yann
as
well.
Are
there
any
questions
in
the
audience.
F
D
D
On
the
same
note,
we
have
also
affinity
I,
never
used
that,
and
that
says
I
want
always
to
run
on
a
note
when,
where
this
pot
runs,
I,
maybe
I
have
I
can
have
a
driver
port,
your
driver
and
something
that
uses
the
driver,
so
they
want
to
run.
On
the
same
note,
maybe
that's
the
use
case,
but
I
never
use
that.
Actually
right.
B
D
D
If
the
client
secession
esta
native,
is
the
client
what
we
told
you
that
all
the
sell,
the
service
object,
it
does
load
balancing
that's
great,
but
it
also
does
load
balancing
based
on
HTTP
cookies.
So
if
I
have
two
ports
in
the
web
front
end
and
then
kubernetes
will
route
my
browser
just
to
one
of
the
port's,
because
it's
based
on
HTTP
cookies.
B
D
D
Still
have
four
participant
claims:
what
kubernetes
does
it
deletes
the
pots,
but
it
does
not
delete
the
claims
good.
It
was
a
good
question
actually,
because
state
Fassett
are
precious
and
storage
are
precious
even
more.
What
are
easy,
you
can
delete
them
start
the
new
ones
that
they
are
stateless.
Basically,
kubernetes
will
never
delete
the
state.
It
will
never
delete
the
percent
volume
claim.
B
The
question
was:
I
think
what
what
happens
to
the
storage
when
the
node
goes
down
and
I
think
this
I
mean
it
depends
on
what
direction
you
look
at
it
from
the
storage
itself.
If
it's
like
network-attached
storage
and
your
node
goes
down,
your
storage
is
still
available
somewhere
else
right
or
it's
still
available
externally.
So,
if
you
configure
your
cluster
correctly
and
you
bring
up
your
plot,
your
workload
that
uses
that
storage
somewhere
else
you're
actually
able
to
then
attach
to
that
network
storage
again
and
just
continue
using
it.
Does
that
answer
your
question.
D
This
in
our
example
on
Google,
the
storage
is
somewhere
in
the
cloud
is
not
on
the
note.
So
what
Google
does
is
just
attaches
the
storage
to
different
note
and
starts
a
put
there.
That's
easy
in
kubernetes
we
also
have
local
storage,
which,
where
you
can
use
nodes
that
are
attached
that
are
physically
on
the
main
on
the
nodes.
But
then,
if
the
node
goes
down,
your
storage
goes
down
too.
D
B
This
brings
up
a
really
good
point
that
choosing
your
storage
back-end
is
really
important
right,
like
if
four
different
resiliency
needs,
you
can
choose
different
backends
right.
If
you
use
a
local
if
you
use
local
disk
on
a
node,
if
that
node
goes
down,
you
lose
access
to
all
of
that
data
right.
But
if
you're,
using
something
like
attached,
network
attached,
storage
or
even
replicated
network
attached,
storage,
you're
gonna
have
better
resiliency
guarantees
on
that.
H
Hi,
my
question
is:
if
you
have
situation
where
you
have
like
database,
my
master
and
slave,
and
you
have
persistent
storage
and
you
do.
You
need
to
use
two
storage
classes
for
that
or
you
can
use
one
storage
place
because
you
want
to
ensure
that
master
ovale
gets
the
same.
Persistent
volume
and
the
slave
always
gets
another
one.
So.
D
B
Picture
I
think
from
what
I
understand
you
want
a
storage
like
you're
asking
if
you
should
have
a
storage
class
for
all
of
the
storage
for
your
slave
workloads
and
a
different
one
for
your
master
workloads.
Is
that
your
question?
So
this
do
the
way
you
choose
how
many
storage
classes
you
need.
It
actually
depends
on
the
needs
of
how
you
group
your
storage
right
if
the
Masters
and
the
slaves
use
the
same
type
of
storage
I'm,
assuming
each
one
has
its
own
volume
right,
each
replica
of
your
masters
and
slaves.
B
So
if
they
need
the
same
type
of
volume,
they
could
use
the
same
storage
class
so
say
they
all
need
SSDs
from
from
GCE
or
something
you
would
have
one
storage
class
for
that,
and
you
would
your
masters
and
your
slaves
would
all
use
that
one
storage
clause,
if
you
want
SSDs
for
your
masters,
but
some
other
type,
maybe
like
NFS
or
you-
want
hard-disk
for
your
slaves.
Then
that's
when
you
would
have
two
different
storage
class
right
storage
class
is
a
concept
that
binds
a
class
of
persistent
volumes.
A
class
of
storage
together.
H
H
B
If
I
can
just
refract
right,
ooh
rephrase
again
I
think
are
you
asking
if,
when
your
workloads
go
down
and
they
come
back
up,
you
want
them
to
use
the
same
underlying
storage
that
they
were
before
that
they
were
using
before
right.
So
so
that's
definitely
possible
with
a
stateful
set.
They
all
have
stable
naming
of
the
workloads,
and
so
when
they
come
back
up,
I
think
they'll.
Just
pick
they'll
just
pick
up
the
same
storage
again
from
where
they
left
off.
Yes
with
a
state
full
set.
F
B
This
is
a
great
question:
we're
actually
currently
working
on
resize
functionality,
so
in
kubernetes
I
believe
in
kubernetes
1.13
we
have
resize
as
offline
resizes
beta.
So
this
is
a
thing
that
you
can
do
right
now,
your
of
course
your
storage
back-end,
has
to
support
it
as
well,
but
I
believe
the
way
you
interact
with
it
is
just
by
changing
the
size
on
your
PV
or
PVC.
I
B
And
another
plug
is
we're
actually
working
on
online
resize
as
well,
so
offline
resizes.
While
your
workload
is
using
the
PV,
you
can't
resize,
it
you'll
have
to
bring
your
workload
down
first,
but
currently
in
kubernetes
we're
working
on
online
resize
as
well.
So
if
your
storage
back-end
supports
it
and
your
file
system
supports
it,
you'll
be
able
to
resize
your
volumes
on
the
fly.
D
B
B
D
J
So
don't
use
house
path
for
your
production
applications
for
exactly
the
reason
that
you
mentioned,
because
you're
gonna
have
to
take
care
of
actually
scheduling.
The
pods
kubernetes
doesn't
know
that
you're
it's
gonna
have
to
stay
sticky
to
that
note
that
it
first
gets
scheduled
to
so
that
becomes
complicated.
What
you
should
use
instead
are
persistent
local
volumes
and
persistent
local
volumes.
J
I
B
The
question
is:
if
I
want
to
update
my
database
schema
or
something
to
do
with
my
application.
I
guess
does
kubernetes
offer
any
primitives
to
help
with
this
update,
so,
okay,
so
yeah,
we
don't
so
kubernetes
schedules
the
workloads
on
two
nodes.
We
don't
like
kubernetes
core,
doesn't
really
have
anything
that
will
deal
with
your
application
directly,
but
we
do
have
primitives
that
can
stop
your
pods
right.
B
D
K
Not
on
I'm,
not
hundred
percent
sure
if
this
was
already
covered,
but
my
question
is:
if
I
have
some
sort
of
a
database
say
PostgreSQL
or
something
and
I
need
to
have
this
running
as
a
database
cluster?
Are
there
are
solutions
available
to
get
this
up
and
running
within
our
native
system
so
that
I
do
not
have
to
create
my
database
cluster
outside
of
my
community's
world.
B
B
There
are
other
solutions
right
like
this
is
not
you
won't,
have
a
kubernetes
primitive
like
there's,
not
gonna,
be
any
kubernetes
command
that
you
can
call
this
as
bring
up
my
Postgres
cluster,
but
of
course,
there's
a
very
rich
ecosystem
of
solutions
that
people
have
built
on
top
of
kubernetes
that
you
can
leverage.
So
we
don't
have
any
specific
recommendations
or
suggestions
for
you.
Unfortunately,.