►
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
Adding a New Storage Provider to Rook - Jared Watts, Upbound
The CNCF hosted Rook project has built a framework for running stateful workloads on Kubernetes, enabling storage providers to seamlessly and effectively integrate into cloud native environments. This framework is already being used to support multiple storage providers such as Ceph, CockroachDB, Minio and NFS. In this talk, Jared will walk through how new storage providers can also take advantage of this framework to easily and reliably run on Kubernetes. He will also cover the benefits that Rook provides to make this transition to cloud native environments easier for new storage providers. Finally, the important architecture, design, and concepts for running storage solutions on Kubernetes will be explored in detail.
To learn more: https://sched.co/Grb1
A
All
right
we're
gonna
go
ahead
and
get
started
here.
Sorry
for
the
late
start.
We
got
a
bit
of
a
late
transition
going
here,
but
let's
get
going
then
alright,
so
I'm
going
to
talk
about
adding
a
new
storage
provider
to
rook
and
what
that
looks
like
and
some
of
the
implications
of
that
my
name
is
Jared
watts.
I
am
a
rook
senior,
maintainer
and
I'm
also
one
of
the
founding
engineers
at
upbound.
So
we
are
going
to
jump
in
here
now.
A
This
is
a
I
think
this
is
the
very
last
session
of
the
very
last
day
of
this
conference.
So
it's
always
a
good
to
see
anybody
who
sticks
around
for
that
I
saw
one
of
my
really
good,
a
guy
that
I
used
to
work
with
the
last
job.
I
really
liked
him
and
I
thought
he
really
liked
me,
but
I
told
him
that
I
was
presenting
at
4:30
today,
he's
like
I'll
catch
on
YouTube,
so
you
guys
are
here.
I
know
who
my
real
friends
are
now
all
right.
A
So
I
spoken
about
rook
already
this
week,
as
did
the
introduction
to
the
rook
project
a
couple
days
ago
and
Travis
Neilson,
one
of
the
other
maintainer
zone.
The
rook
project
spoke
about
rook
earlier
this
earlier
today
and
we
had
a
little
session
at
the
CN
CF
s
meet
the
maintainer
z--
booth
earlier
today
too.
A
So
there's
been
a
whole
lot
of
rook
and
you,
you
know
I'm
sure
a
lot
of
you
have
already
heard
about
it,
but
we're
just
going
to
do
a
little
bit
of
level
setting
here
so
we're
all
on
the
same
page.
So
what
is
rook
so
Brooke
is
a
cloud
native
storage
Orchestrator,
and
what
that
means
is
that
we've
taken
kubernetes,
we've
extended
it
with
some
custom
types,
custom
controllers
and
those
are
specifically
geared
towards
storage
and
how
to
manage
storage.
A
So
it's
there's
some
automation,
software
logic
around
deploying
bootstrapping
configuring
scaling
migrating
disaster
recovery,
all
sorts
of
stuff
force,
complicated,
distributed
storage
systems,
bringing
them
into
kubernetes
and
helping
them
run
well
there.
So
rick
is
also
it's
got
a
framework
now
for
adding
or
integrating
other
storage
solutions
into
kubernetes
as
well,
and
that's
going
to
really
be
the
focus
of
this
talk
today
and
what
that
looks
like
and
the
rook
project.
A
That's
open
source,
the
Apache
2.0
license
and
it
is
hosted
donated
it
to
the
cloud
native
computing
found
a
we
did
that
the
beginning
of
this
year,
so
that
was
January
and
at
the
sandbox
level
and
just
back
in
I,
think
it
was
September
or
August.
We
were
graduated
to
the
incubation
level,
all
right.
So
let's
talk
about
some
of
the
challenges:
running
storage.
So
really
what
you've
seen
for
a
while
with
kubernetes
there's
this
reliance
on
external
storage
or
storage
solutions
or
systems
that
are
outside
of
your
cluster.
A
So
that
requires
that
those
those
systems
are,
you
know,
created,
managed,
accessible,
there's
a
burden
associated
with
those
right.
Somebody's
got
to
do
that
for
you
and
then
you
could
also
take
a
take
advantage
of
cloud
provider
managed
services
you
know
like.
If
you
need
block
storage,
you
can
use
Amazon's,
EBS
or
Google
persistent
disk
and
those
services
are
great.
They
come
with
a
you
know,
an
SLA.
They
come
with
a
full
team,
that's
managing
it
for
you,
so
they're
good.
A
But
if
you
take
some
of
those
services
they
have,
you
know
you
can
get
yourself
into
a
situation
with
that
dependency
on
that
service
and
making
it
difficult
to
move
somewhere
else,
and
you
get
stuck
with
that
vendor
to
spender
lock
in
another
problem
is
with
storage
is
day
two
right.
There
was
a
whole
talk
on
this
that
I.
It
was
a
panel
that
I
moderated
on
Monday.
At
the
cloud
native
storage
day,
where
you
know
day,
one
is
cool.
You
get
your
storage
all
set
up.
A
It's
running
everything
looks
like
it's
working
good,
but
then
you've
got
day.
2
3
4
in
you
know
where
all
sorts
of
disaster
can
happen.
So
somebody's
got
to
manage
your
storage
for
you.
So
let's
talk
about
a
couple
of
solutions
for
those
one
of
them
is
that
you
know
kubernetes
pretty
good
at
managing
the
lifecycle
of
complicated
cost
software
solutions.
So
maybe
we
can
bring
our
storage
systems
inside
of
kubernetes
and
harness
that
power
of
kubernetes
to
manage
some
of
these
components
for
us.
A
So
with
you
know
some
smarts,
an
automation
that
we
can
put
into
software.
Maybe
we
can
do
some
of
that
operations
day
to
operation
stuff
for
you
that
deployment
burden
for
you.
Let's,
let's
offer
to
do
it.
That's
a
lot
easier.
Another
thing
to
deal
with
that
vendor
locking
problem
we're
talking
about
is
you
know.
Maybe
we
should
create
some
portable
abstractions
for
all
of
our
storage
needs,
not
just
block
and
file,
and
so
let's
talk
about
why
that
specifically
is
important,
so
the
power
of
portability.
A
For
me
that
comes
down
to
the
power
of
choice.
Actually,
so
if
you
take
your
application
and
you
can
it's
truly
portable
that
all
of
its
dependencies,
all
of
the
you
know-
resource
requirements,
everything
that
that
application
needs
to
run?
If
you
can
take
those
and
run
them
anywhere,
then
mute
now,
you
have
choice
right.
You
can
choose
to
run
in
one
cloud
provider
because
it's
the
cheapest
cost
or
you
can
choose
to
run
in
another
cloud
provider
or
on-premises
because
of
other
things
like
feature:
geographic
presence,
availability,
durability,
compliance,
all
sorts
of
stuff.
A
But
the
point
is
you
can
have
a
choice,
and
so
what
does
it
look
like
to
start
taking
our
data
wherever
kubernetes
goes
so
kubernetes?
You
know
you
say
you
know
portability.
A
lot
of
people
think
so
far
as
kubernetes
is
done,
a
great
job
with
that
which
absolutely
has,
but
that's
for
pods
and
volumes
right.
So
you
can
abstract
an
application
to
a
pod,
and
it's
in
containers
that
are
gonna
run
in
a
pod
and
its
data
needs
for
a
volume.
Those
are
very
good
abstractions.
A
They
go
along
a
long
way,
but
there's
some
things
that
your
application
might
need
to
use.
They
don't
fit
into
those
categories.
What
about
you
know,
message:
queues
or
our
object?
Storage,
databases,
data
pipelines,
all
sorts
of
other
things
that
we
don't
have
good
abstractions
for
right
now,
and
that
makes
our
applications
very
difficult
to
be
portable.
You
can't
just
take
a
dependency
on
some
of
Amazon
services
and
then
just
move
to
Google
very
easily.
That's
it's!
You
know.
A
You're
kind
of
you
have
that
bit
of
that
gravity
there
so
there's
also
a
new
project,
a
new
open
source
project
that
is
just
over
a
week
old.
Now
we
open
sourced
it
last
week,
so
it's
still
very
new
and
it's
called
crossplane
and
together
with
crossplane
working
together
with
rook,
we
can
start
solving
some
of
these
problems
about
having
portable
applications
that
can
run
anywhere
in
the
cloud
and
also
on
premises
as
well,
and
that's
going
to
be
the
demo
we're
gonna
look
at
later
on
today,
all
right!
A
So
let's
talk
about
a
few
of
the
foundational
knowledge
that
we
need
to
start
talking
about.
How
do
you
add
a
storage
provider
to
rook?
And
what
does
that
look
like?
So
we
talked
to
this
in
a
couple
of
other
talks,
and
people
are
starting
to
see
RDS
becoming
a
pretty
common
expression
now,
so
we
won't
spend
too
much
time
on
it,
but
basically,
with
the
custom
resource
definition,
you
can
teach
kubernetes
about
new
types.
A
You
can
declare
your
own
custom
types
and
they
become
first-class
citizens
and
the
Cabrini's
experience
too
so,
just
like
pods
and
config
maps
and
secrets,
and
such
your
arbitrary
custom
types
can
start
being
displayed
and
used
and
manipulated
within
the
kubernetes
api
and
cube
control,
just
like
any
other
of
the
first-class
or
built-in
objects.
Excuse
me
and
now,
operators
as
well,
so
operators
are
a
very
useful
software
pattern
that
we
found
and
we're
starting
to
see
those
pop
up
all
over
the
place
to
manage
complicated
software
solutions.
A
So
the
first
time
I
heard
about
this
pattern,
I
think
was
from
core
OS
a
couple
years
ago.
I
think
that
they
had
a
blog
post
that
really
defined
what
this
operator
pattern
is,
and
so
you
know
wouldn't
allows
you
to
do.
Is
it
allows
you,
a
user
to
define
their
desired
state
of
what
you
want
the
application
to
do,
and
then
the
operator
looks
at
that
desired
state
and
takes
care
of
everything
else
for
you.
So
it
does
that
in
three
steps.
A
One
of
them
is
its
first
got
to
know
what
this
system
is
doing
and
actually
you
know
in
reality.
It's
got
observe
the
system
see:
what's
there
analyze,
what
the
difference
between
what
the
user
is
asked
for
their
desired
state
and
what
the
actual
system
is
doing,
make
a
comparison
there
and
figure
out
what
to
do
what
to
act.
What
operations
to
perform
to
drive
that
system
towards
what
the
users
a
desired
state
actually
is.
So
there's
a
couple
different
ways
to
write
operators.
A
A
But
these
take
that
idea
a
little
bit
further
and
provide
a
lot
of
generated
code
for
you
and
basically,
we
make
takes
the
job
as
a
developer
of
writing
an
operator
and
takes
away
some
of
that
manual
work
and
makes
it
easier
for
you
to
write
reliable
operators
to
manage
other
software
systems.
So
we'll
see
a
little
bit
of
examples
from
a
couple
of
those
actually,
okay,
so
back
to
rook.
A
So,
as
we
said
before,
you
can
think
of
rook
as
a
framework
for
managing
you
know
other
storage
systems
and
deploying
them
contributing
configuring
them
bootstrapping
and
lot
sort
of
stuff
and
making
that
job
easier.
So
this
framework
here
that
allows
a
storage
systems
to
do
that,
there's
a
couple
of
a
couple
different
facets
or
areas
that
it
enables
to
make
that
job
easier.
So
one
of
them
is
that
it
provides
a
storage
resource
and
normalization.
A
So
what
that
means
is
that
it
provides
a
common
language,
a
common
way
to
describe
how
or
what
storage
resources
in
your
cluster
should
be
included
in
the
storage
system
like,
for
example,
this
node,
and
not
that
node
nodes
with
this
label
selectors,
you
know
specific
devices,
you
know
SDA
on
node
4,
whatever
it
may
be.
It
provides
a
common
way
to
describe
that
and
then
create
a
storage
fabric
out
of
those
and
it's
kind
of
like
we
were
talking
about
with
the
operator
frameworks.
A
A
You
know
specific
storage
systems,
and
you
know,
policies
and
specs
and
logic,
reusable
stuff,
that
kind
of
helps
and
makes
it
easier
for
storage
systems
to
do
their
job
and
make
sure
that
their
storage
is
performing
well
inside
of
kubernetes,
and
we
also
have
you
know
in
the
brook
project
integration
pipeline
that
will
you
know
test
all
your
your
storage
systems
and
the
code
on
a
whole
matrix
of
kubernetes
deployments
and
cloud
providers
and
such
so.
It
makes
you
know
it
makes
the
job
of
if
you
want
to
bring
your
storage
into
kubernetes.
A
A
So
I
know
that
one
that
was
0.94
cubed
on
Seattle
and
we
added
in
FS,
Cassandra
and
next
sent
to
edge
of
s2,
and
so
the
interesting
thing
that
I
really
wanted
to
call
out
here
is
that
this
is
a
community
driven
project.
You
know
the
first
couple
of
storage
systems
we
serve
were
supporting.
Is
you
know,
specialist
F
that
was
done
by
the
core
contributors
of
the
Brooke
project,
but
with
this
framework
now,
we've
enabled
a
whole
bunch
of
new
contributors
to
start
adding
more
storage
into
rook
and
into
kubernetes
there.
A
You
know
as
well.
The
storage
seems
themselves
the
ones
that
are
the
experts
on
those
storage
systems
and
know
how
to
run
them
best.
We've
enabled
them
to
start
writing
some
of
this
code
to
bring
them
into
kubernetes.
So
I
wanted
to
call
specifically
Yanis
Sark
Odyssey.
Is
he
works
at
arc,
though?
And
he
lives
in
Greece,
and
he
just
did
that
he
did
single-handedly
the
Cassandra
Apache
Cassandra
operator
and
the
amount
of
functionality
that
he
put
into
that
before
it
even
got
into
master
branch
was
impeccable,
so
that
guy
is
amazing.
A
He
did
a
great
job.
Rohan
Gupta
did
he
was
a
google
Summer
of
Code
mentee
for
us.
So
through
that
project
there
he
got
to
work
on
enabling
a
network
file
system,
storage
and
rook,
and
then
the
hold
Nick
sent
a
team.
You
know
there
have
been
enabled
to
the
wreck
Brook
framework
to
bring
in
their
edge
FS.
You
know
filesystem
project,
where
storage
solution
alright.
So
let's
start
looking
at
a
little
bit
of
code
here
and
then
we're
gonna
get
into
a
demo
and
I
will
not
go
over
time.
A
I
promise
you
so
you
can
get
out
of
here
and
go
to
your
holiday
parties
or
whatever
you
need
to
do
so.
Okay.
So
this
right
here
is
a
custom
resource
definition.
This
is
what
tells
kubernetes
that
you
have.
A
new
type
is
a
type
that
represents
object,
storage
and
Mineo,
and
it
gives
it
the
name
and
some
of
this
metadata
that
you
can
then
that's
necessary
to
start,
manipulating
it
and
showing
up
and
cube
control
and
all
sorts
of
stuff.
A
So
the
API
server
will
know
what
am
in
IO
object
store
is,
after
you
create
this
custom
resource
definition.
Now.
This
is
an
example
of
creating
an
instance
of
that
object,
storage
type
that
we
just
declared.
So
this
is
a
very
contrived
or
very
simple
example.
Where
we're
basically
saying
this
is:
please
give
me
an
object,
store
created
by
manao
and
give
me
you
know,
spread
it
across
four
nodes,
so
very
simple,
but
this
is
a
way
to
you.
You
can
use
cube
control.
A
So
this
sort
of
what
the
experience
looks
like
you
know
we
did
a
cube,
control
create
on
that
object,
store
MO,
and
then
we
can
say
you
know,
give
me
the
CR
DS,
and
these
are
the
types
of
the
API
server
nodes.
But
it
knows
what
Mineo
is
you
know
we
can
create
the
actual
instance
of
that
object,
store
and
do
a
cube
control
get
and
we
can
see
that
objects
store
come
back,
so
the
API
server
knows
exactly
what
it
is.
A
That
means
that
our
operators
will
be
able
to
see
that
somebody
has
asked
for
a
new
instance
of
manao
object,
storage
and
it
can
start
working
on
it.
So,
let's
take
a
little
bit
of
more
of
a
look
on
what
the
what's
the
more
like
complicated
specs
look
like,
and
we
looked
at
a
very
contrived
example
at
first,
but
so
right
here.
This
is
how
you
start
declaring
a
little
bit
more
configuration
about
your
storage
system.
A
What's
the
important
things
that
you
that
the
operator
would
need
to
know
in
order
to
make
that
storage
system
the
way
that
you
want
it
to
happen,
so
we
can
see
here
in
the
red
box
there
that
all
those
things
that
are
certain
circled
the
square,
all
those
things
that
are
squared
are
are
the
configuration
properties
that
come
from
that
common
rook
framework.
So
you
know
the
manao
team
didn't
have
to
write
any
of
that
logic
or
spec,
or
information
configuration
stuff
that
just
comes
out
of
the
Brooke
framework.
A
So
all
they
needed
to
do
was
add
the
part
at
the
bottom
about
the
access
keys
for
accessing
the
s3
protocol,
buckets
that
manao
object,
storage
creates
and
that's
all
that
they
really
had
to
add
there
so
the
manao
operator.
So
for
each
one
of
the
storage
systems
in
rook,
you
have
to
you'll
write
your
own
operator
for
it
as
well.
A
That
knows,
you
know
we'll
be
looking
for
events
of
when
the
user
has
decided
to
create
an
instance
of
your
type
of
storage,
and
then
it
will
start
doing
that
work
to
turn
that
request
from
the
user
into
an
actual
functioning
storage
system.
It's
really
what
we're
seeing
here
is
that
we're
just
wrapping
this
in
our
deployment
and
we
are
running
we're
telling
it
to
run
the
rook
manao
operator.
So
that's
not
too
much
complicated
in
here.
But
the
point
is
that
you'll
be
running
a
specific
operator
for
your
specific
type
of
storage
and
building.
A
That
can
be
pretty
easy
because
you
can
normally
what
ends
up
happening
is
it
will
take
the
upstream
container
image
for
your
storage
for
that
storage
system
so
from
upstream
video
and
we're
just
gonna
slap
the
real
binary
in
there
and
then
that
turns
it
into
basically
a
container
image.
That
is,
you
know
an
operator.
They
can
start
working
on
the
storage
system,
this
one's
a
pretty
optimized
system,
because
it's
based
the
base
image
is
Alpine
Linux.
A
So
it's
tends
to
be
really
small
when
you
just
throw
in
the
the
rook,
you
know,
statically
compiled
go
binary,
so
it
ends
up
being
pretty
slim.
Okay,
so
we
saw
any
animal
with.
You
know
that
you
can
specify
or
declare
that
you
want
a
mini,
Oh
object,
storage
with
these
this
this
and
this
configuration
properties.
So
that's
got
to
be
backed
up,
and
you
know
if
you're
gonna
do
anything
programmatic,
you
know
you
have
to
back
it
up
with
some
code
somewhere
right.
A
So
this
is
what
the
going
code
looks
like
for
the
defines
what
an
a
mini
object,
storage,
type
IRS's
custom
resource
looks
like,
and
so
we
see
here
once
again
that
all
these
types
are
that
are
in
the
square.
There
are
coming
from
the
common
rook
framework.
This
is
how
I
want
to
or
I
want,
the
ability
to
specify
what
storage
to
include
I
want
the
ability
to
specify
what
resources
should
be
limited
and
constrained
such
as
CPU
and
memory.
I
want
to
be
able
to
specify
some
networking
configuration.
A
How
should
it
use
the
network
and
the
cluster
that
it's
being
deployed
to
and
then
outside
of
that
square?
We
have
their
little
credentials
configuration
that's
specific
to
manao.
It's
not
necessarily
a
common
thing
across
all
storage
providers
that
gets
added
in
there,
so
the
user
configure
could
configure
that
as
well
all
right,
so
the
operator,
the
mini
operators,
got
to
start
doing
something
useful.
A
So
what
it
needs
to
do
is
it's
got
to
set
up
a
watcher
for
getting
that
will
get
us
events
for
ads
and
updates
and
deletes
when
a
user
wants
to
manipulate
the
Mineo
object.
Storage
system,
so
this
you
know,
will
set
up
some
event:
handlers
that
go
through
the
Brooks
rook's
operator
kit
and
what
they
do
is
there'll.
Listen.
A
You
know
subscribe
to
events
on
the
kubernetes
api
server
and
do
that
in
a
smart
way
with
you
know,
informers
and
Asha's
and
and
some
of
those
more
advanced
concepts
that
allow
that
basically
prevent
the
kubernetes
api
server
from
getting
overwhelmed
with
a
bunch
of
gifts.
You
know
if
we
were
to
sit
there
and
say
hey:
do
you
have
any
changes?
If
you
have
any
changes,
you
have
any
changes
over
and
over
again
that
would
be.
You
know
a
dumb
use
of
resources
of
the
kubernetes
api
server.
A
So
this
is:
does
this
an
intelligent
way
where
it'll
get
a
Vince?
It's
more
of
a
push
model
of?
When
you
know
somebody's
created
a
object,
storage
CRD
with
the
kubernetes
api
server
will
just
get
an
event.
This
kind
of
gets
into
a
little
bit
more
of
those
details.
There
of
you
know
using
an
informer
underneath
an
informer
in
a
cache
that
you
know
does
in
a
smart
way,
a
getting
information
from
the
api
server
without
excessively
pulling
doing
a
bunch
of
gits
all
right
and
then
we're
gonna
near
the
end
of
this
video
example.
A
So
you
know
for
your
operator
to
handle
your
storage
system.
You've
got
to
write
a
couple
of
handlers
here,
like
on
add-on,
update
on
delete,
and
so
this
is
here.
Focus
is
on
when
the
Mineo
operator
sees
that
the
user
has
asked
you
to
add
video
object,
storage
to
your
cluster.
It
will
go
through
programmatically,
some
of
the
steps
to
make
that
happen,
so
it
will
create
a
headless
service,
which
is
you
know,
a
great
service
object.
A
It'll
create
a
stateful
set
to
backup
the
the
object
storage
that
many
o
is
going
to
span
across
the
multiple
nodes
that
it
cares
about,
and
it's
going
to
create
a
service
object
that
people
that
clients
will
be
able
to
connect
to.
So
this
is
all
done.
Programmatically
using
the
kubernetes
api
and
the
client
go
library,
and
then,
similarly,
we
don't
have
any
body
of
code.
In
here,
but
on
an
update,
we
get
the
old
object
and
the
new
objects.
A
We
can
do
a
diff
and
see
what
changes
the
operators
got
to
do
to
make
that
the
users
request
to
actually
be
a
reality
and
reflect
it
in
the
cluster,
all
right.
So
now,
some
new
stuff
here
that
nobody
has
seen
before
I
finished
these
slides
in
the
code
and
the
demo
I'm
about
to
give
somewhere
sometime
after
midnight
last
night.
So
it
wasn't
finished
yesterday.
It
was
actually
finished
today.
So
this
is
brand
new.
A
What
you
had
to
do
is
you
had
administrator,
would
have
to
create
manually,
create
persistent
volumes
and
I'd
like
kind
of
registered
them
in
a
big
pool,
and
so
when
an
application
or
a
pod
needed
storage,
it
would
pull
one
from
that
pool
when
all
those
persistent
volumes
that
the
demand
that
the
user
had
manually
created
when
there,
when
you
run
out
well
you're
out
of
volumes-
and
you
can't
you
got
to
go
crow
manually,
create
more.
It
involves
the
administrator
right,
and
so
they
came
up
with
this
abstraction.
A
This
concept
of
storage
classes
and
persistent,
clean
volumes,
and
so
now
I'm
going
to
pause
it
here
that
that
pattern
is
incredibly
useful
for
other
types
of
storage
as
well,
not
just
volumes,
so
this
can
be
generalized
to
abstract
types
of
resources.
So
we
have
here
in
the
cross
plane
projects
what
we
call
resource
classes
and
resource
claims
very
similar
to
storage
classes
and
persistent
volume
claims.
A
But
this
is
now
something
you
can
use
to
all
sorts
of
tight
types
of
resources,
databases,
message
queues,
you
know
buckets
all
sorts
of
stuff,
so
a
resource
classes
of
blueprint
that
the
admin
creates,
that
kind
of
specifies
how
storage
should
be
created
in
an
environment
and
that
the
the
specific
details
about
it.
You
know
all
sorts
of
you-
know,
environments,
details
and
specifics.
A
resource
claim,
though
that's
the
developer.
It's
kind
of
an
abstraction
of
the
developer
gets
to
specify
a
general
need
for
storage.
A
They
don't
have
to
worry
about
the
specifics
of
what
environment
they'll
be
running
in
you
know,
with
dynamic
provisioning,
when
the
storage
is
needed,
it's
created,
the
administrator
doesn't
have
to
manually,
create
create
that
for
you
ahead
of
time
no
pre
allocation,
and
so
this
gets
back
to
portability
that
we're
talking
about.
If
you
can
write
an
app
that
you
don't
have
to
care
about
the
details
of
how
the
its
resources
are
going
to
be
provided
to
you
at
runtime,
you
can
write
that
up
in
one
way
right
at
once,
run
it
anywhere.
A
I'm
gonna
get
started
on
the
demo,
actually
I
think
so
we
can
kick
that
off
and
maybe
we'll
come
back
to
these
thighs
all
right.
So
this
is
my
cheat
sheet
here.
This
is
not
necessarily
meant
to
be
seen
and
I'm
gonna
kick
this
off
cut
and
to
tell
you
what
I'm
doing,
because
this
one
runs
a
little
bit,
because
this
is
doing
some
cloud
operations.
A
Okay,
okay,
so
let's
take
a
look
here
at
some
of
these
concepts.
I
was
talking
about
so
this
year.
What
we're
looking
at
is
a
workload.
This
is.
This
is
just
a
general
example.
This
is
not
a
specific
application,
but
it's
conceptual.
So
what
we're
looking
at
here
is
a
workload.
That's
going
to
run
in
the
cloud
in
a
workload
that's
going
to
run
locally
on-premises.
Now
they
look
really
similar
right.
There's
they're
basically
line
for
line
the
exact
same
of
specifying
a
resource
of
Postgres
I
need
Postgres.
A
Just
give
me
Postgres,
please
and
then
inside
the
app
being
able
to
extract
out
that
connection
information
from
the
Postgres
instance
they're
about
like
the
user.
The
end
points
made
Oh
deleted.
Some
things
have
been
supposed
to,
but
yeah.
So
getting
the
you
know
the
end
point
connection
information,
user
information,
password
information,
but
basically
the
point
is
here
that
your
applications
written
in
one
way
and
it's
going
to
be
able
to
run
in
any
of
the
cloud
providers,
Amazon
Google
as
your
digital
ocean
whatever,
and
it
also
run
on
premises
with
rook
2.
A
If
we
look
at
the
resource
claim
that
I
was
talking
about
this
is
it's
it's
they're
the
same
there
they're
saying
a
general
need
for
a
Postgres
database
and
a
specific
resource
class
to
use
the
one
on
the
left.
The
one
that
we
want
to
go
to
the
cloud
is
using
a
resource
class.
That's
called
cloud
Postgres
and
the
one
on
the
right,
that's
going
to
use
rook
is
is
called
local
Postgres.
A
These
are
all
the
same:
the
user,
the
application
author,
doesn't
have
to
know
the
details
about
where
this
Postgres
is
going
to
come
from
now
here
now.
This
is
what
the
administrator
deals
with
these
resource
classes
very
similar
to
storage
classes
for
volumes.
Now
this
is
where
the
details
become
apparent,
and
this
is
the
separation
of
concerns
we're
talking
about
where
the
administrator
has
to
care
about
this,
but
the
application
author,
the
developer,
does
not
so
on
the
Left
we
we're
going
to.
This
is
specifying
for
this
Postgres
instance
they're.
A
A
Do
it
with
cockroach
and
use
rook
to
dynamically
provision
me
a
cockroach
DB
closed
clustered
that
will
serve
as
Postgres,
so
our
workload,
our
application,
it's
all
it
said,
was
give
me
Postgres
that
could
be
cockroach
DB
locally
on
premises
with
rook
or
that
could
be
cloud
sequel
in
Google
or
it
could
be
Amazon
RDS
or
it
could
be
Asher's
Postgres
server
as
well
doesn't
matter
application
doesn't
care
okay,
so
hopefully
I
gave
cloud
sequel
enough
time
to
get
get
going.
So
we
created
cloud
sequel.
A
Let's
look
at
actually
at
some
of
the
details
of
what
I
did
so
when
I
first
did
here-
and
this
is
some
ugly
said-
I
recognize
that,
but
this
was
injecting
my
credentials.
My
Google
service
account
credentials
from
a
secret
or
sorry
from
a
file
into
a
secret
so
that
when
it
comes
time
to
provision
that
cloud
sequel
database
using
crossplane,
it
will
have
the
print.
You
know
my
credentials
to
perform
that
operation
with
my
account,
and
then
we
created
that
resource
class
that
we
had
there.
A
That
says,
when
somebody
wants
a
Postgres
instance,
you
use
this
information
to
creating
with
cloud
sequel
in
google
and
that
resource
claimed.
That
was
saying.
Okay,
this
is
what
a
Postgres
database,
which
which
specific
class
to
use
in
a
cloud
environment
all
right.
So
that
should
be
running
and
let's
do
the
same
thing
here
for.
A
A
A
It's
clear
some
space
on
the
screen
awesome,
so
they're
all
done
so
in
this
command.
We're
basically
saying
please
give
me
Q
control.
Give
me
the
the
resource
claims
for
the
general
need
for
Postgres
database,
and
we
can
see
here
that
that
general
cloud
Postgres
database
exists,
it's
running
version
9.6
and
then
the
local
Postgres
database
is
also
running
here
and
now
note
they're
bound.
That's
the
same
concept
that
you
see
with
persistent
volumes
and
persistent
volume
claims.
So
what
are
they
bound
to
they're
bound
to
the
the
resource?
A
Sorry,
the
sorry,
the
resources
that
were
dynamically
provisioned
from
these
resource
claims
these
resource
classes.
So
we
see
here
this
one
is
a
cloud
sequel
instance
that's
running
at
Google
and
this
one
is
a
cockroach
instance
that's
running
locally
on
our
using
rook
on
our
local
cluster.
So,
let's
see
if
cool.
So
this
is
in
the
Google
Cloud
console
and
we
could
see
here
that
that's
database
was
dynamically
provisioned
and
created.
Inside
of
you
know
the
Google
cloud
platform
on
demand
force
as
well
and,
let's
take
a
look
see
at
the.
A
A
All
right,
so
as
we
as
we
were
talking
about
here
that
you
know
rook
is
a
cloud
native
storage
Orchestrator
and
it
has
a
framework
to
allow
new
types
of
storage
to
come
inside.
Kubernetes.
You
know
running
that
storage
inside
of
kubernetes
is,
can
be
a
great
idea
with
operators
to
make
them
reliable
and
do
day2
operations
and
provide
storage
right
next
to
your
applications
that
need
to
consume
that
storage.
A
And
then
your
the
thing
that's
really
new
here
is
this
concept
of
dynamically
provisioning,
on-the-fly,
new
types
of
storage,
like
databases
and
message,
queues,
etc
in
a
very
abstract
and
portable
way,
so
that
send
you
know
that
integration
between
the
Brooke
project
here,
the
local,
the
new
types
of
storage
that
rook's
providing
and
that
are
the
new
crossplane
project.
It
allows
you
basically
to
run
your
applications
anywhere
and
not
have
to
change
them
at
all.
A
Okay,
then
you
know
that
ability
there.
It
gives
us
portability
right
the
power
of
choice,
so
you
can
start
choosing
where
you
want
to
run
your
applications
based
on
cost
or
features.
Or
you
know,
geographic
region,
compliance
all
that
sort
of
stuff,
and
that's
we've
not
been
able
to
do
that
before.
So
that's
something
that
is
brand-new.
That
I
think
is
you
know.
Kubernetes
did
a
great
job,
starting
with
with
pods
and
volumes,
but
we're
taking
it
further
now
with
all
sorts
of
different
types
of
storage
with
crossplane
and
rook.
A
So
if
you
want
to
get
involved
in
the
projects,
you
know
Brooke
that
IO
and
cross-play
know
you
can
go
to
those
websites,
and
you
know:
github
they're,
open
source
projects,
we're
always
accepting
new
contributors.
I
think
the
rook
project
has
over
100
contributors
now.
So
we're
really
happy
about
that.
But
we
want
to
keep
it
going
slack
same
thing
and
Twitter
also
talked
to
us
all
all
bats
and
I
think
we
have
maybe
a
minute
or
two
for
questions,
but
basically
that's
it.
Thank
you
very
much
guys
I
appreciate
it.
A
Yeah,
so
the
question
was
about
the
integration
test
and
the
test
Suites
of
a
test
framework
for
new
storage
providers,
so
yeah.
When
you
know
we
have
that
set
of
integration,
tests,
you're
running
on
a
drink
in
the
public
Jenkins
server
and
when
a
every
pull
request
or
every
commit
to
master
or
the
release
branches.
When,
in
response
that
the
Jenkins
server
will
start
up
in
it
will
start
provisioning
kubernetes
instances.
So
it'll
do
like
a
one
diet.
A
You
have
a
put
Travis's
as
a
another
maintainer
here
I
think
he
has
a
pull
request
to
remove
1.8
and
1.9,
but
they
could
right
now.
It's
kubernetes
1.8
went
at
9
all
the
way
through
1.13
and
on
Amazon
and
Google
Cloud
as
well,
so
it'll
spin,
those
up
for
you
and
then
it'll
run
that
full
suite
of
integration
tests
for
all
the
storage
providers
on
those
kubernetes
clusters
that
it
had
brought
up
specifically
for
those
tests.
So
you
can
start
doing
things
like
you
know,
create
your
an
instance
of
your
operator
for
your.
A
You
know
your
new
storage
type
that
you
that
you've
defined
and
then
start
creating
a
you
know.
A
custom
resource
for
that
operator
so
that
your
operator
that
we
Brooke
has
deployed
out
to
that
this
kubernetes
clusters
and
different
versions
that
we
deployed
you
know
and
run
that
for
you
and
then
create
your
storage
from
the
available
resources
in
those
criminales
clusters.
And
then
you
can
write
some
test.
A
Cases
like
you
know,
can
I
find
the
endpoint
and
connect
to
it
and
create
a
file
or
delete
a
file
and
start
doing
some
of
those
test
cases
that
are
specific
to
your
type
of
storage,
but
that
framework
for
bringing
up
kubernetes
installing
your
operator,
your
specific
type
of
storage
and
getting
it
ready
for
you
to
start
poking
with
tests
is
all
common
stuff
yeah.
So
that
is
all
the
time
we
have.
So
thanks
guys
have
a
great
rest
of
the
week.