►
From YouTube: SIG Service-Catalog Intro – Doug Davis, Michael Kibbe & Morgan Bauer (Any Skill Level)
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
SIG Service-Catalog Intro – Doug Davis, IBM, Michael Kibbe, Google, & Morgan Bauer, IBM (Any Skill Level)
About Michael
Michael Kibbe is a software engineer on the Cloud Services team at Google. Michael works on the Kubernetes Service Catalog project and the Open Service Broker API. His goal is to get us to a world where it is easy to consume hosted services, such as those offered by Google Cloud, anywhere, be it on a third-party cloud provider or on-prem!
About Morgan
Morgan Bauer works on Open Source at IBM in San Jose as part of the Cloud Division. Morgan is a maintainer on the core Docker Engine and also a founding contributor of the Kubernetes Service-Catalog.
About Doug
Doug works in IBM's Digial Business Group. He's been working on Cloud related technologies for many years and has worked on many of the most popular OSS projects, including OpenStack, CloudFoundry, Docker and Kubernetes. He's currently co-leading the CNCF's Serverless WG, the Cloud Events specification work and the Open Service Broker API WG.
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.
A
So,
let's
do
a
little
overview
of
what
I'm
gonna
talk
about.
First,
so
first
I'd
like
to
talk
about
the
motivations
around
service
catalog,
what
nice
shits
filling
in
the
career,
Nettie's
ecosystem
and
why
it's
important
and
then
I'll
introduce
the
open
service
broker
API,
which
is
the
API
that
service
catalogs,
backed
by
and
then
finally,
we'll
take
a
look
at
the
new
Resources
Service
Catalog
gives
you
and
what
a
typical
flow
would
look
like
when
interacting
with
it
and
then
hope
to
do
a
demo
if
everything
goes
smoothly
and
finally
a
QA.
A
So
what
is
service
catalog
in
one
sentence?
Service
catalog
is
a
kubernetes
extension
for
the
discovery
and
connection
to
externally
managed
services.
So
the
idea
is,
we
want
to
bring
the
concept
of
external
managed
services
into
the
kubernetes
ecosystem
as
a
first-class
citizen,
and
let
me
talk
a
little
bit
a
while
about
what
those
manages
manage
services
actually
are
so
I'm
gonna
do
a
goofy
little
example.
A
So,
let's
say:
you're
a
web
app
developer
who's,
trying
to
come
up
with
the
biggest
new
startup,
and
you
know
that
people
really
like
taking
and
sharing
pictures
of
their
cats-
and
you
suspect,
there's
a
real
problem
today,
though,
where
people
really
want
to
know
whether
the
pictures
they're
taking
will
be
highly
up
voted
on
reddit
or
elect
on
Facebook
before
they
share
them.
So
you
want
to
develop
an
app
that
people
can
upload
their
pictures
to
and
it
will
predict
how
well
that
picture
will
do
on
social
media.
A
So
what
are
the
sort
of
components
you
would
want
for
this
app
then?
So,
obviously
you
would
want
the
the
web
interface.
That's
what
your
bread
and
butter,
but
then
you
also
need
some
sort
of
bucket
storage
for
the
cat
pictures.
You
need
an
ml
engine
to
do
the
actual
prediction
aspect
and
you
probably
want
some
database
to
maybe
store
previous
cute
cat
prediction
results.
But,
as
I
said,
your
core
competency
is
the
web
app
development.
A
In
this
case,
you
would
have
your
web
app
running
in
pods
on
your
capes
cluster
on
Prem,
but
it
reaches
out
to
multiple
services
outside
the
boundaries
of
your
cluster,
and
that
way
you
can
focus
really
on
only
having
to
manage
your
deployments.
Your
services,
your
resources,
but
you
can
trust
the
hosted
services
to
be
managed
by
their
providers,
and
so
that's
the
dream
of
sort
of
a
hybrid
cloud
services
story
and
kubernetes.
But
this
model
could
also
apply
to
services
just
within
your
single
company
as
well
as
it
grows
larger.
A
So
different
teams
in
your
company
might
be
responsible
for,
like
the
billing
service
or
a
logging
service
or
their
own
managed
database
outside
the
realm
of
kubernetes,
and
you
still
want
to
be
able
to
interface
with
those
easily
from
within
your
cluster,
and
so
that's
great
in
theory.
But
what
does
that
look
like
today
in
kubernetes?
A
You
need
to
download
in
order
to
manage
your
interfacing
with
these
services
or
if
it's
internal
in
your
organization,
maybe
you
need
to
like
file
a
ticket
for
a
different
team
and
wait
three
days
before
somebody
brings
you
a
post-it
note
with
like
username
and
password
for
your
database
instance,
and
then
you
have
to
manually
inject
that
into
your
cluster.
Somehow,
so
you
probably
create
secrets,
but
that's
just
deploying
at
one
time.
So
maybe
each
developer
really
needs
their
own
isolated
environment
to
develop.
A
In
so
you'd
want
to
cluster
per
developer,
or
maybe
a
namespace
per
developer,
and
then
there's
the
test
cluster,
the
staging
cluster,
the
production
cluster-
and
you
want
each
of
the
instances
of
these
external
services
to
be
sandbox
really,
if
you
want
them
to
have
the
applications
to
have
their
own
views
of
these
services,
and
so
you
probably
need
to
start
writing
a
bunch
of
scripts
in
order
to
handle
the
interfacing
with
whatever
api's
are
offered
by
the
service
providers.
So
that
means
every
time
that
you
deploy
your
app.
A
You
also
need
to
run
these
scripts,
and
these
are
your
scripts.
So
good
luck,
maintaining
them,
and
then
you
have
to
interface
with
the
Kate's
API
in
order
to
automatically
inject
the
credentials
and
then
the
lifecycle
of
these
things
aren't
tied
to
your
applications.
So
you
also
have
to
write
scripts
to
tear
down
the
services,
and
hopefully
everybody
remembers
to
run
those
or
you're
gonna,
be
leaking
resources.
A
All
the
time
and
I
think
that's
not
the
best
story,
because
I
believe
that
we're
heading
towards
a
world
of
many
different,
interconnected
services
from
all
different
service
providers,
not
just
the
big
ones
and
I
think
with
products
like
sto.
That
story
is
really
taking
off
for
inside
of
your
cluster
inside
of
kubernetes.
But
what
about
outside
that
bound?
What
about
outside
the
bounds
of
whatever
may
be
hosted?
A
But
you
won't
see
a
truly
hybrid
story,
and
so
that's
sort
of
the
state
of
the
world
today
and
so
I'm
wondering
how
ours
are
we
we
were
wondering:
how
do
we
make
that
experience
better
and
if
we're
designing
the
concept
of
externally
managed
services
and
kubernetes
from
the
ground
floor?
What
would
we
want
so?
Firstly,
just
like
all
other
resources,
it
should
be
declarative,
so
I
should
tell
kubernetes
what
external
services
I
want
and
kubernetes.
A
Just
like
all
the
other
resources
it
manages
internally
should
do
the
heavy
lifting
to
make
sure
that
happens,
and
the
lifecycle
should
be
tied
to
my
applications.
Lifecycle,
so
I
should
be
able
to
keep
control,
apply.
My
entire
manifest
directory
external
services
included
and
everything
just
spins
up
as
expected,
and
then
Cube
control
delete
it
all
tears
down
as
expected,
and,
secondly,
I
think
it
should
ideally
be
a
consistent
API.
A
And
so
ideally
as
well,
though,
we
wouldn't
create
our
own
standardized
API
to
expose
eServices
and
kubernetes.
We
should
leverage
something
bigger
than
just
kubernetes,
and
ideally,
we
wouldn't
also
need
to
create
custom
logic
to
front
all
existing
service
provider
api's,
and
so
luckily,
for
us,
there's
a
industry
standard
emerging
for
discovering
and
connecting
to
manage
services,
and
that's
the
open
service
broker
API.
A
So
there's
the
concept
of
plans
of
a
service
which
are
basically
just
different,
flavors
or
tiers.
So
you
could
have
like
a
free
tier.
You
could
have
a
paid
tier,
a
premium
or
a
ha1
just
depending
on
what
the
service
broker
implementer
wants
to
offer,
and
then
each
plan
has
schemas
for
parameters
when
creating
instances
and
when
binding
your
application.
So
it's
a
simple
API
but
I
think
it
really
has
like
the
the
power
of
it
is
in
its
simplicity
and
so
with
that
foundation.
A
Let's
take
a
look
at
Service
Catalog,
so
at
a
high-level
service.
Catalog
is
a
kubernetes
extension
that
exposes
a
declarative
and
consistent
API
for
interfacing,
with
externally
managed
services
using
the
open
service
broker
API,
and
so
to
do
that.
We've
taken
all
the
concepts
of
the
OSB
api
and
map
them
into
what
feels
right
for
kubernetes
resources.
A
So
these
are
the
resources
that
we
came
up
with
in
so
it
looks
exactly
like
the
slides
a
couple
ago,
so
there's
service
broker
service
class
service
plan
service
instance
and
service
binding.
So
the
service
class
is
how
we
describe
the
service
offerings
and
that's
a
little
bit
of
a
lie,
though,
because
what
we
actually
ended
up
deciding
for
our
view
on
beta
one
was
we
wanted
broker
classes
and
plans
to
be
cluster
scoped.
A
So
it's
the
responsibility
of
the
cluster
admin
to
be
the
one,
adding
the
brokers
that
all
the
developers
in
that
cluster
could
use
and
currently
we're
working
on
namespace
versions,
though
so
that's
coming
in
the
next
couple
months
and
then
instances
and
bindings
are
namespace
scoped
for
the
time
being,
and
so
let
me
just
go
over
sort
of
the
resources
that
you
would
be
directly
creating
so
cluster
service
broker.
That
represents
the
external
broker
that
you're
communicating
with
and
as
part
of
its
spec.
A
You
define
the
URL
that
it
lives
at,
and
you
specify
a
secret
containing
credentials
to
talk
to
that
broker,
and
so
this
is
the
only
part
that
has
to
be
negotiated
out
of
band
of
kubernetes.
Once
you
get
that
injected
into
your
environment,
then
everything
else
is
just
creating
declarative
resources,
and
so
once
you
create
the
cluster
service
broker
resource
our
Service
Catalog
controller.
Will
connect
to
the
broker
and
learn
the
catalog
of
service
offerings
from
that
broker,
and
it
will
create
cluster
service
class
and
cluster
service
plan
resources
to
represent
those
in
your
cluster.
A
Then
you
can
browse
the
catalog
of
services
and
when
you
find
something
that
you
want,
you
can
create
a
service
instance
resource.
So
you
specify
the
class
the
plan
and
then
any
parameters
that
were
specified
by
the
schema
of
that
plan.
And
so
just
one
thing
is
that
we
use
the
external
name
of
the
class
and
plan
just
because
there's
a
difference
between
the
OSB
concept
of
its
external
name
and
then
the
kubernetes
concept
of
its
internal
name.
So
you
can
specify
either.
A
But
this
example
just
uses
the
external
name
and
then
once
the
service
instance
is
provisioned,
you
can
create
a
service
binding
resource
which
represents
your
intention
to
bind,
or
in
other
words
like
the
relationship
between
your
application
and
your
instance.
And
as
part
of
this,
you
specify
the
instance
you
want
to
bind
to
so
the
instance
ref
and
then
any
bind
parameters
and
as
a
result
of
the
binding.
Our
controller
will
create
a
secret.
A
In
your
applications,
namespace
with
any
information
needed
for
your
application
to
talk
to
that
instance,
so
like
credentials,
hostname
port
and
the
secret
name
will
by
default,
just
be
the
name
of
the
binding.
But
you
can
specify
that
and
of
course,
because
it's
kubernetes,
it
doesn't
matter
the
ordering
of
which
you
create
any
of
these
resources.
So
you
can
create
the
binding
than
the
instance
then
wait
a
while
create
the
broker,
and
then
everything
will
become
eventually
consistent
and
same
for
deleting
the
resources.
A
A
A
And
so
the
idea
is
that
in
the
books
Effie
the
books,
Effie
pod
won't
come
up
quite
yet
because
I
have
it
the
deployment
relying
on
the
pub/sub
secret
that
we
expect.
So
we
can
see
that
I
am
mounting
a
volume
for
the
credentials
for
pub/sub
and
then
I
am
also
and
I'm,
specifying
an
environment
variable
for
that
information
and
then
I
specify
the
pub
subtopic
and
all
this
comes
from
the
pub
sub
bindings
secret.
A
So
I'm
going
to
show
the
two
different
flavors,
the
imperative,
CLI
and
then
also
the
manifest
files.
So,
first
let
me
do
SB
cat
I
get
broker,
and
so
you
can
see
that
I
have
the
Google
cloud
platform
service
broker
currently
registered
in
my
cluster.
So
that
means
that
since
it's
ready,
we
should
be
able
to
do
get
classes,
and
now
we
can
see
all
the
Google
cloud
platform
services
that
are
exposed
to
us.
So
in
this
case
we're
interested
in
the
cloud
pub/sub
one.
So
let's
just
look
at
that.
One.
A
A
And
so
here
we
can
see
that
there's
some
there's
an
instance
create
parameter
schema
and
what
we
can
see
inside
of
here
is
there's
just
one
property
that
it
needs,
which
is
the
topic
ID,
so
the
pub
subtopic
so
I
can
go
ahead
and
do
SP
cap
provision.
Let's
call
it
pub
sub
class
cloud
pub/sub
plan
beta
and
I,
give
it
a
parameter
topic:
ID
equals
cube,
calm.
A
A
A
A
So
now
we
can
just
look
at
the
instance.
Real,
quick
and
so
SP
cut
says
it's
ready.
So
now
let
us
bind
to
this
instance,
so
in
this
case
I'm
going
to
do
the
Yama
file.
So
let
me
first
apply
that
now,
let's
take
a
look
at
that
file,
and
so
it
is
a
service
binding
resource,
API
version
service,
catalog,
its
IO
and
its
name
is
pub/sub.
It
references
the
pub/sub
instance,
and
it
just
has
a
few
parameters,
roles
that
we
want.
Our
own
service
account
for
this
and
then
also
create
a
subscription.
A
A
A
We
can
see
that
we
have
the
private
key
data
for
interfacing
with
the
the
service,
and
then
we
get
some
useful
information
that
we
might
just
want
to
use
in
our
application,
so
project
ID
service,
account,
name
and
then
subscription
ID
and
topic
ID.
So
now
that
that
secrets
up,
we
should
actually
have
our
pod
up
and
running.
A
B
A
A
And
so
here's
our
bookstore
application.
So
we
have
a
couple
of
interesting
books.
A
game
of
tones
tone-deaf
ten
year
olds
are
pitted
in
an
acapella
battle
royale,
where
only
one
will
survive.
I
would
like
that.
So
let's
go
ahead
and
purchase
that
one
okay
and
then,
if
everything
worked,
we
should
be
able
to
see
that
there
was
a
purchase
message
for
that
one.
So,
in
this
case,
I
made
a
script
that
just
does
the
G
cloud.
Pub/Sub
subscriptions
pull
and
now
if
we
get
the
message.
A
Where
you
see
that
there
was
one
book
purchased
and
if
we
do
it
again,
Oh
Oh
it's
reading,
probably
from
the
previous
one
I
had
so,
let's
I
previously.
Oh
sorry,
I've
run
this
demo
with
the
same
exact
subscription
name
multiple
times
so,
but
that's
the
idea
is
that
this
allows
you
to
just
really
easily
interface,
your
pub/sub
application,
pub/sub
service
with
your
application,
and
so
now
we
can
see
that.
A
A
Yeah,
so
that
makes
sense,
because
it's
two
three
and
four
so
the
Shelf
is
index
1.
So
this
is
book,
2,
3
and
4
and
I
bought
3
first.
So
that's
why
it's
ok
so
now
our
bindings
gone,
which
also
means
that
our
resources
should
have
been
cleaned
up.
So
if
we
go
back
to
my
get
messages
script,
we
should
see
that
now
it
fails
because
the
Service
Catalog
resource
was
deleted.
So
the
external
service
was
also
cleaned
up
for
you.
A
A
Okay,
so
that's
pretty
much
the
end
of
the
talk,
so
here
are
some
other
resources
that
you
can
get
involved
with.
If
you
want
to
learn
more,
so
we
have
a
sick
for
service
catalog.
It's
meetings
are
Mondays
at
1,
Pacific,
Time,
weekly
and
then
also
for
the
open
service
broker.
Api,
it's
Tuesdays
at
9:30,
Pacific,
Time,
weekly
and
with
that,
are
there
any
questions?
A
A
D
A
C
A
Say
so
yeah
so
right
at
the
moment,
that's
more
of
a
question
for
the
implementation
details
of
the
service
broker.
So
what
I
see
service
brokers
doing
now
is
offering
plans
that
represent
currently
provisioned
resources.
So
the
things
that
were
made
outside
of
the
scope
of
the
open
service
broker
API,
you
can
still
pull
them
in
to
Service
Catalog
and
then
the
bind
and
everything
works.
Just
as
expected.
A
I
absolutely
think
so
we're
having
some
some
talks
with
some
of
the
kubernetes
story
like
the
CSI
people
and
how
we
can
get
more
involved.
There
there's
some
questions
as
far
as
life
cycle
as
far
as
migration
of
data.
How
maybe
OSB
can
help
you
with
that?
So
we
have
a
concept
of
API
extensions
coming
where
we
are
able
to
define
our
brokers
are
able
to
define
an
API
on
top
of
the
instances
that
is
able
to
be
managed
by
the
platform's.
So
that's
how
we
could
have
some
aspect
of
migration
and.
A
Morgan,
yes,
yes,
we,
yes,
we
did
take
ownership
of
pot
presets.
This
is
not
currently
in
our
demo.
We
are
in
our
current
build
because
we
originally
had
pod
preset
bindings,
which
we're
able
to
just
automatically
create
pod
presets.
For
you,
we
decided
to
work
on
revamping
that
a
little
so
for
now
the
story
is
just
create
the
secret
and
then
you
consume
the
secret.
G
E
A
A
service
manager
is
about
the
concept
of
okay.
Service
Catalog
is
really
good
at
managing
the
external
services
that
you
created
inside
your
cluster
and
also
you
can
pull
in
stuff
via
the
broker
if
they
provide
specific
plans
for
pulling
in
already
provisioned
resources.
But
what's
the
story
around
sharing
instances
between
different
instances
of
Service
Catalog
or
between
Cloud
Foundry
and
Service
Catalog,
so
service
manager
is
a
layer
on
top
that
allows
you
to
register
your
brokers
with
service
manager
and
then
service
manager
is
able
to
expose
a
broker
API
to
the
controllers.
A
A
A
Yeah,
currently,
the
open
service
broker.
Api
assumes
that
you
have
the
connectivity
and
that's
something
that
we're
actively
talking
about
in
OSB.
How
do
we
give
the
plug
points
to
be
able
to
expose
different
networking
sort
of
configuration
and
I
believe
service
manager,
though
also
has
this
in
mind,
it's
it's
something
built
into
that.
So
if
you,
if
your
platform
can
talk
to
service
manager,
then
you
should
be
able
to
talk
to
the
brokers,
assuming
that
the
brokers
can
talk
to
service
manager.
A
B
A
That
was,
that
was
more
of
that
you
would
front
your
applications
as
OS
B
services,
so
you
would
create
a
service
broker.
Your
team
would
create
a
service
broker,
exposing
your
application
and
then
other
teams
could,
because,
if
you
expose
it
as
a
kubernetes
service,
as
long
as
there
is
the
network
and
connectivity,
it
all
plays
plugs
in
and
plays
well
last
question.
A
A
There
there
are
some
like
so
if
I,
if
I
understand
your
question
correctly,
are
you
asking
what
is
the
so
the
tools
provided
in
order
to
be
able
to
easily
create
brokers
mm-hmm?
So
that's.
We
have
an
OSP
starter
kit
from
Paul
Morey
Red
Hat
is
one
of
the
implementations,
I
think
Scott
Nichols
from
Google.
He
has
a
different
OS
B
starter
kit,
okay,
okay,
nice,
and
that's
also
something
that
we've
we
just
talked
about
a
couple
weeks
ago
at
the
open
service
broker
API
face
to
face.