►
From YouTube: Deep Dive: Rook - Jared Watts & Bassam Tabbara, Upbound
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
Deep Dive: Rook - Jared Watts & Bassam Tabbara, Upbound
In this talk, we will be taking a deep-dive through both the architecture and some of the more recent developments of the Rook project. 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. We will learn in more depth about the recently added support for new storage providers, such as Cassandra and EdgeFS. We will also explore how Rook can implement new abstractions of storage to enable dynamic provisioning of more persistent resources in your applications, making them more portable and able to deploy consistently no matter what the environment is. Rook was accepted as the first storage project hosted by the Cloud Native Computing Foundation in January 2018.
https://sched.co/MPk3
A
A
A
It's
on
the
other
side
of
the
room,
so
I
was
like
Ari.
This
is
the
direction
the
room
is
in,
but
the
escalators
back
that
way
what
we're
all
here
and
that's
good
sorry.
So,
let's
talk
about
what
rook
is,
you
know:
do
we're
not
gonna
spend
much
time
on
that
because
you
all
probably
at
the
intro
session
yesterday,
but
let's
do
some
level
setting.
A
So
rook
is
a
cloud
native
storage
Orchestrator
and
what
that
means
that
we've
extended
kubernetes
with
new
custom
types
and
custom
controllers
in
order
to
add
a
lot
of
software
automation
around
operational
tasks,
that
a
human
would
normally
do
to
manage
storage
systems
so,
for
instance,
there's
a
number
of
tasks
on
the
screen
they're
about
you
know:
bootstrapping
configuring
deploying
managing
failover
all
these
sort
of
things,
these
operational
tasks
that
require
have
traditionally
required
a
human
operator
to
perform
them.
We
can
use
software.
A
We
can
automate
those
tasks
with
software
and
be
able
to
make
our
lives
a
little
bit
easier.
So,
in
addition
to
being
a
storage
Orchestrator
or
a
control
plane
for
data
services,
it's
also
a
framework
for
making
the
task
of
integrating
new
storage
systems
into
kubernetes
environments.
Much
easier.
We'll
talk
more
about
that
in
a
second.
So
it's
also
an
open
source
project
and
it's
hosted
by
the
cloud
native
computing
foundation.
A
We
first
donated
it
to
the
TNCs
back
in
January
of
2018,
and
then
we
were
graduated
to
the
incubation
level
in
September
of
last
year.
So
let's
talk
a
little
bit
more
about
that
framework.
I
was
talking
about
so
you
know,
rook
is
more
than
just
a
collection
of
operators
and
custom
resource
definitions.
It's
also
this
framework
that
you
know
allows
storage
providers
an
easier
job
of
integrating
their
storage
system
into
cloud
native
environments
such
as
kubernetes.
A
A
Around
events
and
listening
for
CR,
DS
and
Reconciliation
loops
in
order
to
watch
for
new
events
related
to
storage
and
take
action
upon
them,
and
then
we
have
a
like
a
big
testing
and
integration
testing
environment
that
launches
lots
of
different
kubernetes
clusters
across
different
versions
of
kubernetes
and
perform
testing
and
integration
amongst
those
to
make
sure
that
storage
is
working.
So
this
whole
set
of
framework
and
specs
and
policy
and
testing
etc,
can
be
used
by
different
storage
providers
to
make
their
job
easier.
So
we
have
right
now.
A
Steph
is
the
first
one
that
we
started
with.
We
started
the
Brook
project
with
only
SEF,
and
so
it
is
the
most
mature
it's
the
most
stable.
It
has
the
most
contributors
we've
also
since
making
this
rook
framework
we've
added
new
storage
types
as
well
as
cockroach
DB
min
IO,
NFS,
Cassandra,
edge,
FS
and
there's
more
on
the
way.
A
So
today
we're
gonna
talk
about
some
of
the
newer
operators
that
I
haven't
yet
had
a
much
of
a
chance
until
today
to
talk
about
so
I'm
kind
of
excited
about
that,
I
also
wanted
to
call
out
the
the
Brooke
project.
We
released
1.0
just
a
few
weeks
ago
and
as
part
of
that,
you
know,
there's
a
lot
of
features
and
code
and
whatnot.
They
got
included
in
that
release,
but
my
favorite
things
is
actually
the
artwork.
A
So
all
these
cool
little
like
night,
designs
and
stuff
that
we
have
in
the
slides
do
a
designer
named
Chris
did
all
those
for
us
and
I
think
he
did
an
awesome
job
with
the
artwork
and
the
stickers
and
t-shirts
we
had
we're
gone
within
I
think
like
20
minutes
or
something
at
that,
so
either
people
like
the
artwork
or
we
bought
way
too
few
stickers.
But
one
of
the
one
of
those
is
probably
true
all
right.
A
So
let's
talk
about
the
Apache
Cassandra
operator,
so
Cassandra
is
also
an
open-source
project,
but
it's
a
distributed,
no
sequel
database,
and
so
what
I
really
like
about
Cassandra
is
that
it
can
handle
a
large
amount
of
data.
You
can
throw
a
whole
bunch
of
data
at
it
and
because
it
scales
across
a
whole
bunch
of
cheap
commodity
hardware.
You
can
just
continue
throwing
cheap
hardware
at
it.
Instead
of
vertically
scaling
with
expensive
machines,
you
can
horizontally
scale
with
a
bunch
of
you
know
less
expensive
machines,
and
then
you
get
high
availability.
A
You
get
the
entire.
You
know
super
large
data
sets
and
no
single
point
of
failure
for
that.
No
sequel
database
to
to
die
on
that
say
so.
Cassandra's
a
complicated
system,
most
distributed
storage
systems
are
complicated.
That's
F,
that's
complicated!
That's
what
we
started
with
Seth,
but
Cassandra
is
not
really
that
much
less
complicated,
I
would
say
so.
I
think
that's
a
great
candidate
for
building
an
operator
around
it
to
be
able
to
bring
Cassandra
into
our
kubernetes
clusters
and
have
operational
expertise
in
automation
to
manage
it
for
us.
A
So
I
definitely
want
to
call
out
that
the
the
rooks
Apache
Cassandra
operator
was
designed
and
implemented
by
a
guy
named
Yanni's
Jana
cicadas
as
part
of
his
graduate
thesis.
So
I
think
that
he
did
an
awesome
job
with
it
and
you
know
he
actually
went
and
presented
and
defended
his
thesis
about
the
Kassandra
operator
that
he
wrote.
I
didn't
do
anything
nearly
that
cool
when
I
was
in
school.
So
I
think
that
Yanis
is
that
was
really
cool
for
him.
A
To
do
that
he's
a
great
is
a
very
valued
member
of
the
rook
community
now
and
he
was
sponsored
by
a
company
called
our
Aikido.
That
has
a
booth
here
in
the
trade
show
floor,
trade
show
floor
and
Yanis
actually
works
there.
Now
we
got
to
show
you
in
the
room
they
might
not
be,
but
he
did
a
great
job
all
right,
so
so
Cassandra
we
could.
The
first
question
we
want
to
ask
is:
do
we
need
an
operator?
A
We
could
maybe
just
try
to
throw
some
stateful
sets
at
it
and
see
if
that
can
manage
Sandra
for
us
appropriately,
but
there's
a
couple
of
different
downsides
to
that.
One
is
that
the
stateful
set
doesn't
really
give
us
a
hierarchical,
topology
model
that
we
can
use
to
define
a
complicated
Cassandra
cluster,
but
the
staple
set
just
kind
of
confined
you
to
one
rack,
and
you
can't
do
this
different
hierarchy
and
multiple
racks
and
expand
out
the
cluster.
That
way.
A
Another
thing
is
that
scaling
down
a
Cassandra
cluster
you're
safely,
removing
one
of
the
nodes
is
a
process
that
you
don't
want
to
take
lightly.
You
need
to
first
do
Commission
the
node
and
then
you've
got
to
stream
all
the
data
off
of
it
to
get
it
safely
copied
around
the
cluster,
and
then
you
let
the
member
leave.
So
that's
not
really
a
great
facility
in
stateful
sets
to
let
you
do
complicated
operations
like
that,
in
which
you
want
to
maintain
the
integrity
of
your
cluster
and
then
there's
other
issues
too.
A
So,
let's
think
about
how
we
model
it
the
set
of
concepts
and
resources
in
Cassandra.
How
do
we
model
those
to
kubernetes
primitives
that
the
operator
the
Cassandra
operator
can
act
the
pond?
So
let's
start
at
the
bottom.
Let's
start
at
just
the
individual
members
of
the
Cassandra
cluster.
We
can
model
those
with
pods
each
one.
Each
member
in
the
cluster
can
be
mapped
at
a
single
pod
in
our
in
our
kubernetes.
A
Mini
stateful
sets
working
together
to
represent
the
racks
and
members
that
are
part
of
a
data
center
and
then,
finally,
at
the
top,
an
entire
cluster
can
be
modeled
with
a
custom
resource
definition,
a
CRD
that
represents
what
it
means
to
be
a
fully
fledged
Cassandra
cluster
and
you
you
could
tell
that
I
didn't
do
this
slide
because
it
has
animations.
This
is
Yanis
is
slide
minor,
pretty
pretty
broke
looking
compared
to
his
Oh
back
to
when
a
Jared,
slides,
okay,
no
animations,
so
the
Cassandra
operator.
A
It's
got
a
lot
of
neat
functionality
that
that
Yanis
coded
into
it.
So
the
first
one
obviously
is
cluster
creation
and
bootstrapping,
starting
with
a
plain,
vanilla,
kubernetes
cluster,
no
resources,
no
Cassandra
the
operator
will
take
the
steps
to
identify
the
storage
resources
that
could
be
included
in
the
cluster,
be
able
to
bring
up
members
upon
each
one
of
them.
Have
them
start
talking
to
each
other
and
form
a
cluster?
And
then,
once
you
have
a
cluster
running,
it
can
do
both
scale
up
and
scale
down.
A
Where
you,
you
know,
you
add
more
resources
like
a
new
node
to
the
cluster
or
a
new
storage
device
and
you'll
be
able
to
grow
that
cluster
scale
it
up
with
more
members
and
basically,
that
horizontal
scaling
we
were
talking
about
for
Cassandra.
The
operator
could
do
that
for
us
automatically,
and
we
also
talked
about
scale
down
too
and
how
important
it
is
to
do
that
safely.
We
have
to
decommission
the
member
stream
it's
data
and
then
allow
the
member
to
leave
the
operator.
Does
all
this
for
us
in
software
automation.
A
A
Alright.
Now,
let's
talk
about
edge
of
s,
so
these
slides
may
be
familiar
to
people
that
were
at
the
the
last
globally
distributed
global
scalability
talk
that
I
just
did
on
rook
but
edge.
Fs
is
another
storage
system
or
a
data
plane
that
rook
provides
orchestration
services
for
and
so
edge.
Fs
is.
It's
got
a
really
neat
architecture
so
from
the
ground
up
edge,
FS
is
natively
designed
to
be
globally
distributed
and
globally
scaled,
and
so
the
way
it
does.
A
A
You
know
that
make
up
files
etc
are
modeled
and
they
are
immutable
such
that,
if
you
change
a
block
and
a
file
system
or
in
a
file
that
that
that
block
gets
a
whole
totally
new
identity
for
it,
it
makes
it
globally
unique
it's
versioned,
etc,
and
so
that
starts
allowing
the
edge
of
s
storage
system
to
always
have
their
caches
at
each
one
of
the
globally
distributed
sites
to
be
to
be
in
a
consistent
state.
It
allows
global
fault,
tolerance
and
global
reliability
and
scalability,
as
well,
so
for
the
terminology
of
edge
of
s.
A
They're
called
segments
like
when
you
have
a
edge
of
s
cluster
here
in
Asia
and
an
edge
of
s
cluster
in
Europe
each
one
of
those
is
the
segments
and
it's
able
to
stitch
those
together
into
a
single,
transparent
geo
namespace
via
what
they
call
is
GW,
which
is
an
intersect
McDade.
So
they
have
these
gateways
that
are
connecting
and
linking
all
of
the
different
edge
FS
clusters
that
rook
provides
orchestration
services.
A
For
so
I
think
this
is
a
really
cool
feature
of
edge
FS
and
the
edge
FS
operator
is
that
you
can
configure
it
to
be
in
a
metadata
only
mode,
and
what
that
means
is
that
say
you
have
one
site
in
Asia
and
then
you
want
to
also
have
another
site
of
data
in
let's
say
Europe.
So
what
you
can
do
is
that
you
can
stream
only
the
metadata
of
the
files
across
the
two
sites,
so
I'm
talking
about
what
the
file
names
are.
A
The
file
structure
hierarchy
like
the
file
system
tree,
the
sizes
of
files,
the
modification
time
stamps,
etc.
So
you
can
stream
all
that
across,
and
so,
if
you
think
about
it,
metadata
for
files
is
like
kilobyte
size
right
and
then
the
data
itself
is,
you
know,
gigabytes
or
terabytes.
So
what
this
allows
you
to
do
is
this
allows
you
to
almost
immediately
be
able
on
a
different
site,
to
start
using
the
file
system
in
a
useful
manner,
because
you
know
what
files
are
there.
You
know
their
time
stamps.
You
know
the
whole
hierarchy
of
them.
A
You
can
start
a
client
on
another
site,
can
start
fetching
a
reading
and
writing
files
and
the
data
is
not
even
there
yet.
When
the
client
wants
to
use
one
of
those
files,
the
data
will
be
lazily
populated
or
fetched
on
demand,
so
start
filling
in
that
site.
So
it's
not
just
you
don't
have
to
wait
for
file
a
file
B
if
I'll
see
and
then
finally
file
D.
A
A
Igfs
also
does
the
global
deduplication.
So
since
each
block
has
its
own
unique
identity
and
when
you
modify
the
block,
it
gets
a
whole
brand
new
identity.
We
can
do
things
like
a
deduplication
if
we've
got
multiple
copies
of
the
exact
same
data
chunk,
we're
only
gonna
store
that
one
time
or
store
it
as
many
times
as
we
need
to
for
the
redundancy
that
we
want.
But
basically,
if
you've
got,
you
know,
3000
copies
of
the
same
block,
you
don't
have
to
duplicate
it
and
we
saw
that
storage
space
for
3,000
of
them.
A
So
if
you
lose
some
data
on
one
edge,
FS
site
or
one
edge,
FS
cluster,
then
you
can
be
a
to
recover
that
or
fetch
it
from
another
cluster,
another
segment
completely
transparently
to
the
to
the
client
or
to
the
user,
so
that
when
they
do
a
fetch
or
sorry
a
read
for
a
data,
that's
not
actually
there
locally,
you
lost
it.
The
hard
drive
is
gone
whatever
it
may
be.
A
It
can
fetch
it
from
one
of
the
other
globally
distributed
sites,
and
there
will
be
a
little
bit
of
loss
in
in
throughput
necessarily
but
you'll
won't
get
an
error
on
the
client
you'll
get
that
data
back
and
then
your
local
cache
then
gets
repopulated
with
that
data
and
to
recover
automatically
from
the
the
data
loss
that
we
had
all
right.
So
those
are
the
two
new
operators
in
Brooke
or
two
of
the
newer
ones
at
GFS
has
been
declared
beta
now
with
the
Brooke
1.0,
so
edgy
fest
is
maturing.
A
It's
got
a
good
set
of
contributors
working
on
it
and
really
happy
with
the
progress
for
a
GFS
in
Cassandra.
If
we
could
get
more
contributors
on
that
or
get
more
Jana
sazon
it,
then
that
would
be
awesome
as
well.
We
could
continue
to
grow
the
Cassandra
support
as
well,
but
it's
a
whole
lot
of
really
good
support
in
the
Alpha
alpha
version
of
Cassandra's
operator.
Okay,
so
software
in
general
runs
in
many
different
environments.
Right
kubernetes
itself
runs
great,
pretty
much
anywhere
you
can.
A
You
know
it's
it's
ubiquitous
now,
right
it
runs
in
all
the
major
cloud
providers.
You
can
run
it
on
bare
metal.
You
can
run
it
on.
You
know
on-premises
things
like
that.
Kubernetes
is
everywhere
and
that's
why
there's
like
12,000
people
here
in
Barcelona
or
basically
right
rook
is
I.
Think
Brooke
really
shines
the
best
in
on-premises
scenario.
So,
for
instance,
if
you're
running
on
a
cluster,
you
don't
have
access
to
EBS
or
at
a
Google,
persistent
disk
right.
A
You
don't
have
any
of
those
nice
cloud
provider
services
and
so
with
the
bare
metal
you
have
there,
you
can
use
rook
to
orchestrate.
You
know
various
sets
of
data
services
like
Cassandra
or
SEF,
or
edge
FS,
to
give
you
highly
reliable,
highly
available,
durable
storage,
etc.
Services
in
your
cluster,
so
Brooke
is
great
for
on-premises
I.
Think,
though,
that
the
cloud
providers
they
are
they're
managed
services
that
they
run
are
great
in
the
cloud
they
have
like
a
full
team
of
engineers
behind
them,
like
with
an
SLA,
etc.
A
So
the
manda
services
that
cloud
providers
write
those
are
good
too
so
we've
got
kubernetes
everywhere.
We've
got
rookies
great
on-premises,
we've
got
cloud
provider.
Services
are
great
in
the
cloud,
but
can't
we
have
both.
Can
we
have
all
that
together?
Why
do
we
have
to
settle
for
just
one?
So
maybe
we
could
manage
our
infrastructure,
our
platform
services,
our
resources,
our
applications.
A
Maybe
we
could
manage
those
all
from
kubernetes
and
from
a
single
place
and
I
say
cute
control,
but
what
I
really
mean
is
the
kubernetes
api
such
that
you
know
if
it's
in
the
criminalities
api
and
integrated
that
way,
you
can
use
any
of
the
tools
in
the
ecosystem
or
libraries
or
frameworks
that
or
whatever
to
start
managing
all
of
these
services.
You
know
queue.
Control
is
obviously
one
of
them,
but
you
know
the
client
go
or
the
rest
api
or
web
dashboard.
A
If
it's
in
the
kubernetes
api,
it's
exposed,
you
know
in
a
uniform
way
across
all
of
our
surfaces
there.
Additionally,
we
could
start
defining
some
portable
abstractions
for
some
of
our
storage
needs
that
go
beyond
blocking
objects
or
sorry
block
and
also
containers
as
well.
So
let's
talk
about
portability,
so
portability
is
important,
I
think,
because
if
we're
running
in
multiple
environments
or
multiple
clouds
etc,
we
want
to
be
able
to
choose
which
one
of
those
clouds
are
services
that
we're
running
in
right.
A
We
want
to
take
our
data
wherever
kubernetes
goes,
and
so
I
think
that
kubernetes
did
a
really
good
job
at
two
different
abstractions.
The
pod
abstraction
and
the
volume
abstraction
so
pods
run
containers
and
that
allows
us
to
run
our
applications.
Basically
anywhere
kubernetes
runs
and
then
volumes
volumes
provide
us
with.
A
So
those
are
great
abstractions,
pods
and
volumes,
but
applications
are
more
than
just
pods
and
volumes
right.
There's
also
databases,
buckets
caches
message
queues,
you
know
AI
ml
pipelines,
all
sorts
of
stuff
right,
and
so
that's
why
I
we're
also
gonna
talk
about
and
start
showing
you
here.
Some
integration
with
rook,
as
in
this,
a
new
open
source
project
called
cross
plain
that
we
open
sourced
in
right
before
cube
con
Seattle
so
about
five
months
ago.
A
So,
let's,
let's
take
this
idea
a
little
bit
further
here,
make
it
a
little
bit
more
concrete,
so
everyone's
familiar
with
storage
classes
and
persistent
volume
claims
inside
of
kubernetes
right.
So
a
you
know
those
concepts
there
we
can
take
those
from
just
from
volumes
and
to
apply
them
to
the
other
types
of
storage.
So
generalize,
a
resource
class
similar
to
a
storage
class,
can
be
thought
of
as
a
blueprint
that
would
be
created
by
the
administrator
and
then
the
administrator.
They
know
all
the
environment
details
they
can
set
the
policy.
A
You
know
they
own
these
clusters,
so
they
can
define
these
blueprints
for
how
we
might
want
to
create
an
entire
class
of
different
types
of
storage,
your
buckets
and
databases,
etc.
Right,
for
example,
a
fast
class,
a
standard
class,
a
cheap
class
as
well,
and
then
very
similar
to
persistent
volume
claims.
We
could
do
resource
claims
general
resource
claims,
so,
instead
of
just
volumes,
we
could
do
claims
for
all
these
other
types
of
resources
that
users
can
make
to
say.
I
just
generally
need
a
Postgres
database.
Please
give
me
one
of
those
and
we
can.
A
The
application
doesn't
have
to
know
where
it's
coming
from
just
like
an
application
or
a
pod
doesn't
have
to
know
where
its
volume
is
coming
from.
A
pod
shouldn't
necessarily
have
to
know
where
its
database
is
coming
from,
and
so
through
these
classes
and
claims
just
like
storage
classes
and
persistent
volume
claims.
We
can
start
doing
that
on
demand,
not
a
design
time
or
compile
time,
but
it
on
demand
at
deployment
time.
A
Your
applications
could
get
those
resources
that
they
need
fulfilled,
and
now
this
is
what
I
think
really
does
enable
portability
across
the
different
cloud.
Environments
and
on-premises
gives
us
the
power
of
choice
and
this
whole
manager
of
right,
rolling
at
once
and
run
anywhere
can
really
start
becoming.
True
I.
Think
all
right
so
that
cross
plane
project
I
was
talking
about.
You
know
a
multi
cloud
control
plane
to
be
able
to
you
know,
extend
kubernetes
with
the
ability
to
manage
multiple
clusters.
A
Multiple
clouds
deploy
your
platform
services,
your
databases,
etc
to
any
one
of
the
cloud
providers.
Let's
talk
about
what
it
looks
like
to
integrate,
rook
with
crossplane
and
start
doing
new
interesting
scenarios
right
so
crossplane
has
some
new
functionality
where
you
can
extend
it
with
out
of
tree
functionality.
So
you
know
there's
the
main
repo
for
crossplane
and
you
know
everything
gets
compiled
in
there
and
launches
a
container
etc.
But
we
can
also
from
the
rook
project
we
can
compile
and
build
a
functionality
for
crossplane
and
then
an
extend,
install
the
crossplane
multi-cloud
control
plane.
A
That's
spanning
all
of
these
cloud
providers
with
new
functionality
such
as
rook,
and
then
that
will
give
us
the
ability
which
we'll
see
here
of
how
to
dynamically
provision
all
these
new
types
of
storage
and
the
key
here
is
since
it's
we're
using
rook
to
do
this.
Is
that
we'll
be
able
to
do
this
on
premises
as
well,
because
it's
one
thing
to
light
up
a
database
in
or
a
block
volume
or
whatever
in
a
cloud
provider,
but
it's
another
thing
entirely
to
be
able
to
do
that
on
bare
metal
right
alright.
A
So
what
we're
looking
at
here
is
just
some
yam
bolts,
saying
it's
an
extension
request.
You
please
take
the
cross,
plane,
multi-cloud
control,
plane
and
extend
it
with
rooks
cockroach
operator.
So
we
are
going
to
look
at
some
of
the
details
about
that.
So
cockroach
DB
there's,
you
know
the
brook
has
an
operator
for
cockroach
we're
gonna,
look
at
the
three
steps
of
a
traditional
operator,
the
observe
the
analyze
and
the
act
step,
but
for
this
is
for
dynamic
provisioning
of
cockroach,
which
is
implements
the
Postgres
protocol
on
the
wire.
So
here's
some
code.
A
This
is
a
deep
dive,
so
we're
getting
into
a
little
bit
of
go
lane
code
here,
not
surface
level
introductory
stuff,
but
basically
what
I'm
getting
across
in
this
slide
here
is
that
this
step
here
is
the
observed
step
of
an
operator.
So
the
important
part
is
this
line
here,
where
we
are
setting
up
a
custom
controller
for
cockroach
DB
to
watch
for
events
on
a
general
Postgres
claim.
So
when
says
I
want
Postgres
cockroach
is
gonna,
be
watching
here.
Brooks
cockroach
will
be
watching
and
ready
for
that.
A
So
the
analyze
step
in
this
reconciliation
loop
is
we
see
that
there's
a
new
request
for
Postgres
inside
of
our
local
cluster?
Here
and
we're
going
to
check
and
see,
are
we
being
deleted
and
handled
that
with
the
deletion
function?
Do
we
have
a
resource,
a
cockroach
resource
already
created?
If
we
don't
we're,
gonna
go
ahead
and
provision
it
and
after
all,
that's
done
we'll
bind
the
two
together,
the
Postgres
claim
and
the
cockroach
resource
and
here's
the
final
act
step.
A
The
observe
analyze
act
act
is
when
we
actually
provision
and
create
the
cockroach
instance
that
will
fulfill
the
request
for
Postgres.
So
we're
saying
here
we're
creating
a
cockroach,
DB
cluster
object
and
we're
calling
create
on
the
community's
API
to
kick
in
the
machinery
of
the
regular
cockroach
operator.
This
is
the
cockroach
operator
part.
The
provisions,
dynamically
provisioned
storage
and
in
the
cockroach
operator,
will
kick
in
and
bring
up
a
whole
cockroach
cluster.
A
So
let's
actually
look
at
this
thing:
let's,
let's,
let's
see
it
in
action,
all
right
and
I
doing
two
talks
in
a
row,
I
hope
I,
don't
confuse
things
so
I'm
going
to
go
back
to
this
copy
paste.
This
is
not
for
you
all.
This
is
for
me
to
copy
and
paste,
and
so
what
are
we
looking
at
here
we
are
looking
at
the
crossplane
multi-cloud
control
plane,
and
what
we
see
here
is
where
the
main
crossplane
pod
is
running.
A
We
can
point
it
at
any
of
the
cloud
providers,
but
we
can
also
point
it
locally
to
the
on-premises
bare-metal
cluster
and
bear
with
me
here
when
I
say
bare-metal.
What
I
really
mean
is
my
macbook,
but
the
concept
is
the
same
of
on-premises
no
cloud
provider
stuff
involved
here
at
all.
The
second
pod
we
have
here
is
the
extension
manager
pod
for
crossplane.
So
this
is
how
we
can
build
new
functionality
or
integrate
rook
into
this
multi
cloud
control,
plane
and
open
up
new
scenarios
with
this
extension
manager.
A
Here
all
right,
so
I'm
going
to
do
two
commands
here:
I'm
going
to
create
a
namespace
and
I'm
going
to
create
a
cockroach
extension.
So
let's
look
at
what
that
cockroach
extension
looks
like
this
should
be
familiar
because
it
was
on
a
previous
slide
if
I'm
asking
crossplane
requesting
to
extend
it
with
rook
cockroach
functionality.
So
this
is
how
we're
gonna
teach
the
multi-cloud
control
plane
a
new
rook
cockroach
trick.
So
we
applied
that
and
so
now
what
we
should
see
is.
A
We
should
be
able
to
check
on
our
extension
request
and
the
rook
cockroach
DB
package
has
been
downloaded
and
applied
to
the
cross
plane
cluster.
So
it's
ready
to
go,
and
then
we
can
get
more
details
to
about
the
the
specific
cross
plane
extension
that
it's
ready.
It's
ready
to
go
and
service
cockroach
requests.
So
another
thing
to
look
at
here
is
that
when
we
taught
this
multi
clock
control
plane
what
cockroach
and
rook
really
is
it
also
taught
it
some
new
CR
DS.
So
now
there's
a
new
CR
d4
rooks
cockroach
as
well.
A
This
didn't
exist
before,
but
now
it
does
because
we
extended
the
control
plane
with
that
and
then
now
in
addition
to
that
oops.
In
addition
to
that
CR
d4
cockroach,
we
also
created
a
cockroach
operator.
So
now
we've
got
everything
running
up
and
running
in
the
cloud
in
the
multi
clock,
control
plane
here
to
start
doing,
cockroach
stuff,
alright.
So
let's
do
cockroach
stuff,
and
oh
boy,
I
hope.
This
is
the
right
repo
compared
to
the
the
last
demo.
A
So
if
I
and
actually
when
I
was
practicing,
I
accidentally
ran
a
cube,
cotrona
helm
commands
on
the
wrong
cluster,
so
I
hope
that
did
not
mess
up
any
of
these
clusters
here.
So
we're
gonna
see
what
happens.
Okay,
so,
let's
do
first,
remember
we're
talking
about
storage
classes
and
persistent
volume
claims
right,
so
resource
classes
and
resource
claims
here.
This
should
be
very
familiar
to
what
a
storage
class
looks
like
right
now,
but
basically
we're
declaring
a
Postgres
resource
class,
and
this
is
specifically
for
a
cockroach
right.
A
So
when
somebody
asks
for
Postgres
we're
going
to
give
them
the
cockroach
local
cockroach,
rook
implementation
with
you
know
various
parameters
here
of
just
a
gig,
because
it's
tiny
like
three
node
three
replicas
count.
You
know
how
much
cash
to
use
etc,
but
basically
that's
the
blueprints
when
somebody
asks
for
Postgres
that
will
be
able
to
fulfill
that
with
and
here's
the
final
step
to
kick
off
this
whole
thing
from
end
to
end.
A
So
what
I'm
gonna
do
is
I'm
also
going
to
create
the
resource
claim.
So
here
we
go
so
the
resource
claim
is
a
general
Postgres
instance
and
I'm
saying
please
give
me
Postgres
and
use
this
resource
class
here,
please,
the
the
Postgres
resource
class
to
fulfill
that
the
administrator
has
created
a
Postgres.
A
A
It
is
the
Postgres
instance
is
bound
to
the
cockroach
instance,
just
like
dynamic
provisioning
for
volumes
all
right.
So
let's
use
the
thing.
The
cockroach
should
be
up
and
running
so
I'm
going
to
exact
to
it,
and
we
got
a
beautiful
cockroach
interface
here
where
I'm
going
to
say,
show
me
the
databases,
and
this
shows
that
we
have
a
system
database
up
in
provision.
The
three
node
cockroach
cluster
is
up
running
talking
to
each
other.
We've
got
data,
we've
got
Postgres,
we've
got,
we've
got
cockroach
so
now,
let's
start
feeding
data
into
it.
A
So
I'm
gonna
start
up
a
load
generator
program
here,
that's
targeted
at
cockroach,
and
so
this
is
gonna
spin
up
a
pod.
That's
just
going
to
keep
writing
random
data
to
the
cockroach
cluster,
and
if
we
look
at
the
logs
at
it
it's
you
know
doing
write
operations,
it's
doing
benchmarking,
it's
testing
the
the
speed
and
throughput,
and
if
we
actually
do
a
database
query,
we
can
look
at
that
data
that
it's
throwing
in
the
cockroach
right
now.
So
basically,
we
see
here
that
to
throw
it
all
together
and
wrap
it
up.
A
Here
we
asked
for
cockroach
re.
We
asked
for
Postgres
in
a
general
way
through
a
resource
class
that
was
the
administrator
specified,
that
that
should
be
cockroach
with
rook
on
a
local
cluster
and
with
the
crossplane
multi-cloud
control
plane.
We
get
all
this
put
together
so
that
our
general
resource
needs
are
now
portable
and
we
can
do
databases,
caches
object,
storage,
you
know
message
queues
all
sorts
of
stuff
in
general
ways
just
like
we
can
do
with
volumes
all
right.
So,
let's
switch
back
to
the
slides
here
and
quick
summary.
A
We
covered
that
rook
is
a
cloud
native
storage
Orchestrator.
You
should
know
that
by
now,
and
then
we
have
a
framework
here
that
it
has
enabled
new
operators
like
the
cassandra
operator
in
the
edge
FS
operator
storage
services
inside
your
kubernetes
cluster,
orchestrated
by
rook,
and
we
also
learned
how
we
can
extend
cross
planes,
multi-cloud
control
plane
with
new
functionality
to
deploy
new
types
of
resources,
in
addition
to
volumes
that
we
already
have
already
in
the
cloud
and
on-premises
rook
and
cross
the
planner,
both
open
source
projects
we
have
150
or
plus
contributors
on
rook.
A
We
want
more
always
we're
growing
the
community
I'm
really
happy
to
see
all
of
you
guys
here
and
probably
a
lot
of
you
were
at
the
intro
yesterday,
active
on
slack,
Twitter,
etc.
Please
join
us
and
we
have
a
couple
more
sessions
at
cube
con
today.
They're
all
today,
there's
a
meet
the
maintainer
session.
That
starts
in
two
minutes.
A
A
A
Yeah
so
the
question
they
think
that
boy
yeah,
the
question
was
that
there's
actually
enough
code
out
there
to
take
that
data
base
CRT
and
start
using
it
on
premises
and
on
all
across
all
the
clouds.
So
what
I
showed
here
all
the
cloud
ones
are
available,
like
those
are
your
part
of
the
cross
plane
project,
so
you
can
do
you
know
my
sequel
and
post
crest,
etc
across
Google,
Amazon
and
Azure
in
a
general
way,
but
this
local
rook
on
cluster.
Sorry
in
cluster
on-premises
functionality,
it's
still
in
a
prototype
thing.
A
Oh,
that's
yeah!
That's!
So
that's
a
great
question,
so
the
question
was
since
Brook
supports
more
than
just
Seth
now
it
supports
multiple
types
of
storage
systems
and
operators,
if
will
be
able
to
enable
out
of
tree
operators
etc
for
rook
as
well,
and
that
that's
a
good
question
because
we're
starting
actually
to
feel
the
pains
now
of
having
everything
in
tree
and
having
to
manage
releases
for
multiple
storage
systems
and
get
everyone
coordinated
and
get
the
code
out.
A
You
know
all
in
the
same
day
and
all
that
stuff
and
tying
people
storage
systems
tying
their
release,
dates
to
rook
release,
dates.
We're
feeling
the
pain
of
that
right
now
and
kubernetes
did
the
same
thing
with
all
their
entries:
storage
plugins
and
they
move
to
an
out
of
tree
model
as
well,
so
I
think
we're
kind
of
moving
towards
there.
Yet
we
haven't
done
it
yet,
but
we're
starting
to
feel
that
pain
and
that's
gonna
be
something
that
we
need
to
discuss
as
a
community
and
find
out
the
right
solution
that
works
for
everyone.
A
And
so
we
have
community
meetings,
every
Tuesday,
every
other
Tuesday
and
that's
a
great
topic
that
we'd
be
able
to
talk
about
there.
So
oh
yeah,
yeah,
so
yeah
there
is
local
PBS
support.
So
in
the
rook
framework
you
can
specify
you
know
what
storage
you
want
to
to
be
involved
in
the
cluster,
and
so
you
can
there's
all
different
types
of
ways
to
pick
and
choose
that
class.
That's
storage
and
one
of
them
is
persistent
volumes
or
local
PBS
as
well.
A
Yeah,
so
the
question
is:
how
do
these
operators
work
with
cloud
and
local
and
ephemeral?
Nvme
storage?
So
you
know
we
wrote
a
blog
post,
maybe
a
year
or
so
ago,
about
running
rook
in
an
Amazon
with
a
a
situ
instance
using
instant
storage
which
is
locally
attached,
SSD
drives
and
the
performance
benefits
you
get
from
it.
The
cost
benefits
there
was
actually
a
pretty
compelling
story.
Where
you
got
really
good
throughput.
You
got
really
really
good
cost
as
well,
and
it
was,
you
know,
compared
very
nicely
to
what
you
get
an
EBS.
A
You
can
suck
that
up
into
the
cluster
tank
and
include
that
the
question
where
it
gets
kind
of
interesting,
though,
is
that
in
the
cloud
for
use
the
EBS,
you
know,
you've
got
a
whole
team
of
engineers
in
Amazon.
That's
managing
it
there's
an
SLA,
maybe
EBS
isn't
the
best
example,
because
I
think
everyone
has
their
own
abs
horror
story,
but
you
know
then
general
you've
got
a
whole
team
managing
it.
A
When
you're
running
your
own
rook
cluster
inside
the
cloud
provider,
definitely
you
can
do
it
and
you
get
good
results,
but
still,
at
the
end
of
the
day,
it's
your
responsibility,
you're,
managing
that
cluster.
You
have
to
be
on
point
and
on-call
for
making
sure
it's
working.
So
that's
the
trade-off
cool.
Thank
you.
I
get
going
down
to
the
CN
CF
answer
bar
now,.