►
From YouTube: Intro to Rook: Storage for Kubernetes - Jared Watts, Upbound & Alexander Trost, Cloudical
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Intro to Rook: Storage for Kubernetes - Jared Watts, Upbound & Alexander Trost, Cloudical
In this talk, the Rook project will be introduced to attendees of all levels and experience. Rook is an open source cloud-native storage orchestrator for Kubernetes, providing the platform, framework, and support for a diverse set of storage solutions to natively integrate with cloud-native environments. Rook turns storage software into self-managing, self-scaling, and self-healing storage services. It does this by automating deployment, bootstrapping, configuration, provisioning, scaling, upgrading, migration, disaster recovery, monitoring, and resource management. The benefits and use cases of Rook will be explored along with an overview of each of the Rook storage providers: Ceph, EdgeFS, YugabyteDB, Cassandra, NFS, and CockroachDB. Rook was accepted as the first storage project hosted by the Cloud Native Computing Foundation in January 2018.
https://sched.co/Zex7
A
This
is
going
to
be
the
introduction
session
to
the
rook
project,
and
I
have
here
with
me
my
colleague,
alexander
trost,
who
is
currently
a
devops
engineer
at
claudical,
and
I
am
jared
watts,
I'm
a
founding
engineer
at
upbound
and
both
of
us
are
maintainers
on
the
brook
project.
We
got
a
couple
links
in
the
bottom
left,
so
if
you
can
help
you
find
the
rook
project
if
you
haven't
been
to
it
before
so,
let's
go
ahead
and
move
on
to
the
agenda
for
today.
B
B
What
does
it
even
solve
we're
going
to
look
a
bit
into
the
architecture,
as
it's
very
vital
to
understand
like
what
is
even
going
on
under
the
hood
there
we're
going
to
give
a
short
demonstration
as
well,
and
we
are
going
to
give
you
information
on
how
you
can
get
involved
like
even
like
you
know,
slack
and
such
things,
and
if
you
want
to
learn
more
already,
we
have
a
deep
dive.
Rook
session
coming
up
on
thursday
be
sure
to
check
it
out.
If
you
want
to
learn
even
more
about
rogue.
A
Okay,
let's
start
talking
about
some
of
the
challenges
that
we
typically
see
with
storage
in
kubernetes,
so
normally,
especially
through
the
early
days
of
kubernetes.
It
was
very
typical
to
rely
on
storage
that
was
outside
of
the
cluster
external
storage,
which
comes
along
with
a
couple
problems.
One
of
them
is
it's
not
portable,
really,
you
think
about.
A
If
you
have
a
you
know,
a
set
of
storage
appliances
like
nas
devices
stands
whatever
they're,
not
very
portable
to
other
solutions,
so
that
can
cause
some
issues
and
there's
also
sort
of
a
deployment
burden
as
well.
You
have
to
you,
know
physically
go
through
the
effort
of
setting
those
up,
plugging
them
in
and
all
that
sort
of
stuff,
so
not
ideal
would
be
better.
A
Software
could
do
that
for
us
right
and
then
also
you
could
use
cloud
storage
from
the
cloud
providers,
your
google,
persistent
disk
or
ebs
volumes,
et
cetera
and
other
managed
services
as
well,
which
can
typically
lead
to
vendor
lock-in.
Whenever
you
use
cloud
provider,
maintenance
services
which
which
are
good,
they're
they're,
pretty
valuable,
it
does
make
it
harder
to
move
to
another
cloud
and
then
there's
this
whole
other
element
of
day.
Two
operations
of
you
know:
backups,
restores
ongoing
operations,
making
sure
it's
healthy.
Somebody
has
to
do
that
right.
A
So
if
we
take
a
look
at
this
visual
here,
this
is
just
a
quick
sort
of
diagram
of
external
storage
for
kubernetes,
and
so
we
see
on
the
left.
We
have
a
kubernetes
cluster
on
the
right.
We
have
all
sorts
of
different
types
of
storage,
cloud,
storage
and
storage
appliances
and
such
and
volume
plugins
is
what
is
serves
as
sort
of
a
bridge
between
the
cluster
and
the
external
storage
to
provision
it
on
demand
and
provide
it
to
applications.
A
So
that's
typical
way
that
you
would
do
external
storage
in
kubernetes,
which
brings
us
to
what
is
rook
so
rook
can
be
thought
of
as
a
set
of
storage
operators
for
kubernetes,
and
this
really
brings
storage
into
inside
to
the
kubernetes
cluster.
You
can
think
of
operators
as
being
a
you
know,
software
for
automation
and
an
api
to
do
a
whole
bunch
of
operational
tasks
for
running
storage.
A
So
that's
one
way
to
think
about
what
rook
is,
but
you
know
beyond
those
operators,
it's
also
a
framework
to
allow
a
lot
of
different
storage
providers
to
migrate
or
make
their
way
into
cloud-native
ecosystem
and
cloud-native
environments
and
kubernetes.
We'll
talk
more
about
that
framework
in
a
bit.
It's
an
open
source
project
and
it
was
donated
to
the
cloud
native
computing
foundation
a
couple
years
ago
and
it's
incubation
level
right
now,
but
the
vote
is
ongoing
for
it
to
be
moved
to
full
graduation
from
the
cncf.
A
So
the
you
know
quick,
shout
out
to
the
community
gosh.
This
community
is
so
amazing
that
is
absolutely
the
backbone
of
why
the
project
is
successful.
So
we
take
a
look
at
some
of
the
more
recent
events
and
statistics
here,
1.4
released
came
out
which
is
all
sorts
of
new
features
and
improvements
to
the
rook
operators.
We
have
over
7
000
github
stars
now,
160
million
downloads
of
the
container
image.
My
favorite
part,
though,
is
how
we
almost
have
almost
300
contributors.
A
So
a
little
bit
more
about
the
framework,
so
rook
is
more
than
just
a
set
of
operators
right,
it's
a
whole
framework
and
platform
and
libraries
and
automation
and
functions
and
code
and
all
sorts
of
stuff
to
make
basically
make
it
easier
for
a
storage
provider
to
come
into
kubernetes
and
be
running
in
cloud
nano
environments,
so
there's
functions
and
and
libraries
to
help.
You
know
normalize
the
way
that
storage
resources
are
described.
You
know
a
set
of
hard
drives
a
set
of
pvs,
how
much
of
them
to
use
filters
patterns,
etc.
A
To
say
basically
say
what
storage
to
include
in
the
cluster.
You
know
all
sorts
of
the
operator
patterns
and
plumbing
there.
First
storage.
You
know
specific
storage
needs,
one
of
my
favorites.
So
is
the
integration
testing
that
we
have?
We
have
an
entire
framework
around
testing,
storage
solutions
and
storage
needs
across
a
variety
of
kubernetes
clusters,
versions,
clouds,
etc.
A
So
you
can
see
a
whole
series
of
storage
providers
that
the
rook
project
currently
supports
and
we'll
get
into
details
on
those
on
this
slide.
So
we're
going
to
start
with
the
stable
providers.
Each
one
of
these
storage
providers
has
been
declared
as
stable,
so
ceph
was
actually
the
first
storage
provider
that
rook
started
with
the
project
was
kind
of
founded
around
doing
orchestration
for
ceph
seth
provides.
A
You
know
three
different
types
of
storage
file,
block
and
object,
but
it's
also
really
highly
scalable,
which
is
has
some
really
nice
properties,
because
you
know,
basically
anyone
in
the
cluster
can
figure
out
where
a
piece
of
data
should
go.
You
don't
have
to
centralize
that
information.
So
that's
a
really
nice
kind
of
offloading
from
a
central
bottleneck
to
make
it
a
very
highly
scalable
solution.
A
This
slide.
We
have
both
our
alpha
and
beta
providers,
so
these
ones
are
not
quite
too
stable
yet,
but
they
are
on
their
way
maturing
and
growing.
Cassandra
is
a
distributed.
Nosql
database
that's
made
for
large
amounts
of
data,
and
I
like
this
one
especially
too,
because
a
contributor
named
giannis.
He
actually
did
that
for
the
initial
implementation
for
his
master's
thesis
when
he
was
graduating
from
graduating
with
his
master's
degree.
So
that
was
really
awesome.
A
Cockroachdb
is
a
highly
resilient
location,
aware
database,
which
has
really
cool
properties.
When
you
have
location
awareness
about
where
you're
running
you
can
make
decisions
about
where
to
move
data
to
be
closer
to
clients
where
to
move
data
to
be,
you
know,
to
have
excellent
availability
and
durability
properties
et
cetera.
So
it's
a
well-designed
database
and
that's
also
running
as
a
rook
storage
provider
nfs
the
network
file
system.
A
You
typically
use
this
when
you
want
to
have
multiple
writers
on
a
shared
file
system
that
was
originally
implemented
as
part
of
the
google
summer
of
code
project
a
couple
years
ago,
and
then
this
summer
there's
a
new
google
summer
of
code
participant
his
name
is
ahmad
and
he
is
making
lots
of
enhancements
to
nfs
this
summer.
So
there's
active
contributions
going
on
there
and
then
you
go
by
db
is
the
newest
storage
provider.
It
is
it's
a
relational
database
as
well.
A
A
So,
at
the
end
of
the
day,
though,
the
goal
of
rook
and
all
these
storage
providers
that
it
supports
is
for
persistence.
You
know
persistence
of
data
for
applications
right.
So
let's
start
talking
about
the
kubernetes
native
integration,
because
rook
is
a
set
of
storage,
orchestrators
and
a
framework
for
storage
in
kubernetes.
So
let's
talk
about
how
it
natively
integrates
there,
which
brings
us
to
a
visual
here.
This
is
an
analogy
we're
setting
up
here,
so
you
can
think
about.
A
You
see
this
little
tugboat
here
it's
pulling
or
guiding
the
big
cargo
boat
there
with
lots
of
valuable
cargo.
So
you
can
think
about
the
cargo
boat
being
a
the
data
plane,
the
storage
providers.
You
know
they
have
a
ton
of
valuable
cargo
on
there
and
the
tugboat
is
the
one
that's
kind
of
leading
and
guiding
and
steering
and
orchestrating
and
managing
some
of
the
the
direction
that
the
that
data
plane
that
cargo
ship
is
heading
in.
So
keep
that
analogy
in
mind
as
we
move
forward
to
the
operator
pattern.
A
So
the
operator
pattern
is
fairly
common
in
kubernetes.
Now-
and
it's
basically,
you
know
software
automation
that
sits
in
a
control,
loop
and
acts
in
three
phases.
The
first
is
that
it
observes
the
current
state
of
the
system,
the
actual
state
reality
in
the
cluster
and
then
it
analyzes
and
says:
okay.
How
is
this
actual
state
that
I
found?
A
So
we
take
a
look
at
this
architecture
diagram
a
little
bit
under
the
covers
here
about
how
rook
works.
Let's
work
left
to
left
to
right
so
cube
control
is
you
know
the
client
interface
to
kubernetes
api.
It
talks
to
the
kubernetes
api
server
there
and
you
can
do
things
like
you
know:
cube
control,
create
or
get
storage,
pools
and
file,
storage,
etc.
A
B
So
it's
kind
of
like
that.
If
you
think
of
the
operator,
I
guess
the
you
know
like
a
motor
turning
all
the
wheels
in
the
end,
the
custom,
resist
definition
is
basically
the
parameters
for
those
wheels
like
as
an
example,
let's
say
for
seth,
which
version
of
ceph
you
want
to
have
deployed.
That
would
be
one
parameter
and
well.
B
B
That's
what
the
operator
brings
with
it.
It's
bringing
its
custom
types
for
that,
and
I
mentioned
parameters
with
like
the
wheels
and
such
you
know
like
it's
and
a
custom.
Resist
definition
is
basically
nothing
else
like
if,
as
you
think
about,
maybe
like
a
pot
object
like
a
party
ammo,
it's
in
the
end,
nothing
different
to
that.
It's
a
specification
where
all
parameters
on
how
it
should
look
like
in
case
of
a
part
like
what
image
does
it
have
like
readiness,
liveness
probes?
B
How
many
well,
if
there
are
more
than
one
container
in
it,
labels
and
all
those
things
yeah,
so
those
are
basically
just
parameters
around
it
for
kubernetes
to
know
what
the
whole
thing
will
look
like
in
the
end,
for
the
whole
part
for
self-class
object
is
basically
the
same.
You
have
a
list
of
parameters
like
for
the
storage
fund,
like
what
nodes
should
it
use?
Should
it
use
all
nodes?
Should
it
your
all
available
devices?
B
Is
there
like
a
device
filter?
You
want
to
set
any
like
more
configuration
possibilities,
and
you
know
more
and
more,
like
I'm
not
going
into
each
parameter
here.
The
point
being
is
basically
a
big
list
of
parameters
which
the
operator
will
take
and
interpret
and
based
on
that
begin,
creating
and
or
modifying
the
existing
rook
cef
cluster,
which
is
running
and
to
be
go
a
bit
further
into
the
part
with
like
a
parameters
there.
B
For
example,
you
can
specifically
give
a
list
of
notes
you
want
to
use,
and
in
that
part,
what
devices
even
to
use-
and
that's
the
cool
thing
thanks
to
kubernetes
there,
we
can
simply
specify
our
custom
object.
There
is
now
a
magic
that
we
need
to
do
there
and
it
allows
us
to
easily
well
provide
users
with
a
safe
cluster
in
kubernetes,
based
on
those
parameters
for
rook
cipher,
especially
there.
It's
not
just
a
ceph
cluster
object
like
there's
more
around
in
ceph
as
well
already
there's,
for
example,
the
saf
block
pro.
B
We
have
the
api
version.
It's
not
like
version
one
or
apps
slash
version,
one
of
these
people
that
have
run
around
with
kubernetes
already
a
bit.
The
kind
is
not
deployment
or
something
it's
have
block
pull.
That's
our
custom
object
that
the
rig
operator
is
bringing
into
with
the
normal
like
metadata,
which
just
that's
the
name
of
the
object.
It's
the
namespace.
The
object
should
be
created
in
and
we
have
the
specifications,
and
in
this
case
we
define
the
specifications
just
to
say.
B
Well,
failure
domain
host,
replicated
size
free,
require
safe
replica
size
and
so
on.
These
are
well,
those
are
safe,
specific
parameters,
but
in
the
end
you
know,
operator
takes
those.
It
takes.
The
specification
works
it
out
in
terms
to
basically
translate
it
to
ceph.
If
you
will
so
and
take
care
of
that
for
you
as
the
user
to
build
up
from
a
story
there.
B
Basically,
we
have
a
sev
cluster
object
when
we
create
it,
it
will
well
attack
will
take
a
few
minutes
depending
on
how
fast,
like
pulling
images
and
all
those
things
are.
You
have
created
a
ceph
cluster
and
we
have
also
gone
ahead
created
a
set
block
pool
object
because
that
will
instruct
the
operator
to
create
a
pool,
a
storage
pool,
basically
in
the
cef
cluster
it
just
created
so.
B
B
There's,
for
example,
like
storage
class,
the
it
is
an
object
of
kubernetes
like
of
the
native
api
support
like
that
of
the
storage
apis
and
by
default.
Basically,
we
specify
a
name
for
the
search
class.
We
give
it
the
name
rooks
of
block.
We
tell
it's.
You
know
some
special
parameters,
some
way
like
where
to
even
look
for
who's,
the
provisional
storage
and
all
like
all
this
fancy
stuff.
B
We
don't
need
to
consider
also
too
much
with
that,
but
we
pointed
to
the
like
to
the
right
cluster,
which
is
the
rook
ceph
cluster
we
just
created
and
that
it
should
use
the
pool
replica
pool.
If
you
remember,
we
had
created
a
saf
block
pool
as
a
headed
up
as
a
yamal,
and
it
would
use
this
pool
then
for
the
storage.
B
So,
thanks
to
the
storage
classes
in
kubernetes,
now
the
only
thing
ajsa
or
we
need
to
do.
We
could
go
ahead
and
create
a
persistent
volume
claim.
We
create
a
persistent
volume
claim.
Well,
we
give
it
a
cool
name.
Microlab
is
probably
a
well
pretty
cool
name,
so
we
got
this
cover.
We
tell
the
persistent
volume
claim
which
starts
class
name.
In
our
case,
it's
the
rook
set
block
one.
We
tell
it
what
access
means?
I'm
not
going
too
far
into
that.
B
Basically
there
it
won't
work
unless
it's
well.
On
the
same
note,
but
you
know
it's
those
kind
of
edge
scenarios
still
where
it
wouldn't
it
wouldn't
work
out
if
it
would
be
on
different
notes,
because
the
blocks
block
image
normally
can
only
be
mounted
on
one
server
in
read,
write
mode.
So
that's
about
that
blur.
B
There's
also
other
modes
like
read,
write
many
read
read
only
many
as
well
also,
but
as
it
we're
not
going
to
concern
ourselves
too
much
with
that
right
now,
we're
going
to
set
in
a
position
right
over
at
persistent
volume
claim
also
the
resources
we
want.
In
this
case
we
basically
request
20
gigabytes
of
storage
and
well
after
we
have
created
one.
B
B
You
would
want
to
make
to
the
deployment
that
you
have
a
flawless
way
of
upgrading
like
you
currently
can
only
run
this
with
a
replica
of
one,
because
if
you
would
have
the
need
to
run
an
application
where,
like
each
replica,
so
each
pot
would
have
its
own
persistent
volume
claim,
it
would
be
necessary
because
you
know
block
storage
can
only
be
mounted
once
by
one
part.
Basically,
you
would
need
to
go
ahead
and
use
the
stateful
set.
So
this
is
more
just
the
demonstration
purpose
here
purpose
here
this
would.
B
So
we
have
our
application
they're
basically
running.
We
have
one
part
and
now
we're
going
to
dive
into
the
demo.
Okay,
diving
into
the
demo.
Now
for
first
part
for
ceph
operator,
we
need
to
create
the
common.yaml
all
the
objects
which
are
in
there
in
a
kubernetes
class.
So
we'll
simply
do
that
by
well,
and
it
will
really
create
crds
custom.
B
B
B
Well,
please
take
a
look
at
the
at
the
cluster
cluster
minus
test.yaml
for
that,
and
so
let's
dive
right
into
that
so
well,
you
know
we
have
a
name
name
system.
All
that
again
we
have
the
specification
which
ceph
version
it
will
use
with
some
additional
stuff
like
data
the
host
path,
I
would
recommend
you
to
read
up
on
like
what
each
part
here
does
in
the
documentation
on
rook.io.
B
But
you
know,
as
we
had
it,
there's
a
bunch
of
parameters
which
need
to
be
said
in
a
certain
way.
Most
of
them
have
defaults,
but
you
should
be
aware
of
what
the
defaults
are,
especially
when
you
would
go
ahead
and
run
it
in
production
at
one
point,
so
just
yeah.
Well,
you
know
we
have
the
whole
the
whole
structure
of
the
self
cluster
object.
B
So
let's
just
jump
back
and
see
how
how's
it
looking.
Okay,
we
have
a
bunch
of
components
already
having
spun
up
the
operator
in
the
background
is
creating
all
the
components
we
need.
We
have
the
mons
spinning
up.
They
are
a
vital
part
of
ceph
and
for
production.
Already
as
a
side
note
here,
you
should
have
at
least
three
months
if
you
run
with
less
than
three
months,
you're
not
going
to
have
a
quorum
for
the
seven
months.
So
keep
that
in
mind.
B
Okay,
so
we
have
the
months
now
it
is.
The
operator
has
now
started
the
so-called
rook
sap
osd
prepare
parts.
They
are
jobs
basically,
which
are
running
on
each
node
to
well
create
oh
well,
not
necessarily
great,
but
prepare
disks
in
the
server
for
osds.
So
that's
what
they're
doing
and
let
me
just
refresh
the
output
here.
B
It
has
already
finished
for
two
of
the
nodes
we
have
for
the
master
and
for
the
node
one
here
and
we
already
have.
Even
we
are
it's
already
faster
and
then
anticipated
right
now
we
already
have
the
three
osds
there.
Is
this
short
explanation
here
there
is:
these
are
the
part
which
actually
save
the
data
to
disk
there.
Now,
let's
run
another
again
to
update
the
output.
B
B
You
might
be
wondering
what
can
I
use
as
an
asd?
You
need
to
have
either
an
empty
partition
sidenote.
I
would
recommend
you
format.
The
disk
as
unformatted
may
seem
weird,
but
at
least
then
for
to
talk
about
she
parted
here
at
listen
to
your
part,
there's
an
option
to
say:
hey.
This
is
unformatted
and
in
the
k
clusters
I've
been
setting
up
when
like
even
though
the
partition
was
empty
and
it
didn't
work
after
that.
It
worked
when
I've
set
them
to
unformatted,
so
yeah,
just
a
quick
tip
here.
B
Let
me
jump
ahead
to
the
application
deployment
in
a
second
okay,
so
now
for
the
application
deployment
first
thing
we
still
need
to
do
is
create
a
storage
class
and
a
saf
block
pool.
As
we
learned
from
previous
previous
slides,
we
there's
a
pretty
convenient
example
in
a
csi
rbd
folder
called
storage
class
yaml.
As
you
can
see,
we
just
created
a
set
block,
pearl
called
replica
pool
and
a
storage
class.
So
we
got
that
now.
So
if
I
run
cube,
ctrl
get
storage
class,
we'll
see
there
we
go.
B
We
have
a
storage
class
now,
okay,
now,
let's
deploy
the
application.
Okay,
now
after
we
have
created
the
storage
class
and
with
that
also
self
block
pool,
we
can
just
run
cube.
Ctrl
create
on
our
application,
manifests,
which
are
also
in
this
case,
as
they
are
deployment
objects
and
a
persistent
volume
claim
object.
So
I'm
just
gonna
create
the
everything
that's
needed
for
that,
and
we
can
go
ahead.
We're
gonna,
keep
cuddle,
get
part
and
get
pvc
minus
w.
So
we
can
watch
the
whole
thing.
No,
we
can't
do
that
in
a
watch
mode.
B
B
A
All
right
alex
thank
you
very
much
for
that
helpful
demo
there
to
showing
us
how
some
of
the
book
project
works
with
a
little
bit
more
hands-on
experience
there.
So
now
we
can
talk
about
since
brooke
is
a
completely
open
source
project,
your
cncf
project.
We
have
a
pretty
broad
community
now
and
there's
a
lot
of
different
ways
that
you
can
get
more
involved
and
become
more
more
involved
in
the
community
as
a
whole.
So
the
main
site
is
rook.io.
A
That
has
some
more
explanation
about
the
project
and
all
of
our
documentation,
user
guide,
quick,
starts,
etc
is
all
there.
So
it's
a
great
place
to
go
if
you
want
to
start
using
the
rook
project
and
then
we're
super
active
on
slack
as
well.
There's
the
link
right
there.
If
you
have
questions
you
can
come
and
find
the
right
channel
and
we're
a
very
welcoming
bunch.
So
you
come
talk
to
us
there.
A
You
know
we
have
over.
You
know
almost
300
contributors.
Now
we're
always
looking
for
more
so
on
github.com.
That
is
the
repo
and
you
can
submit
issues.
Pull
requests
have
discussions
there
and
then,
of
course,
we're
also
on
twitter
and
we
have
community
meetings
every
other
tuesday.
The
specific
links
for
that
is
on
the
read
me
in
the
book
repo,
so
yeah
thanks
a
lot
for
listening
to
us
today
and
we
can
I'll
just
about
wrap
it
up.
B
Thanks
jared
so
yeah,
if
you
want
to
get
involved,
follow
the
links
check
out
our
slack.
If
you
have
any
questions
there,
especially
for
coupon,
wafer
channel
called
conferences,
well
feel
free
to
ask
questions
and
yeah
thanks
for
listening.
Everyone
have
a
good
day
and
well
see
you
next
time.
Hopefully.