►
Description
Don’t Hassle Me, I’m Stateful - Jeff Bornemann & Michael Surbey, Red Hat
Stateless, cloud-ready applications are the future for many enterprise users, but what do you do about legacy monoliths, and existing vendor applications? New StatefulSet features within Kubernetes allow developers and administrators to work with these types of applications, and still reap the many rewards of a containerized platform. This session will explore some of these features by deploying a full MongoDB cluster on-top of OpenShift.
About Jeff Bornemann
Jeff has been developing software for Fortune 500 companies for many years, including contributions to multiple OSS projects. Jeff works with Red Hat's OpenShift platform, helping to bring container adoption to Red Hat customers.
About Michael Surbey
With a background in development, design, and management of enterprise IT-driven solutions, Mike enjoys helping U.S. public sector customers, contributors, and partners create better a citizen experience the open source way.
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
A
Let's
talk
a
little
bit
about
some
things:
I
I,
really
I
like
that,
have
come
out
in
the
latest
version
of
kubernetes.
So
talk
about
that
at
the
end,
just
a
little
bit
of
ground
rules,
I
mean
we
we're
a
little
informal
here.
So
there
will
be
some
questions
at
the
end,
but
if
anybody
has
anything
pressing,
please
raise
your
hand
and
we'll
get
to
you.
If
this
devolves
into
some
sort
of
discussion,
that's
all
right
with
us.
Hopefully
that's
all
right
with
you.
A
B
A
A
few
just
a
few
of
nice
features
essentially
all
around
this
is
centered
around
pods
having
greater
sense
of
identity.
So
how
we
usually
think
about
pods
in
terms
of
deployments
is
that
they're,
these
stateless,
the
stateless
workloads
they
can
be
killed
when
they're
not
needed
scaled
up
when
they
are
and
so
on
and
so
forth.
So
thinking
about
pods
in
terms
of
identity,
what
do
we
have?
Well
now
we
have
stable,
replicas
storage.
So
when
staple
sets
scale
up,
we
can
have
stable
storage
that
also
scales
with
those
replicas.
A
It's
each
replica
also
has
its
own
network
identity
now.
So,
instead
of
just
happy
and
limited
to
pods
being
load
balanced,
you
know
the
service.
We
have
pods
with
their
own
addressable
space,
and
then
we
have
some
sense
of
ordered
start
up
for
staple
sense
and
that's
since
to
mesh
really
well
with
the
kinds
of
applications
that
are
most
applicable
to
staple
sets.
A
Mike
and
I
both
work,
a
lot
with
Red
Hat
customers
and
their
journey
through
containers
and
one
of
the
things
that
we
see
that
is
most
applicable
of
staple
sets
or
vendor
applications.
So
there
is
sort
of
a
timeline
of
or
a
progression
or
evolution
of,
containers
and-
and
one
thing
that
we
see
is
that
vendors.
Do
you
see
the
the
value
and
containers
and
they
do
see
the
the
value
and
potato
orchestration,
but
there's
some
missing
pieces
between
that
and
the
the
support
for
the
underlying
platform
the
containers
run
on.
A
We
also,
you
know
some
other
things:
people
a
little
bit
more
specific
storage
with
scale.
That's
what
I
mean
by
this
applications
that
scale
they
tend
to
need
their
own
storage.
Would
that
be
in
indices
or
some
sort
of
runtime
state
information,
and
then
chatty
clusters
so
clusters
and
they
scale
they
like
to
talk
to
one
another
gathered
together
like
graph
information
and
then
order
cluster
entry.
So
entries
into
the
cluster
like
to
have
some
notion
of
the
the
replicas
before
them
being
ready
and
started.
B
A
B
To
your
points,
also,
everything
that
comes
with
kubernetes,
like
velocity,
so
the
time
to
develop
a
product
or
a
vendor
product
and
get
it
out
the
door
is
definitely
something
that
comes
into
mind
as
well
as
scalability
from
not
only
the
software
perspective,
but
also
team's
perspective
and
then
yeah.
Just
overall
efficiency
and
automation,
right,
yeah,.
A
Certainly
so,
like
an
example
I'm
a
concrete
example
here
Cassandra.
So
if
you
think
about
Cassandra
Cassandra
cluster,
we
have
nodes
in
a
graph
and
they
use
this
protocol
a
gossip
protocol
to
share
information
between
the
nodes
in
the
graph
and
the
edges
in
the
graph.
So
thinking
about
how
do
we
scale
Cassandra
and
this
method
staple
sets
at
some
value
here.
A
A
Every
node
in
the
cluster
has
to
be
started
ready
before
a
new
node
is
added.
Every
node
also
needs
to
at
its
own
stable
storage.
So
it's
it
stores,
index
information,
Lucene
index
information
per
node,
there's
also
some
shared
storage
for
for
a
configuration
that
you
see
exposed
to
a
PVC
or
at
the
like,
and
then,
of
course
they
need
replications.
So
they
each
need
some
notion
of
a
network
address
and
being
able
to
communicate
with
one
another,
and
that's
really.
A
The
question
is:
how
do
we
take
these
patterns
and
scale
them,
because
it's
not
really
an
issue
of
putting
them
on
keeper
Nettie's,
as
we
can
certainly
do
that
we
could
manually
create
services
that
expose
the
the
replicas
and
all
that
but
and
it
may
be
overstated
through
home.
But
you
know
kubernetes
or
excuse
me.
Staple
sets
really
add
an
easy
way
for
this
to
happen
in
an
automated
fashion.
B
A
D
B
D
World
you're
bringing
up
data
from
sensors
and
you've
got
collectors
coming
up,
and
one
of
the
things
that
your
make
you
running
is
something
that
is
monitoring
the
descents
or
health
information,
and
you
want
to
generate
an
alarm
state.
Well,
those
alarms
are
stateful
when
I,
send
it
out
to
whatever
system
is,
is
coming
out
to
warn
somebody
that
something's
bad
I
have
to
know
that
they've
received
it
I
have
to
if
they
don't
receive
it
after
we
send
it
to
them
at
some
point.
D
A
Thank
you.
Anybody
else
have
any
examples.
They
know
we'll
get
back
to
it.
The
questions.
If
anybody
else
has
any
ideas
you
know
again,
this
is
the
forum's
our
example
is
gonna
be
so
this
is
actually
help
Mike
and
I
met.
We
did
some
some
work
with
the
image
here
at
Red
Hat,
to
make
it
a
little
bit
more
capable
in
terms
of
charting
and
and
scaling
with
with
openshift.
So
just
a
quick
debrief.
You,
of
course,
don't
need
to
be
a
expert
to
attend
this.
A
So
this
is
just
the
high
level
of
what
we'll
see.
So
we
have
clients,
and
then
we
have
a
S
component,
and
this
is
the
the
shard
server
of.
If
you
think
about
the
shards
here,
you
can
think
of
them
as
as
buckets
where
data
comes
in
and
then
it's
hashed
and
it's
determined
which
shard
that
data
should
fall
in
and
then
there
can
some
config
servers
over
on
the
right.
A
C
A
A
Yeah
we
have
a,
we
have
a
short
super
here.
This
is
a.
This
is
nothing
special.
This
is
a
this
is
deployed
through
a
plain
Jane
deployment,
it's
a
stateless
component
and
then
we
have
config
server,
which
is
also
exposed.
It's
basically
just
a
wrapped
replica
set.
This
is
exposed
as
a
staple
set,
and
then
we
have
one
shard.
So
this
isn't
currently
very
useful,
but
we'll
go
through
some
of
the
features
and
see
how
they
may
interact.
The
neat.
A
A
A
A
E
B
B
A
A
C
A
A
A
A
B
Essentially,
what
we
did
is
we
took
advantage
of
what
staple
sets
it
does
and
that's
from
the
kubernetes
perspective.
We
just
define
and
we're
gonna
deploy
the
staple
said
and
how
many,
how
many
pods
of
the
image
that
we
were
going
to
deploy
and
that's
listed
in
the
blue
or
blue
box,
and
so
those
got
instantiated
with
unique,
unique
quarterly
numbers
so
base
on
the
namespace
and
then,
in
addition
to
that,
we
created
a
headless
service.
B
A
Right
so
in
this
case,
we
don't
need
to
be
in
load
balance.
We're
gonna
use
just
a
headless
service
as
a
base
entry.
So
it's
kind
of
color
coded
like
if
this
might
be
an
interesting
graph
to
look
at
later.
So
blue,
the
blue
part
comes
from
the
headless
service
and
then
the
orange
piece
is
generated
from
the
staple
set,
its
name
definition.
Then
three
is
the
ordinal
index
from
from
Cooper
Nettie's
and
then.
B
A
A
So,
let's
we
can
talk
a
little
bit
about
that,
so
it's
zero
to
n.
So
one
of
the
the
guarantees
we
have
is
that
if
a
pod
comes
up
n
plus
one
isn't
has
a
guarantee
that
potting
has
been
started
and
is
ready.
So
this
is
basically
that's
us
treat
potentially
treat
lower
end
s
and
discipline
disease,
as
you
know,
master's
or
various
other
applicable
things.
A
A
And
now
just
some
some
other
things
that
aren't
that
aren't
that
aren't
represented
an
open
shift
but
I
think
is
really
cool
in
kubernetes.
Is
we
have
this
idea
of
an
update
strategy?
So
currently
the
update
strategy
is
default
undelete.
So
if
you
delete
a
staple
set,
pods
are
retained,
but
with
a
Google
1:7
which
isn't
rolled
in
yet
with
the
open
shift
that
I'm,
showing
they
have
a
rolling
update
concept.
So
you
can
actually
have
the
the
pods
shut
down
in
the
opposite
direction,
so
into
one
will
shut
down
in
a
readiness
fashion.
A
In
addition,
you
have
partitions.
So
in
the
instance
where
you
know
index
zero
is
say
for
WebLogic,
you
have
an
admin
server
or
something
you
could
have
that
associated
with
index
0
and
then
partition
off
one
to
end
to
the
applicable
to
your
update,
so
that
you
don't
touch
your
admin
server.
But
when
you
roll
out,
you
have
1
to
N,
update
and
then
pod
management.
A
So
this
is
this
really
allows
you
to
forego
the
the
readiness
entirely
in
my
opinion.
So
currently
it's
it's
no
ordered
and
ready.
So
we
have
that
one
to
end
relationship
of
you
know
waiting
for
the
readiness
probe
to
succeed.
But
if
you
just
want
to
use
staple
sets
say
for
swords,
provisioning
capacity,
then
you
know
you
can
utilize
parallel.
So
just
forget
that
entirely
so
those
are
some
of
the
cool
things
that
we
see
and
I'm
really
excited
to
see
how
it
how
it
develops
in
the
future.
So.
G
G
This
particular
instance
like
when
you're
running,
like
crap
love
legacy
software
inside
something
at
some
point.
You're
someone's,
like
I,
just
need
you
to
bounce
this
thing,
and
this
one
note
is
having
a
problem
we'd
like
we
played
around
with
this
with
like
labels
and
affinity,
and
it
was
just
like
you
know,
you
could
trick
it
into
doing
that,
but
like
having
a
way
that
say
like
you
know
what
index
zero,
just
stop
it
and
let
it
restart
yeah.
B
B
A
A
H
C
H
A
E
All
the
way
in
the
back,
could
you
tell
me
what
the
problems
might
be
if
you
try
to
deploy
a
stateful
application
on
MongoDB
or
db2,
but
not
using
staples
set,
which
is
something
we're
doing
right
now
we
have
the
MQ
series.
Db2
we
use
deployment
which
I
see
was
first
ended
again,
I'm
someone
who's
a
cooper
Nettie's,
which
is
stateless
right
and
it
seems
to
be
working
fine,
but
I
heard
you
know
for
stateful
applications,
you
better
use,
stateful
objects.
B
So
I
can
answer
that.
Essentially
you
get
a
lot
of
refactoring
of
the
staple
application
or
staple
workload
that
you're
working
with
in
order
to
suit
to
suit
kubernetes
replica
sets.
So
this
was
driven
by
demand
from
the
community
to
be
able
to
basically
provide
you
an
easier
migration
path
to
take
advantage
of
microservices
architecture
associated
with
one
one
of
a
stateful
application.
So
basically
this
gets
you
to
get
on
to
kubernetes
to
begin
with,
and
then
just
have
a
more
faced
or
methodical
approach
to
decoupling
those
tightly
integrated
services.
So
yeah.
A
Just
to
add
to
that
a
little
bit
and
like
when
I'm
when
Mike
and
I
were
originally
working
on
this,
you
know
one
of
the
biggest
things
was
provisioning
of
storage.
So
previously
we
had
customers
where
no
kidding.
It
would
be
weeks
to
months
of
a
wait
time
on
storage
team
work
for
storage
or
even
really,
for
you
know
what
that
would
seem
for
for
compute
to
add
a
new
replica
set
with
this.
You
know
deploying
those
types
of
applications
and
having
a
click
and
then
having
a
new
replica
set
is
huge.
B
J
J
I
would
just
add
to
that
that
you
know
there's
a
number
of
applications
that
don't
change
their
DNS
name.
Well,
you
know
they'll
go
through
and
create
new
uu
IDs
or
show
up
as
new
cluster
members
or,
if
you're
going
through
and
trying
to
configure
and
say,
hey,
you
know
we
want
these
notes
to
come
up
and
find
each
other.
You
know
dynamic,
DNS
portion
that
comes
up
with
running
a
deployment,
we're
gonna
get.
J
A
Well,
you
can
even
dive
into
details,
but
if
you
want
to
just
get
going
going
and
running,
it's
really
just
a
matter
of
creating
maximal
service
and
that
health
service
is
used
to
create
those
DNS
entries
per
replicas
and
that's
done
automatically.
So
there's
really
no
getting
your
hands
into
the
details
as
far
as
that's
concerned.
A
But
if
you're
talking
about
you
know
more
of
a
managing
how
the
pods
are
scheduled
so
that
there's
like
low
byte
latency
links,
then
that's
not
really
a
detail
that
you
work
with
specifically
with
staple
sets,
that's
more
something
that
you
consider
with
labels
and
your
scheduling
policies.
So,
but
it's
definitely
something
to
consider.
A
H
A
A
A
It
would
be
like
scaled-down,
so
if
you
have
like
one
two
replicas
three,
then
three
would
get
fully
shut
down
deleted.
Two
would
get
fully
shut
down
its
lead,
one
would
get
fully
shut
down
and
deleted
zero
cetera,
and
then
it
would
get
recreated
from
the
bottom
top
again
to
top
again
zero
one.
Two
three
does
that
make
sense,
and
all
those
Network
identifiers
are
sticky
so
as
they
come
back
up
the
rebound
to
that
same
address.