►
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
Intro: Rook - Alexander Trost, Cloudibility & Travis Nielsen, Red Hat
In this talk, we will be introducing the Rook project 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. We will explore the benefits and use cases of Rook, and we will also walk through the architecture that the project is built on. Rook was accepted as the first storage project hosted by the Cloud Native Computing Foundation in January 2018.
https://sched.co/MPiS
A
B
A
So
yeah
we'd
like
to
tell
you
all
about
rook
today,
just
to
get
a
sense
of
what
you
all
know
about
rook,
who
here
has
at
least
tried
running
rook
somewhere
in
kubernetes?
Okay,
a
bunch
of
you
all
right
so
so
glad
to
hear
people
were
trying
it
out
who
just
heard
about
rook
in
the
keynote
this
morning.
For
the
first
time
plenty
of
you,
too.
Okay,
we
got
a
good
mix
here.
So
we
would
like
to
take
you
through
what
rook
is
all
about
and
show
show
you
a
demo.
A
Well,
so
we
just
released
the
one
dot,
Oh
rook,
release,
we're
excited
about
that.
It's
been
quite
a
journey,
so
I'll
be
happy
to
talk
a
little
bit
about
that,
but
ultimately
we're
gonna
talk
about
storage.
What
rook
does
for
storage,
how
it
brings
it
into
the
kubernetes
ecosystem
and
makes
it
a
more
native
part
of
the
experience.
A
Well
talk
a
bit
through
the
rook
design,
how
it
fits
together,
but
then
the
most
exciting
part,
hopefully,
is
the
demo
where
it
will
show
you
a
running
cluster
kubernetes
cluster
with
rook
and
what
it
takes
to
get
going.
At
the
end,
how
to
get
involved?
What
other
rook
sessions
we
have
will
will
have
I
think
four
sessions
tomorrow,
where
rook
will
will
be
involved.
B
So
yeah
one
of
the
biggest
parts
dead,
especially
like
every
time
I
open,
get
up
to
calm,
slash,
rooks,
Luke
I'm
always
happy
to
see
is
that
we
do
well.
We
gain
more
stars
and
well
stars,
are
kind
of
like
the
currency
in
how
pop
you're
a
lot
of
project
is,
if
you
also
and
well,
we
have
5.2
K
and
it's
still
rising
I
thought
we
were
already
free
yeah.
B
We
did
the
1.0
release,
which
is
great
besides
well,
ironically
ruk
already
having
like
well
stable
support,
if
you
will
so
for
the
staff
part
at
least
well.
We
now
have
hit
the
1.0
which,
for
some
people
it's
kind
of
the
line
we
approach
it
has
to
go
over,
but
well
we're
happy
to
those
people
that
came
because
of
the
1.0,
especially
and
well.
We
have
over
150
plus
contributors
and
it's
well
it's
great
to
see,
especially
for
some
community
provided
starch
operators
like
from
the
at
Rufus
caste
from
mix
anta.
B
A
Think's
Alex,
just
it
really
is
amazing-
to
see
the
growth
of
the
ecosystem
and
what
the
power
of
an
open-source
project
can
do
with,
especially
when
the
CN
CF
sees
the
value
and
it
is
helping
us
back
it.
So
we're
excited
so
this
journey,
so
work
was
first
open
sourced,
actually
a
coop
con
Seattle
November
2016.
It
was
a
little
bit
smaller
about
a
thousand
people.
Were
there
on
that
occasion,
nobody
had
ever
heard
of
Brooke,
even
at
the
conferences,
no
talks
or
anything.
A
So
we
had
ODOT
one
release
with
that
open
source
event
and
then,
since
then,
we've
released
roughly
a
quarterly
cadence
until
now
we're
at
the
1.0,
and
it's
just
we're
gonna
keep
on
going
on
this
cadence
and
yeah
just
having
fun
delivering
features,
bringing
storage
to
kubernetes.
So
so,
let's
talk
about
what
storage
involves
with
kubernetes
for
a
minute,
so
traditionally
kubernetes
applications.
We
assume
they're
stateless.
They
they're
designed
to
just
it's
running
here,
kill
it
run
it
over
there
great
we
treat
them
as
cattle
and
everybody's
happy,
but
what
about
the
applications?
A
Who
need
storage?
Traditionally,
you
know
you
by
your
storage
appliance
you
plug
it
in
somewhere
else.
You
manage
it
somewhere
else
and
it's
outside
of
kubernetes.
Then
there's
this
volume
plug-in
model
for
kubernetes
that
lets.
You
attach
your
storage,
that's
external,
to
kubernetes,
whether
it
be
you
know,
if
you're
running
in
the
cloud
Azure
Amazon,
if
you're
running
on
premise,
maybe
you've
got
staff
or
Gluster
running,
but
that's
the
traditional
model
for
working
with
storage
with
with
kubernetes
ok.
So
this
comes
with
certain
challenges.
Of
course,
the
storage
is
this
separate
animal?
A
That's
on
the
side!
You
can't
treat
it
just
like
your
other
kubernetes
applications.
Well,
we
thought
well.
Why
is
that?
Why
can't
we
just
treat
storage
as
another
application
in
your
cluster?
There's
a
it's
a
separate
deployment
burden.
We
don't
want
it
to
be
separate.
We
want
to
be
the
same
same
model.
You
might
have
bender
lock-in
right
right,
these
storage
appliances.
A
You
know
lock
you
into
that
solution.
It
you
have
a
different
solution,
whether
you're
running
on
premise
or
in
the
cloud
or
wherever.
So
you
know
the
question
to
ask
ourselves:
is
how
do
we
get
a
consistent
story
across
all
clouds
or
on-premise,
and
how
do
we
get
storage
that
follows
the
same
pattern
in
the
same
solution,
whether
or
wherever
kubernetes
is
running?
A
Ok,
so
this
is
where
rook
comes
in
with
rook.
What
we
did
is
we've
created
a
set
of
operators
that
will
run
storage
applications
in
kubernetes
and
we'll
talk
about
what
those
specific
operators
do,
but
really
there
are
two
different
categories
that
that
these
operators
and
what
Rick
will
do
for
you.
First
of
all,
it's
about
automating
the
deployment
and
management
of
the
storage
for
you,
so
we've
you
need
to
deploy
the
storage.
You
know
you,
you
start
up,
you
bootstrap
it
you
configure
it.
You
need
to
upgrade
it
over
time.
A
This
is
a
whole
set
of
problems
which
you
want
to
make
sure
is
automated
and
you
don't
want
to
have
to
manage
any
differently
from
other
urban
A's
applications.
Okay,
so
that's
the
first
thing
managing
the
storage.
You
need
a
management
layer
for
with
that
works
well
with
kubernetes.
The
second
thing
is
really
I'm
provisioning
of
the
storage.
That
means
using
the
kubernetes
volume
plug-in
model
to
attach
the
storage
with
PBC's,
so
that
mainly
involves
right.
You've
got
a
PVC.
You
you've
got
your
pod
that
needs
to
consume
the
storage.
A
A
Ok,
so
that's
now,
SEF
itself
has
been
in
production
for
a
long
time,
but
the
integration
with
kubernetes
we
declared
is
stable
edge.
Fs
is
another
operator
that
recently
has
been
integrated
with
rook
and
in
the
1.0
release
was
just
declared
as
beta
so
go
check
that
out
and
see
what
it's
capable
of
that.
You
know.
Other
storage
service
is
similar
to
Seth
Cassandra
cockroach
DB,
Mineo
NFS.
All
of
these
are
in
alpha
some
of
them
I've
been
in
rook
for
a
couple
releases.
It's
just
about
community
involvement.
A
B
Besides
study,
as
we
already
had
said
earlier,
like
with
Cassandra
and
so
there's
been
amazing
work
for
a
new
community,
it's
we
also
have
some
other
storage.
Softwares
have
come
up
and
hey.
Can
we
integrate
in
some
way
with
the
group
there?
So
again,
it's
amazing
to
see
the
community
there.
Oh
yeah.
A
A
You
may
have
heard
about
it
for
the
last
couple
of
years,
or
maybe
it's
completely
new
at
the
end
of
the
day,
it's
about
taking
what
you
need
to
deploy
and
creating
automation
around
it
and
do
it
in
a
way
that
it
looks
like
any
other
kubernetes
application
and
custom
resource
definitions
are
the
way
that
the
kubernetes
allows
us
to
do
this.
So
an
operator
will
sit
in
what's
called
the
control
loop
and
it
watches,
and
it
says
what
would
you
like
to
do?
A
Oh
you'd
like
to
create
this
type
of
thing,
a
like
a
Seth
cluster.
Okay
I'll,
go
create
that
now
with
the
settings
that
you've
described
in
your
manifests
or
this
llamó
file
which
which,
just
like
you
define
other
pods
and
deployments,
and
anything
else
in
kubernetes.
So
as
it
observes
what
you
your
desire
to
happen
in
your
cluster,
the
operator
goes
and
makes
that
happen,
and
automation
is
a
good
thing
and
the
other
effect
it
has
is.
It
simplifies
your
life
as
an
administrator
in
the
cluster.
A
You
you
just
don't
have
to
worry
about
all
of
the
individual
storage
settings
for
your
storage.
You
can
let
rook
take
care
of
that,
for
you
apply
some
smart
defaults,
but
then
you
can
also
override
those
defaults
and
change
those
settings.
When
you
need
to
see
RDS,
I,
guess
I
already
it's
all
about.
What
do
you
want?
What
settings
do
you
want
and
then
the
operator
makes
it
happen?
A
So
watching
yeah,
let's
skip
over
this
all
right,
so
the
operators
leverage
the
full
power
of
kubernetes.
That's
where
we
really
took
a
bet
early
on
in
in
Rooke,
where
we
said
we
believe
kubernetes
is
going
to
grow
and,
amazingly
it's.
You
know.
It's
been
amazing
that
way
and
let's
build
everything
around
kubernetes.
So
that's
the
only
storage
provider
or
sorry,
the
only
orchestration
platform
that
we
cater
to
it's
it's
all
about
kubernetes
use,
generate
services,
use,
replica
sets
or
demon
sets
deployment
secrets.
A
All
of
these
things
the
operator
talks
to
the
kubernetes
api
to
apply
these
settings.
We
don't
worry
at
our
level
about
like
what
now
do
you
have
docker
Ryan.
Do
you
have
you
know?
What's
underneath
the
covers?
You
have
system
D,
you
know
it's
it's
out
of
our
hands.
It's
just
standard
kubernetes
I,
also
note
that
the
rook
operators
are
not
on
the
data
path,
so
the
operators
are
just
the
management
plane
and
whatever
the
storage
provider
is
under
the
covers.
A
A
What
we
have
is
on
the
left,
your
standard
coop
cuddle
tool
where,
whatever
you
want
to
create
you
say
or
whatever
you
want
to
know
about
the
cluster
you're
you're,
creating
it
you're
querying
it
so
with
rook,
again,
you're
just
gonna,
be
able
to
say
coop
cuddle,
create
your
llamo
file,
your
rook
cluster
and
same
tools
you're
already
using
and
the
operator
will
work
on
that.
So
now
the
operators
on
the
right.
So
we
have
one
Operator
for
each
storage
provider.
A
A
Overall
picture
is
operators
talk
to
the
kubernetes
api
to
create
these
resources
and
use
the
CSI
or
other
drivers
to
attach
the
storage
from
your
pods,
an
example
with
SEF.
So
I
do
work
with
the
SEF
team
at
Red
Hat.
So
that's
what
would
I'll
be
focusing
on
for
the
demo
today
tomorrow
and
the
rook
deep-dive
definitely
come
back,
for
that
there
will
be
more
talk
by
other
maintainer
is
about
the
other
storage
providers
that
rook
has
but
first
SEF
as
an
example.
A
There
are
there
a
bunch
of
settings
that
we
need
to
know
about
your
cluster.
What
version
of
SEF
do
you
want
to
run
because
that's
a
different,
that's
a
different
version
from
what
version
of
rook?
How
many
SEF
monitors
do
you
want
to
run?
You
know
the
smart
thing
is
well,
you
need
at
least
three,
so
you
can
have
a
quorum.
Do
you
want
it
to
run
with
host
network
for
storage?
A
A
If
not
just
just
know
that
there
are
these
storage
demons
being
started,
such
that
the
storage
platform
will
be
available
to
consume,
from
your
PBC's
and
and
in
this
picture
note
that
there's
really
only
the
rook
operator,
which
is
the
little
blue
castle
there
there's
only
one
or
a
few
of
these
pods
running
the
rest
are
really
the
storage
layers
demons.
So
the
safety
in
this
case
running
where
there's
not
any
rook
in
that
code
path,
all
right,
so
you
you
create
your
yeah
Mille,
you
get
pods
and
other
services.
A
We
kind
of
touched
on
this
already
so
Rick
is
a
framework
for
other
storage
solutions
and
the
what
we
get
in
common.
We
really
get
patterns
around
how
to
create
or
there's
some
common
code
that
helps
that
helps
these
operators
work
with
the
different
kubernetes
api's.
There's
a
common
testing
effort,
because
you
need
you
need
reliable
storage.
You
need
stories,
that's
durable,
so
the
testing
framework
really
helps
make
sure
that
that
things
are
well
tested
before
release
all
right.
So
let's
go
to
the
demo
I'll
switch
over
here
and.
A
A
A
No
all
right,
let's
make
sure
what
we
got
here,
so
coop
Cod
all
get
nodes
just
to
see
if
we're
connected.
Alright.
So
in
our
cluster
we
have
well.
We
have
four
worker
nodes,
a
couple
of
masters,
so
what
I've?
What
I've
done
is
I've
pre-configured
the
yamo
files
our
manifests,
so
that
will
start
storage
on
and
consume
the
storage
on
three
of
these
nodes.
A
Okay,
go
over
here
clear!
Alright,
now
the
let's
see
alright,
so
I've
got
it.
These
yellow
files,
I'll
create
them
one
by
one
and
describe
as
I
go
so
coop
cuddle,
create
common.
Is
that
big
enough
for
should
I
make
it
bigger?
Okay,
okay,
so
common
dot
y
Amal
when
I
hit
create
it's
going
to
create
the
the
security
settings
that
are
back.
All
these
service
service
accounts
that
rook
needs.
Rook
needs
to
have
privileges,
to
run
pods
privileged,
for
example,
because
the
operator
needs
to
start
these
demons
which
consume
local
devices.
A
You
real
hardware
on
the
nodes,
so
we
do
run
some
pods
privileged
for
that
purpose.
So
we've
got
this:
now
we
don't
have.
We
don't
have
any
pods
yet
just
to
confirm
all
right.
No
research
is
found
so
now
I'm
going
to
go
ahead
and
create
the
operator
create
operator
and
before-
and
this
is
openshift-
there
are
several
settings
specific
to
OpenShift.
But
before
I
do
that,
let
me
say:
watch
Kubb,
cuddle
get
hot
all
right
now,
hopefully,
when
I
create
the
operator
will
see
the
pod
start
to
appear
all
right.
A
There
we
go
so
the
operator
is
the
first
pod
to
start
and
immediately
as
soon
as
it
starts,
it's
going
to
create
several
other
pods
on
our
storage
nodes
so
that
we
can
detect
what
storage
devices
are
available
and
also
start
an
agent
which
will
help
us
attach
the
storage
later
this.
This
is
currently
using
the
Flex
driver
for
a
rook
which
will
attach
the
SEF
Ceph
storage,
all
right.
A
A
So
this
is
the
yeah
Mel
that
has
all
the
settings.
I
show
it
on
a
couple
slides
ago
that
tell
it
what
version
of
SEF
to
run
so.
The
first
thing
it
does
is
detect
what
version
of
SEF
do
you
want
to
run
in
this
case
is
going
to
detect
SEF
Nautilus,
which
was
just
released
a
couple
months
ago.
The
the
next
thing
is
going
to
do
it's
going
to
create
some
selfies,
save
them
as
secrets
in
kubernetes.
Then
it's
going
to
start
creating
these
SEF
monitors.
A
Ok,
who
here
has
has
deployed
SEF
independently
from
Brooke
anybody.
So
you
probably
know
it's
it's
not
very
easy,
or
at
least
not
as
easy
as
this.
Hopefully,
that's
why
we
created
rook
to
make
it
easy,
but
you
need
monitors
so
it's
going
through
one
by
one,
it's
making
sure
they're
in
quorum
each
step
of
the
way
after
we
have
three
monitors.
So
just
in
a
few
more
seconds
here,
so
we
see.
Okay,
we
have
Mon
a
Mon,
a
Mon
be
and
Mon
C.
A
So
once
those
are
all
in
quorum,
then
it
will
create
the
Ceph
manager
as
the
next
pod
that
will
initialize
some
SEF
manager,
plugins
and
modules,
and
then
we'll
get
our
oh
s,
DS,
which
are
the
storage
daemons.
That
will
really
create
the
storage
platform
that
staff
is
going
to
serve
up
from
from
each
of
the
nodes
and
make
it
look
like
this:
the
software-defined
storage
system,
okay,
so
we
have
the
manager
now,
while
that's
going
so
we'll
see
that
OSD
start
to
come
in
up
in
a
minute.
A
A
A
Okay,
now
that
we
have
the
toolbox,
we
have
our
Oh
s,
DS
yeah,
let's
go
back
to
OS
DS.
So
we
see
right
here
that
we
have
three
OSD
daemon
pods
they're
running
on
each
of
our
three
nodes:
okay,
they
they're
ready
ready
to
go
so,
let's
connect
to
the
toolbox
now
and
see
the
status,
so
we're
going
to
say
for
convenience,
I'm
going
to
connect
with
OC
to
the
toolbox.
All
right
I
need
the
pod
name.
A
A
Let
me
just
show
you
what
the
storage
class
looks
like
so,
along
with
a
storage
class,
we
have
a
safe
block
pool
and
in
that
pool
the
interesting
thing
is
you
can
tell
it
how
many
replicas
of
your
data
do
you
want
in
the
cluster
or,
if
you're
familiar
with
erasure
coding,
it
can
configure
erasure
coding
as
part
of
that
pool.
So
in
the
for
this
demo,
I
said,
let's
create
two
copies
of
the
data:
okay
for
the
storage
class,
which
is
in
the
same
amyl.
We
tell
it.
A
Okay,
my
rook
cluster
is
in
this
namespace
when,
when
you
mount
the
storage
use,
XFS,
oh
and
I
skipped
over
the
block
pool
and
the
pool
that
this
storage
class
should
use
is
the
replica
pool
which
was
the
pool.
I
just
showed
you
with
replicas
okay.
So
let
me
exit
this
and
go
ahead
and
create
that
storage
class.
A
A
Now,
let
me
just
show
quickly
what
that
looks
like
in
the
yeah
mol
and
show
where
the
PBC
is.
Let's
see
so
in
this,
my
sequel,
yeah.
Well,
we
see
a
definition
for
a
persistent
ball.
You
persistent
volume
claim
and
we're
requesting
simple
20
gigabytes
and
read/write
read/write
once
and
it
comes
from
this
storage
class
rook
set
block
that
we
just
created
okay
and
then
later
in
this,
you
can
see
the
pod
definition
that
uses
this
this
PVC,
so
that
you
can
mount
it
in
into
the
my
sequel
pod.
A
So
with
that,
let's
go
ahead
and
and
create
create
yeah
Milus
I've
got
a
my
sequel:
I'll
just
go
ahead
and
create
the
other
one,
and
we've
got
WordPress
okay
and
at
the
bottom.
Well,
these
may
scroll
off.
Let
me
make
this
bigger,
so
we've
got
two
pods
that
are
starting
up
and
as
soon
as
the
that
storage,
that
PVC
is
bound
and
and
mounted
we'll
see
them
in
running
state.
Okay.
So
now
we
have
WordPress
running
in
this
state
where
it's
ready
and
available.
A
Now
the
WordPress
does
take
a
couple
of
minutes
to
startup
initialize
the
database
and
things
so
in
a
couple
of
minutes:
I'll
open
it
up
in
browser
and
we'll
double
check
that
it's
actually
running,
but
that's
basically
in
a
nutshell,
so
you've
got
storage
orchestrated
by
rook.
You
know
it
started
asset
cluster.
It
then
allowed
you
to
create
but
define
the
PBC
which
mounts
from
the
storage
class
and
gives
you
this
storage
all
right.
A
So
this
well
that's
going
well,
we
will
see
if
I
get
the
services,
so
the
WordPress
app
creates
a
load
balancer
service
that
will
be
at
this
URL
since
it's
running
an
AWS.
It
just
gives
me
this
nice
URL
and,
let's
see,
where
did
my
browser?
Go?
Oh
I'm
in
presentation
mode.
So
now
this
probably
won't
work
yet
because
WordPress
is
still
initializing,
but
we'll
come
back
to
in
a
minute
and
and
talk
about
that.
So
why
don't
we
go
back
to
the
slides
for
just
a
couple
of
minutes?
A
B
So
we
have
seen
right
now
that
it's
pretty
easy
to
well,
especially
in
a
test
environment.
Creators
have
class
two
for
storage,
but
kind
of
thing
about
more
or
less
just
as
a
use
case.
For
let's
say
in
my
case,
I
have
some
bad
mental
servers
and
what
I
don't
have
money
to
buy
more
service
for
well,
exactly
you
for
storage,
so
I
could
just
go
ahead,
run
my
applications
with
kubernetes
as
containers
and
just
well
put
roots
F
on
there
and
have
my
storage
a
to
like
well.
B
If
the
applications-
and
you
at
one
point
used
too
much
load
of
the
service
and
yeah,
you
will
run
into
some
issues
there
with
well.
Virginia
is
also
just
another
application
running,
but
it
could,
for
example,
in
this
case,
helped
me
so
long
till,
for
example,
I
would
get
more
funding
from
a
company
or
something
to
get
more
service,
just
kind
of
as
a
idea
where
it
could
also
be
as
a
used
as
a
use
case
there
and
well.
You
showed
it
with
directories,
but
the
same
goes
for
disks.
B
B
I
had
like
I
think
one
of
the
longest-running
clusters
or
oh
well,
not
the
longest
path
from
like
version
0.6
on
to
like
zero,
eight,
zero,
nine
and
well.
The
only
reason,
but
a
class
I
have
wasn't
well,
isn't
the
longest
running
now
anymore.
It's
because
I
got
new
hardware
and
just
trapped
everything
inside
it
over
I
say
well.
Maybe
someone
else
doesn't
like
this
starts
a
new
version
kind
of
with
kubernetes
and
resets
to
zero
to
rebuild
what
you
learnt
till
adventure
there.
So.
A
A
B
Ucsd
dairy-
it's,
for
example,
to
which
is,
which
is
simply
awesome,
to
see
that
it's
well
not
only
applicable
for,
like
smaller
use
cases
like
in
my
case,
with,
like
seven
suddenly,
but
also
for
bigger,
well
universities.
Also,
companies
there's
also
a
good
amount
of
companies
using
it
and
already
in
production.
For
those
of
you
going
like
hey.
Can
we
use
it
in
production?
Yes,
there
are.
A
lot
of
people
are
a
since,
like
already
I,
think
like
at
0.3,
0.2
or
so
started
using
it
very
early.
A
A
B
A
B
Yeah,
so
well,
if
you
want
to
use
it
as
a
user
best
way
would
be
to
go
to
route
at
I/o.
We
have
a
big
documentation
link
at
the
top.
If
you
go
to
it,
there's
like
a
link
to
the
staff
getting
started
guide,
but
I
also
for
the
oddest,
like
HFS,
Cassandra
and
so
on,
and
well
hoping
that
you
not
run
into
any
issues.
B
But
still,
if
you
should
run
into
any
issues,
we
either
have
to
get
up
project
where
you
can
create
issues
or
just
sit,
hop
on
slack
and
well,
ask
or
say
that
you
have
an
issue
yeah
besides.
If
you
want
to
get
involved
too
well,
for
example,
as
you
said,
with
a
new
storage
bag,
and
maybe
even
possibly,
we
have
communion
team.
B
A
A
A
A
Okay,
yes,
so
the
question
is:
if
you
can
apply
it
more
OSD,
backfill
settings
or
other
OSD
settings
yeah?
Yes,
it
is
possible
to
apply
any
Ceph
settings
to
for
the
daemons.
There
is
document
in
advanced
documentation
on
the
site
that
says
how
to
do
that.
Basically,
you
set
the
Ceph
settings
in
a
config
map
and
then,
when
it
creates
the
pods,
those
pods
pick
up
the
settings
from
that
config
map.