►
From YouTube: Rook: Intro and Ceph Deep Dive - Travis Nielsen, Sebastien Han, Blaine Gardner & Satoru Takeuchi
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Rook: Intro and Ceph Deep Dive - Travis Nielsen, Sebastien Han & Blaine Gardner, Red Hat; Satoru Takeuchi, Cybozu, Inc
The Rook project will be introduced to attendees of all levels and experience. Rook is an open source cloud-native storage operator for Kubernetes, providing the platform, framework, and support for a diverse set of storage solutions to natively integrate with Kubernetes. Rook turns storage software into self-managing and self-healing storage services. A deep-dive will be presented for the Ceph storage provider to show how Rook provides stable block, shared file system, and object storage for your production data. The recent features in the v1.7 release will be covered to further illustrate how Rook continues to be enhanced for production environments. Rook was accepted as a graduated project by the Cloud Native Computing Foundation in October 2020.
A
A
B
A
A
A
A
A
A
Brooke
has
three
live
storage
providers
right
now,
three
active
storage
providers,
I
should
say
for
stable.
We
have
steph,
thus
the
upcoming
deep
dive
into
rook
with
ceph.
We
also
have
nfs
and
cassandra
in
alpha
phase
and
with
some
recent
changes,
we're
now
able
to
release
all
of
these
storage
providers
independently,
so
they
don't
all
have
to
be
released
at
the
same
time,
if
some
features
still
need
to
be
baked
a
little
bit
for
nfs
there,
there
is
that
time
and
freedom
available
as
an
example.
A
A
A
With
the
architectural
layers
we
have
rook
cef,
csi
and
seth,
starting
with
the
rook
layer
that
owns
the
deployment
and
management
of
everything
else,
which
is
ceph
and
ceph.
Csi
cefcsi
itself
is
the
thing
that
dynamically
provisions,
storage
in
ceph
and
then
mounts
that
into
user
application,
pods
and
with
chef
we
have
our
data
layer
that
does
all
the
data
protection
data
movement.
A
A
This
is
the
driver
that
actually
makes
the
storage
inside
steph
like
that
it
creates
it
inside
ceph
and
then
it
connects
that
storage
into
user
application
pods.
I
also
won't
go
too
deep
into
everything
you
see
here.
I
think
the
important
takeaway
sort
of
expanding
beyond
the
csi
view
from
before
a
little
bit.
A
A
Very
rarely
do
these
need
any
modification
at
all,
and
then
creation
of
the
ceph
cluster
resource
that
we
have
in
rook
is
the
only
thing
that
most
people
really
need
to
to
customize.
To
get
things
started
and
at
its
simplest
it
could
be
the
13
lines
of
code
that
you
see
the
13
lines
of
yaml
that
you
see
off
to
the
right.
A
A
A
Work
also
runs
in
really
any
environment.
You
could
want
these
commonly
we
break
down
into
two
two
basic
umbrellas
being
bare
metal
or
inside
of
a
cloud
provider
with
bare
metal.
This
may
be,
you
have
your
own
hardware,
or
it
may
be
that
you
have
a
shared
hardware
situation
in
a
data
center
we
commonly
get
asked,
especially
by
people
used
to
running
kubernetes
on
bare
metal.
Why
would
you
want
to
run
rook
in
a
cloud
provider
and
the
the
responses
here?
I
I
really
find
quite
fascinating.
A
A
Some
cloud
providers
also
limit
the
number
of
pvs.
You
can
have
per
node
to
30,
which
is
sort
of
pathetically
small
for
for
a
lot
of
users,
and
it
may
simply
be
that
users
want
to
save
money.
They
can
use
a
cloud
provider,
they
can
still
use
cloud
provider
storage,
but
they
can
use
something
that
has
a
better
cost
to
performance
ratio
and
to
aggregate
that,
together
into
something
that's
usable
with
rook.
A
The
bottom
line,
also
especially
for
multi-cloud
situations,
is
that
consistent,
a
consistent
storage
platform
like
the
one
that
rook
can
provide,
is
can
be
used
anywhere.
Kubernetes
is
deployed,
and
this
is
like
again.
The
interface
is
just
using
persistent
volume
claims
for
underlying
storage,
there's,
no,
nothing
extra
or
fancy.
It's
just
make
a
claim
for
storage
and
in
a
cloud
environment.
There's
no
need
for
direct
access
to
local
devices
as
we're
using
a
cloud
provider's
pvcs
as
the
underlying
storage.
In
many
cases.
A
Also
sort
of
expanding
on
environments:
here
we
it's
possible
to
configure
rook
for
any
cluster
topology
really.
This
is
customizable
across
failure,
domains
or
within
failure
domains,
and
this
really
is
toward
the
end
of
providing
a
highly
available
and
durable
storage,
and
this
is
achieved
by
spreading
ceph
daemons
and
data
across
failure
domains
as
much
as
possible.
A
Also
key
with
rook
is
that
updates
are
automated.
I
mentioned
this
a
little
bit
before
and
we
can
think
of
this
in,
like
in
two
parts,
there
are
upgrades
to
cif
and
then
there
are
upgrades
to
rook
with
steph
updates
and
even
major
upgrades
are
fully
and
totally
automated
rook
handles
everything
I
can
go
from
a
major
release
of
cefs
version,
15
octopus,
for
example,
to
version
16,
pacific
and
rook.
A
A
Sometimes
we
need
to
update
the
permissions
that
rook
has
or
any
number
of
things,
or
we
have
feature
deprecations,
which
require
a
small
amount
of
manual
work
if
users
are
using
those
features,
a
notable
feature
deprecation
I
just
talked
about
is
deprecating
the
flex
volume,
which
is
very
little
used
anymore,
even
feel
free
to
read
the
latest
ceph
upgrade
guide
here
at
the
link.
Also.
A
Well,
rook
also
allows
connecting
to
that
external
ceph
cluster,
so
that
then
kubernetes
has
access
to
it
and
just
like.
If
rook
itself
were
running,
the
cef
cluster
users
can
still
just
request
the
storage
they
want
and
it
gets
created
in
kubernetes
and
there's
no
no
fiddling
necessary.
No
extra
administration,
that's
necessary.
A
And
then,
whenever
rook
sees
that
obc
come
in,
it
creates
a
bucket,
and
then
it
gives
the
user
access
to
the
bucket
via
a
kubernetes
secret
there's.
Also
a
kubernetes
enhancement
proposal
called
cozy.
The
container
object,
storage
interface,
which
we're
we've
been
following
pretty
closely
and
we're
waiting
to
get
into
kubernetes.
So
so
we
can
also
provide
this
option
for
users,
and
this
aims
to
be
csi,
but
for
object.
Storage,
if
I
were
to
put
it
in
a
very
short
number
of
words.
A
A
A
A
So
I
promised
I
would
get
back
to
stretch
cluster.
Many
users
want
to
run
ceph
in
multiple
failure
domains.
This
allows
us
to
actually
have
the
better
disaster
protection
that
I
mentioned
and
most
commonly.
This
is
really
either
two
zones
or
three
zones.
We,
we
really
don't
see
more
than
three
zones
terribly
often.
A
A
We
have
two
primary
zones,
and
this
is
in
our
example,
where
all
of
our
user
applications
live.
This
is
also
where
all
of
our
ceph
storage
lives,
and
this
is
where
most
of
the
ceph
monitors
are
going
to
live.
We
have
the
third
zone
on
the
right,
which
is
a
monitor
that
exists
as
a
tie.
Breaker
just
for
the
case
of
a
whole
zone
going
down,
we
still
can
have
a
majority
quorum,
and
this
is
still
what
it
looks
like
during
normal
operation.
A
A
True
story:
this
actually
happened
to
me.
With
this
tiebreaker
zone,
there
are
still
a
majority
quorum
of
three
out
of
five
nodes
and
ceph
has
protected
all
of
your
data.
All
of
these
osd's
in
zone
two
still
have
all
of
the
data
that
exists,
and
it's
still
available
kubernetes,
because
it's
kubernetes
will
reschedule
any
applications
from
zone
1
into
zone
2
once
it
realizes
they're,
failed
and
now,
after
some
surprisingly
short
amount
of
downtime,
ideally
less
than
15
minutes.
A
A
B
As
for
pvc-based
cluster,
you
are
free
from
describing
hardware
configurations
like
this,
and
then
you
should.
You
should
specify
only
to
field
the
count
field
and
the
volume
claim
template
field
count.
Field
means
number
of
ost
and
volume
claim
templates
field
is
used
for
template,
or
pvc
used
for
osts
pbg-based
cluster
is
very
easy
to
expand.
B
B
B
B
B
B
There,
no,
no
okay!
So,
let's
see
the
progress
of
creating
this
creating
root,
safe
cluster
get
caught,
so
roxy
operator
is
already
exist
and
the
g
support
this
port
for
safe
gsi
drivers
and
now
safe,
monitor
port
is
learning
and
the
second
and
the
next
step
is
create
a
manager
port
and
the
third
step
is
looks.
Creating
root,
safe
opera
looks
ost,
look
safe,
osd,
prepare
port,
it's
to
initialize,
the
initialize
data
structure,
on
top
of
our
local
block
device
and
the
last
rook
safe,
osd
port
is
created.
B
B
B
B
A
Thank
you
satori
for
the
demo,
thank
you
all
for
for
watching
and
for
your
interest
in
rook.
I'm
gonna
leave
this
last
slide
here
with
some
links
to
our
website
and
documentation
and
anything
else
that
you
you
might
have
interested
in
about
the
rook
project
and
I'm
going
to
attempt
to
leave
these
open.
While
we
then
go
to
the
q,
a
portion
of
our
of
our
presentation.