►
From YouTube: The Open Service Broker API and the Kubernetes Service Catalog [B] - Paul Morie & Chip Childers
Description
The Open Service Broker API and the Kubernetes Service Catalog [B] - Paul Morie, Red Hat & Chip Childers, Cloud Foundry Foundation
The next frontier for Kubernetes is allowing seamless integration with the vast array of service brokers available in the microservice-based software ecosystem via a service catalog. The Open Service Broker API is an industry standard that allows service operators to integrate with multiple platforms using a single API specification.
In this session, you’ll learn exactly what the Open Service Broker API specification is, its history, how the cross-ecosystem collaboration on the API specification is happening and especially how the Kubernetes ecosystem is building integrations with this specification via the service catalog project. We’ll briefly talk about how to get involved in the Kubernetes Special Interest Group (SIG), and if the audience behaves, we’ll even do a demo!
About Chip Childers
A proven DevOps visionary and leader. Before coming to the Foundation, Chip was vice president of Product Strategy at CumuLogic. He spent more than 15 years in engineering leadership positions within the service provider industry including work with SunGard Availability Services and Qwest Solutions. He has served on the board of directors for the Distributed Management Task Force; and is a member of The Apache Software Foundation.
About Paul Morie
Paul is a Principal Engineer at Red Hat and is a committer to the Kubernetes project. He is currently leading the Kubernetes Service Catalog SIG and the champion of the service-catalog Kubernetes incubator repository. Before Kubernetes, he worked on the first three versions of Red Hat's OpenShift Container Platform and built multi-tenant platforms for the financial and insurance industries. He likes spending time with his wife, scale model making, and striving for perfect hair.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
B
A
B
I'm
chip
I'm,
the
CTO
of
the
cloud
foundry
foundation
and
we're
here
today
to
talk
a
little
bit
about
services,
catalogs
and
the
api's
that
make
them
work
cool,
so
we're
going
to
start
with
a
little
cal,
aesthetic,
so
about
half
the
room
is
standing.
So
that's
a
little
strange
right,
I
was
going
to
say
air.
Let's,
let's
get
some
energy
going.
Everybody
raise
your
hand
if
you
develop
applications
that
use
something
like
a
database.
Oh
good!
B
A
B
Like
I
mean
it's
most
of
us
right,
okay,
everybody,
tired,
you
can
put
your
hand
Center,
that's
good
cool,
so
one
of
the
interesting
things
is:
how
do
you
actually
get
access
to
that
database?
That
you're,
using
for
your
application
I
mean
this
is
the
traditional
way
right?
How
many
of
you
do
this
but
create.
B
It's
a
great
experience,
it's
a
great
experience.
In
reality.
Most
of
you
probably
don't
operate
all
the
services
that
you
depend
on
when
you're
writing
your
application.
So
that's
really
what
service
brokerage
is
all
about.
You
know
one
of
the
things
that's
kind
of
difficult
about
just
database
access
for
developers.
How
do
you
get
that
password
passed
over
to
the
devam,
the
OP
statement?
And
so
we've
got
this
really
outstanding
technology
I
mean
I'm,
an
operator
I
provision,
databases
for
for
folks
and
we've
got
this
awesome
technology
secure.
B
B
Standing
out
standing
and
that's
usually
the
way
it
works-
I'm,
definitely
not
going
to
email.
You
the
password,
though
right,
because
that
would
be
insane
no
okay,
all
right!
Let
me
get
this
written
down
here,
for
you
hit
that
note
right
all
right,
cool,
so
came
over
Paul's
cubicle
here
you
go
buddy.
Finally,
sweet
relief
make
sure
you
get
that
thing
configured
before
done.
B
A
B
A
Here's
where
we
get
into
some
unavoidable
inconvenient
territory
and
thankfully
chip
had
the
foresight
to
come
up
with
this.
Maybe
patent
pending
system
of
yeah,
the
namespace
that
we're
going
to
evaluate
these
nouns
in
is
at
the
lower
right
hand,
corner
of
the
screen.
So
right
now
it's
open
serviceworker
api
because
we
do
have
some
naming
collisions
between
service,
catalog,
kubernetes
service,
open
service
broker,
etc.
Yeah.
B
So
we're
going
to
talk
about
cloud
centers
for
a
second
for
a
few
seconds
just
to
give
you
some
background
on
this
API
how
it
evolved,
where
you
know
what
the
needed
was
solving
and
before
we
transition
to
the
open
service
broker
API
and
in
kubernetes,
so
back
in
2011
class
editors,
first
open
source
by
VMware,
and
it
had
five
fixed
backing
services
again,
namespace,
two
Cloud
Foundry.
What
we
mean
by
a
backing
service
is
actually
in
when
you
look
at
factor
for
the
12
factors.
Anybody
familiar
with
the
12
factor,
applications.
B
Okay,
so
a
factor
for
stateless
applications.
Persistence
goes
into
a
backing
service.
So
that's
the
design
pattern
that
class
foundry
was
using
and
that's
the
term
for
service
right.
So
there's
five
of
them
now
for
those
of
you
that
have
written
code
before
generally,
you
start
with
a
fairly
static
implementation,
and
then
you
realize,
oh,
my
god,
I
just
tightly
coupled
that
thing
really
really
into
the
implementation
detail,
not
much
extensibility
there.
So
in
2013,
as
gf
was
evolving,
it
got
cleaned
up.
B
There's
a
v2
version
of
the
service
brokerage
API
became
much
cleaner
and
then
eventually,
we
added
some
asynchronous
provisioning
and
you'll
see
what
we
mean
by
that
in
a
minute
all
right
last
point:
late
2015-2016,
we
started
having
conversations
with
folks
from
you
know:
the
daya's
project
we
actually
notice
it
in
their
backlog
was
the
implementation
of
the
cloud
foundry
service
broker
API.
Within
that
past
experience,
it's
not
on
top
of
kubernetes
the
folks
at
Google
cloud
we're
poking
around,
and
we
also
in
talking
with
a
lot
of
the
the
cloud
foundry
end
users.
B
They
were
very
clear
that
their
data
center
is
not
going
to
be
one
platform.
Now
all
of
you
that
might
have
a
particular
platform
favorite.
This
is
just
reality
right
if
you're
from
an
enterprise,
you
understand
excu
if
a
complex
environment
and
so
there's
all
kinds
of
crazy
combinations
that
people
wanted
to
have
in
place.
B
Foundry
flows,
mezzo
mezz
displays,
kubernetes,
CS,
loves,
kubernetes
or
maybe
all
three
right,
depending
on
the
workload
or
the
specific
type
of
thing
you
were
trying
to
deploy
and
so
be
carrying
out
how
to
make
capabilities
that
are
being
exposed
by
different
teams.
Working
on
each
platform.
Work
with
the
other
platforms
was
actually
very
important
to
our
users,
so
we
created
this
thing
called
the
open
service
broker
API.
B
This
was
created
so
that
we
could
take
the
the
governance
in
the
evolution
of
the
API
between
platform
and
services
and
put
it
in
a
neutral
place
where
a
different
ecosystem,
different
commercial
interests,
were
able
to
collaborate
and
evolve
it.
It's
a
bit
more
complicated
than
just
saying,
there's
two
distributions
of
an
open
source.
You
know
saying
that
we're
you
know:
they'll
figure
it
out
in
the
upstream
right.
This
actually
becomes
a
bit
more
of
a
specification
upstream.
B
However,
there's
a
little
bit
of
a
nuance
there,
one
of
the
great
things
about
the
way
that
this
group
is
operating
is
that
this
is
not
astronaut
architecture.
Any
of
you
actually
dealt
with
kind
of
specifications
that
are
all
on
paper,
no
implementation,
the
there's
a
general
rule
that
we've
got
for
the
group.
Everyone
has
agreed
to
that
new
features.
New
capabilities
get
implemented
in
a
platform
before
it
becomes
part
of
the
spec
prove
them
out.
B
B
A
It
you
know
all
right
all
right.
Finally,
I
can
get
back
to
work,
yeah,
excellent,
all
right,
so
in
open
service,
burger
API,
it's
really
simple.
There's
there's
just
four
nouns
that
we
really
need
to
know.
So
a
broker
is
something
that
offers
a
set
of
capabilities.
We
call
those
capabilities
services
and
the
collection
of
those
capabilities
is
called
that
broker's
catalog,
so
naming
collision
there
a
broker
has
a
catalog.
It's
a
set
of
services
services,
their
capabilities
that
that
broker
provides.
A
So
as
an
example,
a
service
might
be
database
as
a
service
all
right
and
when
you
want
to
use
that
capability,
you
provision
a
new
instance
of
it.
So
continuing
that
database
as
a
service
metaphor
when
I
provision
something
that
I
can
use
from
that
I
get
a
database.
Now,
that's
all
fine
and
good,
but
what
I
want
to
hook
it
up
to
my
app
I
need
to
bind
to
it
and
a
binding
represents
my
desire
to
consume
that
instance
somewhere.
B
Cool,
so
let's,
let's
just
walk
through
how
those
nouns
work,
in
sequence,
pretty
straightforward.
Actually
the
beauty
of
this
API
is
how
simple
it
is.
You
have
a
platform
on
the
left,
any
type
of
platform
it's
effectively
to
consumer.
The
end
user
is
going
to
interact
with
the
platform.
This
is
about
how
a
platform
talks
to
a
backing
service
capability
so
step
one.
You
get
a
catalog
right,
that's
easy
step.
Two,
a
new
user
wants,
some
of
that.
They
want
that
database
they're,
giving.
B
B
No
doubt
right
last
up,
then
we
create
binding
right
again.
That's
the
association.
As
far
as
the
brokers
concern
it's
basically
providing
unique
credentials
back
to
the
platform.
Saying,
hey
look.
We
know,
you've
got
a
new
application
that
wants
to
access
this
instance
of
the
service
here
are
the
credentials
for
that
specific
application
or
I
could
even
imagine
it
working
in
other
ways
where
every
node
of
a
application,
that's
communicating
with
the
database,
could
eventually
get
unique
credentials,
make
sense
cool
and
then
you
know
you
can
delete
the
things.
That's
pretty
cool
it.
B
A
A
Perils
of
two
clickers-
yes,
so
we're
kubernetes
comes
into
play.
Is
that
this
this
API
and
abstraction
that
we're
talking
about
super
powerful
right?
We
don't
have
anything
like
this,
yet
in
kubernetes,
so
this
is
actually
something
that
a
number
of
folks
have
been
interested
like
chipset.
For
for
a
long
time,
we
established
a
sig
special
interest
group
in
the
kubernetes
community
in
September.
A
2016
made
an
incubator,
repo
under
Tribune
Nettie's
incubator,
Service
Catalog
in
October
of
that
year,
and
we've
got
folks
like
myself
from
Red
Hat
from
Deus,
Google
and
IBM,
and
we're
working
towards
an
alpha
release
that
we
want
to
be
able
to
use
against
a
one
six
cluster
which
is
convenient
since
one
six
was
released
yesterday.
If
you
helped
out
with
that
thanks
a
bunch,
so
the
API
kubernetes
api
that
we
surface
from
this
looks
a
lot
like
other
kubernetes
api
Zin
that
it's
intention
based.
So
what
I
mean
by
that
is.
A
When
you
create
one
of
these
resources,
it
indicates
your
intent
to
do
something
and
then
the
kubernetes
catalog
goes
and
tries
to
make
sure
that
your
intent
is
realize.
So
there's
just
four
resources
in
this
API
there's
a
broker
that
represents
your
intent
to
consume
a
particular
broker
in
the
catalog.
A
A
Likewise,
when
you
want
to
bind
you
make
a
binding
resource,
and
that
represents
your
intent
to
make
up
binding
to
a
particular
application,
so
the
I'm
going
to
talk
more
about
those
resources
in
the
demo.
It's
way
easier
to
show
something
interesting.
That
I
want
to
point
out
now
is
just
a
really
high-level
design.
If
you
look
at
this,
we've
got
an
API
server
and
a
controller.
Now
that's
this
API
server
that
you
see
on
the
upper
left-hand
corner
of
the
screen
is
not
the
kubernetes
core
API
server.
A
It's
a
new
API
server
that
reuses
some
of
the
API
server
pieces
from
kubernetes,
but
it
lives
outside
the
core.
We've
got
a
controller
that
backs
that
that's
list
watching
the
API
and
doing
the
normal
kubernetes
thing
that
we're
all
used
to
right,
we're
watching
resources.
It
sees
a
spec
type
thing
and
a
resource
and
tries
to
make
that
happen.
Now
the
controller
is
responsible
for
actually
talking
to
the
processes
that
implement
the
open
service
broker
API
and
it
manifests
bindings
down
in
back
into
the
core
API
server.
A
So
some
interesting
things
for
the
kubernetes
nerds
in
the
audience
we
might
have
one
or
two
of
those
right.
This
is
the
first
example
or
one
of
the
first
examples
of
extending
kubernetes
with
another
tiny
baby.
Kubernetes
I
grew
up
to
be
something
else,
and
those
of
you
that
are
interested
in
a
BIS
might
be
wondering
how
am
I
going
to
use
these
things
together.
Well,
in
1-6,
there's
support
limited
support
for
api
aggregation
where
you
have
a
fronting
proxy
in
front
of
the
core
API
server
and
other
API
servers
that
present
a
single
discovery.
A
A
One
of
the
requirements
that
we
have
is
that
you
shouldn't
have
an
additional
data
store
that
you
need
to
limit
operational
complexity,
so
our
API
server.
You
can
either
back
it
with
MCD
and
you
can
use
the
right
key
from
the
main
net
CD.
If
you're
running
kubernetes
in
an
environment
where
you
don't
have
that
right,
secret
to
SED,
you
can
actually
back
our
api
server
with
third-party
resources
so
that
your
data
goes
ultimately
into
the
cores
at
CD.
A
B
B
B
B
A
A
This
is
gonna,
be
a
fun
ergonomic
experience
over
here,
all
right,
so
what
I'm
gonna
show
actually
is
scaled
back
from
what
I
planned.
What
I
had
planned
to
show
is
that
there
are
a
bunch
of
brokers
that
folks
in
the
sigit
helped
me
get
ready
well,
when
I
hooked
them
up
to
the
catalog
I
found
that
the
catalog
didn't
actually
work
very
well.
So
sorry,
Doug,
sorry
PLA,
sorry,
everybody
else.
A
So
what
I'm
going
to
show
is
basically
an
equivalent
of
like
a
post-it
note
broker
and
for
those
of
you
that
are
interested
in,
like
the
the
brokers
that
we've
started.
Looking
up
like
please
do
talk
to
I'm
gonna,
just
name
some
names,
real
quick
talk
to
Doug
Davis
Doug.
You
want
to
put
your
hand
up,
there's
Doug,
rizvi
leg,
all
right,
Billy's
behind
the
pillar,
it's
apparently
at
least
big
enough
to
completely
obscure
belay
from
me.
A
B
We
should
point
out
there's
a
whole
bunch
of
burgers
that
exist
already.
That's
true
work
quite
well!
That
comes
from
the
Fiat
vehicle
system,
so
you
could
get
Google
cloud
services
brokered
into
kubernetes.
You
could
get
your
cloud
services
brokered
into
kubernetes,
so
that's
the
benefit
of
having
this
combinate
forms
and
services.
So.
A
Let's
check
out
what
a
broker
resource
looks
like
it's
pretty
simple
right
like
it
has
a
name,
and
it
has
a
URL,
since
this
broker
doesn't
have
any
hot.
It
has
a
URL
that
says
this
is
where
I
get
to
this,
and
if
you
see
UPS
broker
in
there
like
three
times
it's
just
a
product
of
how
we
happen
to
have
this
deployed.
This
is
the
cluster
local
DNS
of
the
thing
this
example
Brooker
is
actually
running
in
my
local
kubernetes
cluster.
So
when
I
create
this
thing,.
A
You
can
see
under
status
here
the
controller's
already
blinked
up
that
I've
created
this
thing.
It's
gone
in
fetched
these
service
classes
that
this
worker
gives
me
and
it's
ready
to
ready
to
go.
So,
let's
see
one
I
list,
the
service
classes
and
hey
there,
we
go
user
provided
service.
Basically,
this
is
kind
of
like
a
post-it
note.
A
You
can,
you
can
put
credentials
into
it
when
you
make
an
instance
of
it
and
I
will
give
them
back
to
you
when
you
bind
now
I
want
to
just
note
before
I
go
any
further
you'll
notice,
I'm,
actually
in
my
Service
Catalog
repo
now
and
the
resource
that
I
made,
is
in
contribute
examples
walkthrough.
This
is
our
walkthrough
for
Service
Catalog
and
one
of
the
the
reasons
that
we
thought
it
would
be
good
to
demo.
A
And
let's
talk
about
what
this
has
so
note,
this
instance
is
namespaced.
This
resources,
namespace
instances
live
in
a
namespace.
Its
spec
is
the
name
of
the
service
class
brokers
and
service
classes
are
global
resources,
and
this
plan
name
is
referring
to
the
service
plan
that
we
are
going
to
select
from
the
service
class
plans
are
they're,
not
API
resources,
but
the
API
types.
A
plan
is
basically
a
tier
of
a
service.
So,
for
example,
your
service
might
have
like
a
free
tier,
it
might
have
a
in
for
talking
database
of
the
service.
A
Maybe
your
free
tiers,
like
you,
know,
little
plaything
that
you
can
use,
but
it
doesn't
hold
that
much
data.
Maybe
when
you
go
up
to
the
silver
tier
you
get
like
a
tablespace
created
for
you
in
a
multi-tenant
database
somewhere
and
when
you
go
up
to
gold,
you
actually
get
a
new
database
process
created
for
you
that
you
don't
share
with
anybody
else.
So
this
this
user
provided
service
just
has
one
plan
called
default
and
we're
going
to
use
that
one.
So,
when
I
create
this.
A
Alright
check
that
out,
we've
got
a
condition
on
there
that
says
it's
ready.
The
controller's
gone
out
and
told
the
service
worker
give
me
a
new
instance
of
the
service
and
it's
ready
to
use,
so
that
means
I
can
bind
to
it.
Now.
Those
of
you
that
are
familiar
with
Cloud
Foundry
can
I
can
I
get
another
show
of
hands.
Okay,
we
got
some
cloud
foundry
users
in
boundary.
A
When
you
bind
to
a
service
you
get
this
environment
variable
called
beat
cap
services
that
has
JSON
representation
of
the
credentials
that
you
got
back
from
the
bind.
Now
in
kubernetes,
we
have
a
couple
different
mechanisms
that
you
can
use
to
get
things
from
secrets
and
config
maps
manifested
into
your
app.
You
can
get
them
in
environment
variables,
you
can
get
them
in
in
volumes,
and
so
what
we're
going
to
do
right
now
with
this
state
in
the
repo
that
I'm
demoing
from,
is
we're
just
going
to
create
a
secret
and
how
we
can
use.
A
Blinding
looks
pretty
simple:
it's
just
a
reference
to
an
instance.
New
bindings
are
names
based
so
instances
and
bindings
are
names
based
and
right
now
you
can
only
bind
to
an
instance.
That's
created
in
the
namespace
of
the
binding
one
of
the
futures.
Things
we
want
to
do
is
be
able
to
do
cross,
namespace
references,
but
there's
some
expensive,
relatively
speaking,
precedent
to
establish
in
kubernetes
to
do
that.
So
in
our
MVP,
you
have
to
have
the
binding
in
the
same
namespace
as
the
instance.
A
A
A
Let's
see
which
secrets
are
in
my
namespace
I
got
a
default
hook
in
there,
don't
have
my
secret
pre-created
or
anything
so
when
I
create
that
binding?
Oh
look
at
that
we
had.
The
controller
saw
I
made
a
binding.
It
went
out
and
told
the
service
burger
to
do
the
binding.
It
got
back
some
credentials
and
it
made
the
secret
in
the
kubernetes
core
API
that
I
can
now
use
in
my
application.
So
those
are
the
mechanics
I'm,
not
a
fan
of
like
flashy
demos.
I,
don't
want
to
get
hung
up
on
a
particular
technology.
A
A
Next
steps
getting
to
alpha
the
some
of
these
things
have
actually
happened
already
and
I
haven't
taken
them
off
the
slide,
but
so
we
noticed
that
we
got
a
secret
created
in
our
namespace.
That's
good
right,
but
that
means
that
I
have
to
know
that
it's
there
to
be
able
to
use
it,
and
it
also
means
that
I
have
to
like
put
that
knowledge
into
every
place
that
uses
it
now.
Luckily,
for
us
just
for
zell
in
1/6,
just
you
in
the
audience
here,
okay,
she
might
not
have
made
it
all
right.
A
In
1/6,
we
implemented
a
new
core
API
resource
in
the
settings.
Api
group
called
pod
preset
now
pod
preset
is
a
we've
got
the.
What
do
I
want
to
use
where
do
I
put
it
pod
preset,
is
the.
How
do
I
want
to
use
it
so
part
of
pod,
presets
spec
is
a
subset
of
the
pods
back.
You
can
say
I
want
to
use
this
thing
in
environment
variables.
A
I
want
to
use
it
in
volumes,
I'm
going
to
mount
the
volumes
in
two
containers
at
this
point
and
then
that's
how
do
I
want
to
use
it?
Who
do
I
want
to
use
it?
We
specify
in
a
label
selector,
so
you
can
create
a
pod
preset.
You
will
be
able
to
create
a
pod
preset
once
we
finish
rebasing
it
catalog
on
kubernetes
1/6,
which
is
a
lot
of
fun
you'll,
be
able
to
create
a
binding
that
has
the
what
do
I
want
to
use.
Where
do
I
want
to
put
the
data?
A
How
do
I
want
to
use
it
and
who
should
use
it
just
in
one
object?
What
this
means
is
that
you
will
be
able
to
get
that
automatic
injection
after
the
pod,
preset
resources
created
and
the
match
the
label
selector,
which
I
think
is
pretty
cool.
So
we
talked
a
little
bit
about
the
API
aggregator.
Already
that's
going
to
be
Co
resident
in
the
API
server
process
in
1/7,
and
this
is
important
to
us
because
we're
building
this
thing
outside
the
core.
A
But
it's
also
important
to
anybody
in
this
audience
that
wants
to
build
an
extension
to
burn
at
ease
outside
the
court.
So
once
we
have
those
things,
we
need
a
way
to
make
sure
that,
like
authentic
work
without
having
to
set
it
up
twice
the
service
catalog,
the
API
server
will
delegate
back
to
the
core
api
server
for
authentic
and
then
there's
some
other
integrations
with
the
kubernetes
core
that
those
of
you
that
know
Derrick
Wayne
car
from
the
kubernetes
community.
A
He
likes
to
call
it
the
community's
bow
just
to
make
the
experience
like
exactly
what
you
would
expect
when
you
use
the
kubernetes
api.
So
that's
that's!
That's
alpha.
After
alpha
we've
kind
of
hinted
at
some
of
these
things
so,
like
I,
said,
brokers
and
service
classes,
aren't
namespaced
that's
convenient
for
us
from
an
API
standpoint,
but
we
still
need
some
kind
of
mechanism
to
make
sure
that,
like
the
right,
people
can
see
and
use
the
right
services
and
not
services
that
they
shouldn't
be
able
to
use.
A
We
also
want
to
have
cross
namespace
bindings
and
then
there's
a
number
of
enhancements
to
the
open,
Service
Worker
API
that
we're
proving
out
right
now
that
we
expect
to
ripple
back
into
this
API
like
schema
for
parameters
that
you
can
give
to
bind
and
provision
output
schemas.
So
you
could
do
things
like
when
you
do
a
binding,
you
get
back
credentials,
you
get
coordinates
you
get
config.
We
want
to
put
those
things
in
the
right,
kubernetes
primitives,
it's
that
kind
of
thing,
and
that's
basically
the
short
version
of
the
roadmap.
A
We
got
some
time.
It
looks
like
for
questions
or
not.
I
can't
tell
because
my
clocks
in
the
wrong
time
zone,
I,
think
not
I.
Think
not
yeah
we'll
be
around
there's
folks
in
the
fig
that
are
around
that
raise
their
hands
earlier.
Open,
serviceworker,
api,
org,
github.com,
slash,
cousin,
Eddie's,
incubator,
Service
Catalog.
Thanks
a
lot
everybody
for
coming
pleasure.