►
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: SIG Service Catalog - Doug Davis & Jonathan Berkhahn, IBM
Join us for a deep dive into how the Kubernetes Service Catalog works under the covers. Starting with a quick overview of Service Catalog and some of the challenges we faced while bridging the different processing models between Kubernetes and the Open Service Broker API, we will then look at more advanced scenarios and new features from the perspective of cluster operators, application developers and helm chart authors. You’ll come away with a solid understanding of how Service Catalog works and recommended workflows and practices for using it. Finally we would love for anyone considering contributing to stop by and get an introduction to all the parts of Service Catalog, meet the maintainers and learn how to become a contributor!
To learn more click here: https://sched.co/FuLk
A
Let's
go
and
get
started
so
welcome
to
the
sig
service
catalog
deep
dive
session.
My
name
is
Jonathan
birkel
and
I
work
for
IBM
as
a
full
time
contributor
to
the
Service
Catalog
project.
My
erstwhile
colleague,
Doug
Davis,
who
was
trying
to
escape,
is
also
a
contributor
he's
one
of
the
co-chairs.
He
gave
the
intro
session
yesterday,
so
this
is
gonna,
be
a
bit
more
in-depth.
So
let's
go
ahead
and
get
started
this
direction.
Okay.
So
what
am
I
going
to
be
talking
about
today?
A
I'm
gonna
start
off
with
a
quick
overview
of
the
open
service
broker
API.
So
this
is
what
Service
Catalog
is
an
implementation
of.
We
went
over
it
briefly
yesterday,
but
I'm
gonna
go
a
little
bit
more
in
depth
and
just
sort
of
recap
things.
If
you
weren't
here
yesterday,
then
I'm
going
to
talk
a
little
bit
about
the
architecture
of
Service
Catalog
itself.
A
What
it
physically
is
how
it
plugs
into
your
kubernetes,
how
it
talks
to
the
service
brokers
through
AHS
bappy,
the
OSP
API
and
then
I'm
gonna
go
over
some
of
the
design
challenges
we
have
faced
and
continue
to
face
in
our
development
of
implementing
Service
Catalog
I'm
gonna
go
over
some
of
the
recent
features
we
as
a
sig
have
implemented,
and
then
I'm
gonna
go
over
our
future
plans.
What
we
hope
to
accomplish
for
the
next
six
months
sort
of
thing
and
then
one
will
have
time
for
questions
so
ozb
Appy.
What
is
that?
A
Okay,
so
the
open
service
broker
API
is
an
open
source,
API
specification
for
the
automated
deployment,
management
and
use
of
services
and
I'm
using
service
in
a
very
generic
sense,
not
the
specific
kubernetes
service,
meaning
but
more
of
a
generic
program
that
runs
somewhere
and
is
accessible
on
somewhere
on
your
network.
So
pretty
much
and
it
can
be
pretty
much
anything.
The
archetype
will.
Example.
We
use
is
sort
of
a
relational
database.
A
That's
something
that
cloud
native
apps,
you
know
usually
need
they
need
somewhere
to
keep
their
stuff
because
they're
stateless
and
that's
a
good
fit
for
the
OSB
API
model,
but
it
can
be
pretty
much
anything
and
we
want
to
solve
the
problem
of
app
developers
shouldn't
have
to
care
about
this
stuff.
They
should
focus
on
developing
their
app.
Not
how
do
they
manage
their
database?
How
do
they
hook
up
their
app
to
a
message
queue?
They
shouldn't
have
to
care
about
any
of
that.
A
So
it's
an
API,
so
it
has
two
sides:
the
client
side
of
the
server
side,
the
client
side
we
implement
as
Service
Catalog.
The
server
side
is
implemented
many
times
in
various
service
brokers.
That's
what
they're
called
and
they
have
three
main
endpoints
I'm
going
to
care
about.
For
the
purposes
of
this
talk,
they
have
a
catalog
endpoint,
which
you
get,
which
returns
the
lists
of
all
the
services
offered
by
the
broker.
A
So
that's
the
thing
that
we
actually
implement
and
we
translated
this
open
service
broker,
API
into
five
kubernetes
resource
types,
more
or
less
so,
service
broker
service
class
service
plan
service
instance
and
service
binding,
so
service
broker
is
our
internal
representation
of
a
broker
that
has
been
registered
with
the
cluster.
It
has
one
or
more
service
classes,
which
is
a
category
of
services
offered
by
that
broker,
for
instance,
my
sequel
databases.
Each
class
can
have
one
or
more
plans
which
is
sort
of
a
quality
of
service
level
of
that
class.
A
For
instance,
in
this
my
sequel
database
class,
we
could
have
multiple
plans
which
could
be
database
sizes,
so
you
could
get
a
10
megabyte,
100
megabyte
1
gig
database
out
of
that
class.
When
you
create
an
instance,
it's
a
specific
permutation
of
a
class
and
plan
so
of
my
sequel
databases
and
of
100
megabyte
my
sequel.
Databases
create
me
one
of
those
create
me
Johnathan's
100
megabyte
my
sequel
database
and
then
that
instance
can
have
one
or
more
bindings
created
for
it,
which
represents
a
single
set
of
credentials
to
access
it.
A
So
once
I
have
my
database
provisioned
through
service
catalog
I
can
create
a
binding
that
will
give
me
a
set
of
credentials
in
the
form
of
a
kubernetes
secret,
which
I
can
then
plug
into
my
writing.
Application
to
access
that
database,
the
magic
so
we're
gonna
briefly
go
over
what
Service
Catalog
actually
does
for
you
in
terms
of
those
abstractions.
So
here
we
have
our
friendly
user
and
their
kubernetes.
Now,
once
at
the
very
beginning,
you're
gonna
need
to
register
the
broker
with
your
kubernetes
service
catalog.
A
So
this
is
sort
of
an
operator
level
action
and
it's
it's
you
do
it
once
and
then
you
don't
need
to
worry
about
it
ever
again,
so
this
isn't
kind
of
the
domain
of
your
your
normal
user.
They
aren't
gonna
be
doing
this,
but
if
this
is
something
it
needs
to
happen,
so
you
register
the
service
broker.
Service
Catalog
is
gonna,
reach
out
hit
that
brokers,
catalog,
endpoint
and
retrieve
the
catalog
of
services
that
it
offers,
and
it's
gonna
keep
that
locally
and
keep
track
of
that.
So
that
could
be.
A
You
know
how
many
databases
this
broker,
offers
what
classes
and
plans
they
have
representing
those
so
on
and
so
forth,
and
then
the
user
later
on
can
go
and
look
at
Service
Catalog
hit
its
endpoints
say:
get
service
classes.
What
kind
of
things
do
you
offer
and
when
that
user
figures
out
they
like
okay
I,
want
a
database
of
this
specific
class.
This
specific
plan,
they're
gonna,
say
Service
Catalog,
create
me
a
new
service
instance
and
then
the
service
catalog
is
gonna
go
and
it's
gonna
issue
a
request
to
the
broker.
A
Saying
provision
me
a
service
instance
with
the
specific
class
and
plan
it's
going
to
go
to
the
broker
that
the
brokers
are
going
to
do
whatever
the
broker
does
to
provision
new
instances.
This
is
sort
of
out
of
the
purview
of
Service
Catalog.
We
don't
have
to
care
if
it's
bangin
rocks
together
or
you
know,
provisioning,
a
VM
or
a
container.
We
don't
care
it
returns
to
us.
Yeah
that's
been
created.
A
The
user
then
is
going
to
go
in
to
play
their
application
in
kubernetes
run
a
pod
somewhere
and
then
in
order
to
give
access
to
that
application.
To
this
instance,
it's
gonna
have
to
create
a
binding.
So
it's
going
to
say,
service
catalog,
create
me
a
service
binding
service,
the
catalogs
gonna
be
like
okay,
I'm
gonna
go
and
tell
the
broker
to
do
that,
and
it's
going
to
return
to
me.
A
Some
set
of
credentials
usually
use
your
name,
a
URL
and
a
password,
but
it
could
be
pretty
much
anything,
but
that's
usually
what
it
is,
and
service
cogs
gonna.
Stick
that
my
kubernetes
secret
for
you
now
kubernetes
secrets
already
use
outside
of
service
catalog
to
manage
access
to
services
and
other
things.
So
hopefully
most
kubernetes
users
should
be
familiar
with
that
and
then
they're
gonna
have
to
go
ahead
and
manually
attach
that
to
their
app
so
they're
going
to
have
to
coop
CTL
edit
their
application
declaration
somehow
give
it
access
to
that
secret.
A
A
So
now
I'm
going
to
briefly
talk
some
of
the
issues
we've
encountered
and
continuing
encounter
as
a
kubernetes
extension
project.
So
Service
Catalog
in
terms
of
criminalities
incubator
projects,
is
one
of
the
oldest
we've
been
around
for
about
a
year
and
a
half
two
years
now,
which
means
that
many
of
the
new
and
exciting
features
that
exist
in
kubernetes
today
didn't
exist.
When
we
started
the
projects
we
had
to
sort
of
break
new
ground
ourselves.
A
For
instance,
custom
resource
definitions
didn't
exist
when
we
started
so
we
had
to
pretty
much
come
up
with
our
own
solution
to
that
problem.
Tpr
is
the
predecessor
to
see
our
DS
did
exist,
but
they
were
pretty
buggy
and
a
very
new.
So
we
didn't
really
want
to
just
take
the
stability
of
our
project
down
those.
So
we
decided
to
come
up
with
our
own
solution,
which
was
API
aggregation
for
various
reasons
we
didn't
want
to
have
service
catalog
have
access
to
the
main
at
CD
store
from
kubernetes
proper.
A
So
our
solution
was
to
provision
our
own
at
CD
instance,
run
an
API
server
and
controller
on
top
of
it
and
use
API
aggregation
to
hook
that
API
server
in
to
the
main
access
point
for
the
main
kubernetes
api
server.
So
when
the
main
API
server
receives
a
request
to
manipulate
one
of
our
resources,
it
proxies
that
off
to
our
API
server
and
we
handle
it
from
the
users
perspective.
A
Another
issue
we
faced
is
that
kubernetes
names
of
objects
are
fixed.
They
are
immutable.
However,
we
have
outside
information
that
we
need
to
keep
track
of
the
various
names
and
goods
of
all
these
broker
resources
and
the
OSB
API
resources
have
mutable
names,
they
are
allowed
to
change,
they're
allowed
to
be
updated
and
they
also
have
goods
that
are
associated
with
each
of
these
resources
and
those
are
fixed
and
immutable.
So
we
needed
to
keep
track
of
both
of
these,
and
some
of
these
are
more
or
less
human
readable,
as
the
case
may
be.
A
However,
the
actual
names
of
the
resources
we
pull
from
the
external
goods
that
are
president
nas
bappy,
which
sometimes
aren't
exactly
human
readable.
So
we
implemented
in
our
CLI
tool,
SV
cat,
which
we'll
talk
about
in
a
minute.
We
generally
keep
track
of
things.
I
have
ax
their
external
names
rather
than
their
kubernetes
metadata
name
itself.
A
Another
issue:
this
is
a
more
of
an
ongoing
issue
that
we
struggle
with,
is
broker
synchronization,
so
kubernetes
sort
of
considers
itself
to
be
the
source
of
truth
of
the
universe.
It
allows
users
to
declaratively
modify
state
in
the
NCD,
with
the
expectation
that
somewhere
down
the
line,
I
will
be
able
to
reconcile
that
with
reality,
which
is
kind
of
a
problem
when,
in
order
to
do
that,
we
need
to
make
a
call
to
an
external
system.
A
In
our
case,
the
service
broker,
which
could
say
no,
the
user,
deletes
the
service
instance
and
we
tell
the
broker
hey
I
deleted
the
service
instance
and
for
whatever
reason
it
says,
no
you're
not
allowed
to
do
that
right
now.
That's
sort
of
a
problem
because
the
the
SCD
resource
has
already
been
marked
with
a
delete
flag.
It's
basically
already
gone
or
going
to
be
gone
in
the
very
near
future,
which
can
make
it
hard
to
reconcile
these
changes.
A
A
Okay,
so
moving
right
along
some
recent
features,
we've
implemented
in
the
past
six
months,
so
originally
the
original
imps
resource
types
that
we
implement
still
pretty
much
allowed
cluster
wide
access
to
anything
that
was
on
the
Service
Catalog
and
we've
received
a
lot
of
requests
for
various
ways
to
want
to
filter
that
and
we've
sort
of
implemented
a
couple
of
generic
solutions
to
that
that,
hopefully,
should
allow
cluster
operators
and
cluster
users
to
restrict
access
in
a
way
that
they
want.
The
two
when
I
talk
about
today
are
namespace
service
brokers
and
catalog
restrictions.
A
So
what
is
the
namespace
service
broker?
So
this
is
how
the
original
service
brokers
worked.
You
have
your
kubernetes
cluster
and
in
our
example,
here
we
have
two
service
brokers
registered
with
them.
Each
of
them
offers
a
single
service,
so
the
service
broker
is
available
cluster
wide,
so
any
service
it
has
is
going
to
be
available
to
all
of
your
users,
regardless
of
any
namespace
privileges
they
do
or
do
not
have.
The
same
is
true
for
service
B.
Here
anybody
can
see
it.
A
A
So
our
solution
of
this
was
to
implement
namespace
service
brokers,
a
namespace
version
of
the
service
broker
resource
that
registers
with
the
cluster,
just
like
a
normal
service
broker,
but
it
and
it's
children.
Resources
are
only
available
in
a
specific
namespace.
So
in
this
case
we
only
register
each
of
these
service
brokers
in
the
single
name,
space,
and
only
users
that
have
access
to
that
namespace
can
see
and
use
its
resources.
A
So
this,
like
I,
said
also
it
solves
the
problem
of
visibility.
Access
control
to
these
services,
but
because
each
of
these
brokers
is
only
visible,
it
only
modify
the
the
state
of
existence
of
the
namespace
that
it's
been
added
to.
This
is
also
a
far
less
destructive
operation.
There's
no
chance
of
you
know
I
want
to
add
my
specific
service
broker
and
it
has
a
name
collision
with
something
that's
already
present
on
the
cluster
wide
level.
A
So
it's
a
lot
safer
to
allow
normal,
like
app
developer
users,
the
capability
to
add
or
remove
these
from
the
clusters,
so
they
don't
need.
You
know
to
go,
bother
an
admin
to
add
their.
You
know
favorite
little
service
broker
to
get
access
to
their
resources.
This
is
something
they
can
do
themselves
spin.
It
up,
use
it
break
it
down.
Nobody
has
to
care
named
catalog
restrictions
is
sort
of
our
name
for
a
couple.
Different
things
we
implemented
would
basically
allow
the
white
and
black
listing
of
services
on
a
specific
service
broker.
A
So
when
you
create
the
broker
at
register
time,
you
can
specify
a
catalog
restriction,
which
is
basically
either
a
white
or
black
list
of
the
services
that
belong
to
that
specific
broker.
So
this
is
a
simple
example
of
a
black
list.
You
know
when
you
create
the
broker,
specify
a
catalog
restriction
that
says
no
service
name
to
be,
and
service
B
won't
show
up
to
any
of
the
users
that
have
access
to
the
services
from
that
broker.
A
Similarly,
you
can
specify
a
white
list
give
me
only
service
a
when
you
create
the
broker,
so
only
a
you'll
show
up
to
users
on
the
system
and
combine
these
two
features
pretty
much
allow
a
great
deal
of
permutations
of
access
control,
so
you
have
a
broker.
You
only
want
to
specify.
You
know
that
those
resources
to
specific
users
or
even
specific
resources
on
that
broker
to
specific
resources
differently.
These
two
combined
will
allow
you
to
do
that
Espie
cat.
So
this
is
the
other
big
thing
we've
been
working
on.
A
In
the
past
six
months,
we've
been
implementing
our
own
custom
CLI
for
several
reasons.
One
I
mentioned
earlier:
the
naming
sort
of
weirdness
the
collision
between
how
kubernetes
treats
names
and
OSB
resources
have
names,
make
it
kind
of
confusing
to
reconcile
those
two.
So
we
created
our
own
CLI
and
generally
refer
to
service
catalog
resources
only
via
their
external
name,
which
is
usually
something
that's
human,
readable,
my
sequel,
databases.
How
did
you
bangee
bite?
A
My
sequel
databases
other
than
gooood,
which
is
you
know,
axb
underscore
my
sequel,
one,
two,
three
four,
so
we
allow
that
to
be
easier
for
the
user
to
provision
browse
use
resources,
that's
easier
for
them.
Additionally,
we
sort
of
want
to
follow
a
more
imperative
model
of
resource
interaction,
because
we
have
to
go
out
and
call
out
to
this
external
platform.
A
Unexpected
things
can
happen
when
the
users
directly
manipulate
the
kubernetes
resources,
and
this
sort
of
lets
us
pull
that
under
the
covers
and
away
from
the
users
hands
to
sort
of
hide
that
from
them.
Additionally,
we
have
a
couple
sort
of
niche
features
that
aren't
really
representable
directly
in
normal
kubernetes
abstractions.
A
The
classic
example
we
like
to
use
is
the
marketplace
command
that
we
have
implemented,
which
is
showing
all
of
the
services
I
can
buy
using
service
catalog,
which
is
represented
by
multiple
resource
types
amalgamated
together,
for
instance,
show
me
all
the
classes
of
services
available
to
me
and
all
of
the
plans
that
are
attached
to
those
which
you
couldn't
get.
If
you
were
just
like
show
me
all
the
classes
available
on
my
cluster
to
me,.
A
Future
plans,
so
this
is
what
we're
hoping
to
do
in
the
next
six
months.
We
are
still
a
beta
project.
We
are
coming
up
on
1.0,
but
that's
still
sort
of
under
contention
for
what
exactly
that's
going
to
mean,
but
this
is
just
a
quick
list
of
the
things
we're
actively
working
on
or
investigating
the
use
of
CRTs
to
replace
our
own
custom
API
server.
This
is
still
open,
the
other
up
in
the
air,
whether
all
of
the
functionality
that
we
currently
have
can
be
replicated
using
C
or
DS.
A
So
currently
all
the
classes
and
plans
you
will
see
on
a
cluster
come
directly
from
the
catalog
offered
by
the
broker,
we're
creating
the
feature
to
allow
Crush
cluster
operators
to
create
custom
classes
and
plans
and
pre
specify
parameters
such
that,
like
you
know,
it's
a
configurable
size.
You
provide
a
parameter
that
says
how
big
my
database
is
going
to
be.
We
can
rule
out
a
cluster
operator
to
pre
specify
that
so
the
user
wouldn't
have
to
care.
A
They
could
just
be
like
pick
from
a
list
that
doesn't
necessarily
exist
on
the
broker
itself,
pod
presets.
So
currently,
when
you
create
a
binding,
the
output
of
creating
that
binding
is
a
kubernetes
secret
created
somewhere.
It
is
not
automatically
connected
to
your
application
and
we
want
to
take
this
a
step
further,
so
that
the
user
doesn't
have
to
go
and
manually
add
that
to
their
pod
declaration
or
deployment
declaration.
The
problem
with
that
is
is
this
is
not
really
accomplishable
from
our
little
extension
project.
A
We
need
to
implement
actual
functionality
inside
the
mainline
kubernetes
repository,
so
we're
currently
collaborating
with
some
of
the
core
teams
to
get
this
done.
But,
like
I
said
it's
it's
it's
a
project
in
motion
and
then
reiterate
again
we're
coming
up
on
our
1.0
release,
so
that,
hopefully,
should
be
sometime
in
the
next
six
month.
We
should
graduate
okay,
so
that's
pretty
much.
All
the
material
I
have
prepared.
A
I
can
feel
questions
now,
but
before
that,
just
a
quick
rundown
of
some
resources,
so
this
first
link
here
is
our
general
documentation.
What
is
service
catalog?
How
do
I
start
it?
How
do
I
use
it?
How
do
I
get
up
and
running?
This
is
our
actual
repository
if
you're
interested
in
contributing
or
just
checking
out
what
issues
we're
working
on
adding
a
given
time.
That's
place
to
check
that
out
open
service
broker
API.
B
B
A
A
Whoever
does
this
is.
Whoever
has
permissions
to
create
service
brokers
on
the
cluster
so
for
a
cluster
service
broker,
usually
an
admin,
and
then
this
will
be
for
anyone
who's
capable
of
viewing
services
from
the
service
broker.
They
won't
see
service
B,
it's
like
it
doesn't
exist.
So
this
isn't
our
back.
Not
exactly.
A
B
B
A
We
don't
have
the
capability
to
do
that
right
now,
in
catalog
restrictions
like
I,
said
it's
sort
of
an
ongoing
problem,
because
some
brokers
do
enforce
restrictions
like
that,
like
you
can't
delete
a
service
after
five
o'clock
and
we
currently
don't
have
any
way
to
represent
that
range
of
restrictions
in
inside
of
our
resource
model.
So
no,
you
can't
do
that
right
now,
but
we
are
working
on
letting
you
do
things
like
that.
Okay,.
B
A
A
Like
I
said
currently,
OSP
is
also
under
ongoing
development,
and
this
isn't
a
problem
just
for
us.
Other
platforms
that
implement
the
OSP
API
have
similar
issues
and
we're
currently
on
the
we're
just
getting
started
on
version
3
of
OS
b
api,
so
we're
starting,
potentially
a
new
entirely
different
API
from
scratch.
So
the
answer
is
probably
going
to
be
both
the
specification
itself
will
probably
change
some
to
allow
for
the
additional
hooks
and
endpoints.