►
From YouTube: SIG Service Catalog - Jonathan Berkhahn, IBM
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
SIG Service Catalog - Jonathan Berkhahn, IBM
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Come learn about the Kubernetes Service Catalog Project. Service Catalog lets you provision cloud services, regardless of where they are hosted, directly from the comfort of native Kubernetes tooling. Through use of the Open Service Broker API, app developers can use third party services directly from your Kubernetes application. We will walk through provisioning a database through Service Catalog, and then connect it to an application running on the cluster. We’ll also briefly cover recent work and future plans for Service Catalog. Finally, we would love for anyone considering contributing to stop by and get an introduction, meet the maintainers and learn how to become a contributor!
https://sched.co/NrrK
A
Okay,
I
figure.
We
can
go
and
get
started
so
hello
and
thank
you
for
showing
up
to
the
Service
Catalog
sixth
session,
so
my
name
is
Jonathan
Brooklyn
I'm,
a
co-chair
of
sig
service
catalog,
as
well
as
a
maintainer,
so
yeah.
So
this
is
the
only
session
we
have.
We
only
got
one
slot,
so
I'm
gonna
be
covering
stuff
fairly
quickly.
B
A
Then
I'm
gonna
do
a
brief
demo,
just
sort
of
the
the
simple
happy
path
of
using
it
and
then
I'm
going
to
dive
a
bit
more
into
how
it
actually
works,
how
the
odds
bappy
the
API
that
lies
behind
it,
works
and
then
quickly
go
over
stuff.
The
sig
is
done
recently
and
our
future
plans.
Okay.
So
what
is
service
catalog?
So
in
the
world
of
cloud
native
applications
we
have
today,
your
applications
that
run
on
kubernetes
are
not
exactly
islands.
Well,
they
also
often
have
their
own.
A
B
A
Probably
has
some
sort
of
data
that
needs
to
be
persisted
beyond
the
lifetime
of
each
ephemeral
container,
and
you
need
some
place
to
put
that
data.
Usually
a
you
know:
relational
database,
equal
Postgres.
What
have
you
and
these
services
are
often
fundamentally
required
by
your
application?
It's
not
like
you.
Could
you
know
for
an
angle,
some
ways
that
you.
A
To
require
them,
it's
something
you
absolutely
have
to
have,
or
else
your
application
will
not
work
and
as
an
application
developer.
You
need
these
things,
but
it
would
be
nice
if
you
didn't
have
to
provision
them
and
manage
them
and
allocate
all
the
resources
for
them
yourselves.
It
would
be
nice
if
someone
who
you
know
was
more
experienced,
who
had
dedicated
responsibility
for
that
sort
of
thing,
would
handle
all
this
for
you,
and
this
is
the
problem
that
a
Service
Catalog
is
attempting
to
solve.
So
I
have
my.
A
Really
the
only
sort
of
thing
I
care
about
it
would
be
nice
if
the
the
usin
manager
of
the
sophistic,
the
services
could
be
a
distracted
away
from
me
and
before
I
go
any
further
I'm
gonna
sort
of
help
define
what
exactly
I
mean
when
I
say
services,
so,
especially
within
the
realm
of
kubernetes.
That
word
is
sort
of
overloaded.
A
At
the
same
time,
we
also
have
an
initiative
platform
manager,
hosted
services
like
object,
storage,
various
flavors
of
databases
and
then
external
services,
which
is
probably
where
it
starts
a
little
more
weird,
because
that
can
still
be
the
sort
of
archetypal
thing
like
relational
databases,
it
could
be
a
subscription
to
some
API
like
Twilio.
It
could
be
a
subscription
to
billing
services
so
on
and
so
forth.
A
So
it's
really
these
sort
of
second
two
categories
that
what
I
mean
when
I
say
services
I,
don't
necessarily
mean
a
thing
running
at
a
dns
discoverable
address
within
the
cluster
itself,
I
mean
some
some
trying
to
avoid
using
the
word
service.
Something
I
want
that
my
application
needs
not
necessarily
within
the
cluster
and
creating
you
manage
ease.
A
These
things
can
be
non-trivial,
so
a
relational
database
is
something
all
of
us
are
probably
familiar
with,
but
there
certainly
can
be
stranger
and
more
esoteric
services
that
again
our
application
developers
don't
really
want
to
be
in
the
business
of
provisioning
and
maintaining
those
themselves.
We've
all
probably
have
some
experience,
relational
databases,
but
something
like
Twilio,
which
is
a
a
P
I
to
make
phone
calls
again.
I
really
don't
want
to
have
to
handle
it
myself,
something
that's
sort
of
mission-critical
like
billing
services
again
I.
A
Don't
really
want
to
have
to
handle
that
myself
and
for
any
of
these,
even
if
I
do
have
like
the
actual
code
that
does
it
managing
the
instances
can
itself
be
a
non-trivial
task.
Okay,
so
once
I
have
a
database
up
and
running
I
have
to
control
access
to
it.
Okay,
so
I
have
a
set
of
credentials.
How
do
I
maintain
that
do
I,
maintain
it
with
a
sticky,
now
push
it
on
my
mom.
Do
I?
Okay,
that's
probably
not
a
very
good
idea,
but
I
could
put
it
in
a
secret.
A
Okay,
that's
a
little
bit
better,
but
that
secret
is
still
ephemeral.
It's
within
your
kubernetes
cluster.
You
have
to
control
access
to
it.
If
you're
in
a
multi-tenant
cluster,
you
have
to
make
sure
that
the
wrong
people
don't
have
access
to
it.
In
the
event,
the
credentials
need
to
be
changed
or
rolled.
I
have
to
go
in
and.
A
That
and
this
all,
it
can
be
further
compounded
by
the
fact
that
this
service,
this
thing
I'm
consuming,
might
not
be
deployed
within
the
kubernetes
cluster
itself.
It
might
be
something
else
running
in
the
same
data
center.
It
might
be
something
else
running
on
the
internet
somewhere
completely
different,
and
each
of
these
services
is
also
going
to
be
further
compounded
by
the
fact
they're
gonna
be
managed
and
deployed
their.
A
Kubernetes
already
has
secrets,
which
is
a
good
way
to
encapsulate
these
credentials,
so
it'd
be
nice.
If
we
could
take
advantage
of
that
because
our
application,
it
will
also
probably
already
familiar
with
that,
and
that
is
what
a
service
catalog
does.
So
what?
If
I
am
a
user
of
kubernetes
and
I
had
a
command
called
marketplace?
It
would
be
like
hey
show
me
all
the
things
I
could
buy
and
it
came
back
with
a
list
of
okay.
A
A
What
are
the
benefits
of
this?
So
the
most
obvious
benefits
is
probably
the
ease
of
use,
and
that's
really
what
we
were
aiming
for
to
relieve
the
burden
of
application
developers
from
having
to
focus
their
time
and
effort
on
these
things
that,
while
they
need
them
for
their
application
to
run,
they
aren't
really
within
the
main
purview
of
the
application
developers
themselves.
A
Additionally,
because
this
is
all
contained
within
the
sort
of
normal
kubernetes
workflow,
it
can
be
utilized
by
helm,
carts
or
operators
or
what-have-you
to
automate
the
use
of
these
resource
types
sort
of
coming
at
it
from
the
other
angle,
if
I'm
a
service
provider.
So
if
I
sell
databases,
this
is
also
very
helpful
to
me,
because
it
gives
me
an
easy
mechanism
to
provide
my
service
to
application
developers
who
are
interested
in
consuming
it.
A
Additionally,
while
Service
Catalog
itself
is
the
kubernetes
implementation
of
ozbaby,
the
thing
that
allows
this
magic
sort
of
at
work,
other
platforms
as
a
services
also
implement
ozbaby
so
that
they
can
also
consume
these
service
brokers.
So
if
I'm,
you
know
interested
in
selling
my
databases,
this
opens
up
multiple
markets
to
me.
The
service
provider,
which
hopefully
means
more
people,
can
use
them.
A
A
A
Now
this
are
the
services
available
from
a
single
broker
called
mini
broker,
that's
sort
of
a
helpful
tool
that
I
use
a
lot
for
demos.
It's
a
it's
a
service
broker,
so
it
it
offers
services,
but
the
actual
backing
store
is
really
just
helm
charts.
So
when
I
request
one
of
these,
it's
going
to
deploy
a
helmet
art
and
locally
in
the
same
cluster,
but
that's
the
sort
of
a
the
way
this
particular
broker
is
implemented.
A
A
So
the
class
is
sort
of
what
service
this
offering
sort
of
generally
represents.
This
is
fairly
straightforward.
It's
a
Rattus!
The
plan
is
what
particular
flavors
that
service
comes
in
so
because
this
is
really
deploying
helm,
charts
in
the
backend.
That's
what
that
is.
It's
the
version
of
the
helm
chart
I'm
I'm,
pushing.
A
So
in
reality,
that's
pushing
a
home
chart,
so
I
can
go
back
and
look
at
the
pods
to
see
it
getting
created
depending
on
what
broker
using.
This
could
be
something
you
know
like
this,
where
it's
deployed
and
say
the
same
cluster,
it
could
be
a
broker
on
the
internet.
That's
provisioning,
something
inside
the
you
know
the
service
providers,
datacenter
I,
don't
have
to
really
know
or
care.
A
A
So
when
I
go
back
and
reload
this,
it
should
be
connected
to
my
Redis,
and
this
is
all
the
information
it's
using
to
access
that
reticence
since
I
just
created
so
now,
I
can
type
stuff
in
and
then
we'll
get
stored
in
that
red
assistance.
So
that's
that's
sort
of
the
brief
walkthrough
of
how
easy
this
stuff
is
to
use.
C
A
Key
values,
database
and
that's
sort
of
the
archetypal
example
like
I
said,
but
this
can
be
used
to
represent
both.
Oh
sorry,
a
lot
more
stuff,
so
pretty
much
anything
that
can
be
represented
in
credentials,
which
is
to
JSON
containing
arbitrary
fields,
can
be
used
offered
via
a
service
broker.
So
databases
subscriptions
to
any
sort
of
API.
A
There
even
may
be
a
little
bit,
stranger
brokers
that
are
sort
of
platform
or
where
and
can
reach
back
into
the
platform
and
provide
internal
platform
services
such
as
load,
balancing
or
auto
scaling
of
the
things
that
are
attached
to
them.
So
well,
that's
sort
of
the
example
we
use
it's
by
no
means
limited
to
just
that,
and
while
the
command-line
utility
I
used
in
that
demo,
SP
cab,
that's
sort
of
a
little
tool
we
have
developed
for
Service
Catalog
everything
I
showed
you
is
accomplished
using
normal
kubernetes
pattern.
A
A
Okay,
so
that's
the
basics,
I'm
gonna,
get
kind
of
into
the
nitty-gritty.
Now
so
I
called
said
this
a
couple
times
open
service
per
ok
API.
What
exactly
is
that?
So
it's
an
open
specification
of
an
API
for
the
automated
deployment
management
and
use
of
services,
so
I've
already
explained
through
the.
Why
you
would
want
this.
This
is
sort
of
the
how
and
it
specifies
two
sides
of
an
API
one
for
the
the
server
side,
which
is
called
a
broker
one
for
the
client
side,
which
is
the
platform
in
our
case
kubernetes.
A
It's
sort
of
has
three
main
actions
and
get
catalog
provision
instance
and
buying
service,
which
we
have
represented
in
corresponding
types
in
service,
catalog
itself,
cluster
service
broker,
cluster
service
class
cluster
service
plant
and
service
instance,
and
Service
binding,
as
well
as
namespace
representations
of
each
of
those.
So
going
back
to
the
sort
of
archetypal
example,
cluster
service
broker
would
be
some
my
sequel
book
or
a
broker
that
offers
my
sequel
services.
The
class
would
be
my
sequel
instances
or
sorry.
My
sequel
databases
then.
B
A
Service
class
would
have
sort
of
plans
that
are
belong
to
it,
which
would
be
different,
flavors
of
databases,
so
100
megabyte
my
sequel
databases
and
then,
when
a
user
provisions,
instances
of
that
class
and
plan,
that's
what's
called
an
instance,
so
Jonathan's
100
megabyte
my
sequel
database
and
then,
when
we
create
bindings
to
that
instance,
that's
a
set
of
unique
credentials
to
access
it.
So
a
single
username
password
for
accessing
Jonathan's
hundred
megabyte
my
sequel
database
and
then
I'm
gonna,
briefly,
sort
of
step
through
the
workflow
of
what
actually
happens.
A
So
the
first
thing
that
happens
when
you're
trying
to
use
service
catalog
is
you
have
to
register
a
service
broker.
Now.
This
is
something
that's
sort
of
done
once
usually
by
an
operator
and
from
then
on
services
offered
by
that
broker
are
going
to
be
available
in
your
cluster.
So
when
that
happens,
you're
going
to
create
a
service
broker
object
in
service
catalog
and
service.
C
A
Be
like
okay:
these
are
the
services
that
are
available
on
Service
Catalog
I'm
gonna
want
to
provision
an
instance
of
one
of
those,
so
it's
gonna
do
this.
By
creating
a
new
service
instance
object,
catalogs
gonna,
go
to
the
broker
and
be
like
a
create
me,
a
new,
my
sequel
database
of
class,
my
sequel
plan,
100
megabytes
and
the
broker
is
going
to
do
whatever
it
needs
to
do.
To
make
that
happen
again.
A
Service
Catalog
doesn't
really
need
to
know
or
care
that
user
is
going
to
deploy
some
application
that
it
needs
to
consume
the
service.
It's
gonna
create
a
binding
by
creating
a
service
binding
object
in
service
catalog,
which
again
we're
gonna
forward.
That
request
to
the
broker
saying
create
a
binding
to
that
instance.
You
already
have
provisioned
and
it's
gonna
return
a
set
of
credentials
now.
C
A
Mentioned
this
before
these
credentials,
it's
sort
of
an
arbitrary
JSON.
It
contain
arbitrary
fields
which
can
vary
a
lot
depending
on
the
service
and
how
the
broker
offers
it.
Usually
it's
some
set
of
a
username
password,
a
URL
and
port
that
you
can.
You
know
where
you,
where
you
can
access
the
service
and
how
you
can
log-in
and
we're
going
to
take
that
we're
going
to
create
a
secret
with
that
credential
in
it,
which
the
user
can
then
attach
to
their
app
which
we'll
use
to
access
the
service
wherever
it's
running.
A
So
that's,
that's
sort
of
so
what's
actually
going
on
when
I
step
through
those
steps
and
that's
sort
of
how
Service
Catalog
works.
So
that's
the
what
the
why
and
the
how
I'm
gonna
go
briefly
now
into
what
the
sig
has
sort
of
been
doing
in
the
past
couple
of
months.
So
we
just
recently
released
zero
to
zero
of
Service
Catalog.
A
major
feature
release
that
was
the
official
ga
release
of
names
based
resources.
A
So
previously
brokers,
plans
and
classes
were
only
available
as
cluster
wide
resources,
which
meant
when
broker
was
added
to
the
the
kubernetes
cluster.
It
would
be
available
cluster
wide
to
all
users
and
sort
of
in
the
interest
of
allowing
operators
to
restrict
access
certain
services
to
namespaces
or
even
further.
We
added
a
couple
features
than
the
main,
one
of
which
is
namespace
versions
of
those
resources,
also
because
cluster
service
brokers,
adding
them
to
the
cluster,
is
sort
of
a
very
widely
impactful
action
that
was
usually
recommended
to
be
restricted.
A
Only
the
cluster
operators
but
namespace
version
of
these
resources
can
be
installed
in
a
single
namespace
and
are
much
less
disruptive
to
other
users
of
the
cluster.
So
there's
probably
a
lot
less
reason
to
have
restrictions
on
creating
and
using
those
types.
So
this
also
allows
individual
users
of
a
cluster
to
manage
their
own
brokers.
Add
them
to
their
cluster
if
they
wanted
to
use
them
themselves,
and
then
we
also
updated
SV
quatre
CLI
to
be
sort
of
intelligent
about,
manipulating
both
these
resources
types
I
mean
catalog.
Restrictions
was
another
feature.
A
A
Okay,
so
that's
that's
what
we
just
did.
I'm
gonna
talk
about
what
we're
going
to
do
now,
so
Service
Catalog
is
kind
of
weird,
and
then
it's
a
pretty
old
project
we've
been
around
for
about
three
years
now,
which
means
that
when
we
started
all
the
fancy
things
you
can
use
today,
like
CR
DS
didn't
exist
so
currently,
today,
Service
Catalog
exists
as
an
aggregated
API
server
and
an
accompanying
controller,
which
means
we
don't
use
CR
DS.
A
A
Other
than
that,
the
things
we're
working
on
are
so
because
we
represent
sort
of
a
functionality
of
a
server
outside
with
kubernetes
that
we
occasionally
have
synchronization
issues
where
a
user
can
request
some
state
by
issuing.
You
know,
creating
an
object
or
deleting
an
object
within
Kubb,
and
we
have
to
attempt
to
reconcile
that
state
with
an
exterior
sort
of
source
of
truth
in
the
broker,
which
occasionally
causes
a
little
hiccups.
A
If
the
broker
you
know,
prevents
us
from
doing
a
thing
or
forbids
us
from
doing
an
action
after
that,
action
is
already
cleared
within
coop,
so
that's
sort
of
a
source
of
constant
hiccups
and
bugs
we're
still
working
on
improving
that
we're,
adding
a
new
feature
called
user
provided
services
where
we
sort
of
skip
the
first
three
steps
of
creating
a
broker
and
picking
a
class
and
plan.
So
this
is
a
feature.
That's
if
I
have
some
service
instance
like
a
database
that
already
exists
outside
in
the
world
for
legacy
purposes.
A
Maybe
I
can
manage
access
to
that's
extant
service
instance
using
service
catalog
without
having
to
have
a
broker
pot
presets.
So
currently
the
end
result
of
using
service
catalog
is
you
create
a
binding
and
it
creates
a
sir
a
secret
in
a
namespace
with
your
credentials
in
it
and
beyond
that,
it's
really
left
up
to
the
user.
A
You
have
to
attach
it
to
a
pot
or
a
deployment
and
make
use
of
it
manually,
so
we're
working
on
proving
that
by
adding
a
feature
called
pub
presets
which
would
allow
you
to
automatically
inject
a
binding
to
a
deployment
or
pod
we're
also
working
on
improving
our
docks,
that's
sort
of
a
constant
task,
but
with
the
namespace
service
broker,
stuff
and
transitioning
into
C
IDs
we're
hoping
to
clean
up
our
docks
a
lot
and
because
we're
still
a
beta
release.
We
haven't
actually
gone
to
yet.
A
B
A
Kubernetes
SIG's
Service
Catalog,
that's
our
main
repository
that
contains
the
code
for
the
API
server,
the
controller,
the
CLI,
pretty
much
everything
open
service
broker,
API
to
org.
That's
the
main
website
that
lists
information
about
the
AHS
batli
spec,
which
is
what
we're
in
implementation
of
and
then.
Finally,
if
you're
interested
in
contributing,
we
host
weekly
sig
meetings
on
Monday
at
9:00
a.m.
PST
as
well
as
we
have
people
available
in
our
slack
channel,
pretty
much
around
the
clock
around
the
world.
C
A
So
that's
sort
of
a
report,
an
admission
controller
that
would
be
a
replacement
for
user
provided
services,
but
that
wouldn't
I
don't
know
how
you'd
represent
the
sort
of
the
full
workflow
on
that.
So
you're
still
gonna
have
to
interface
with
this
broker,
which
is
some
exterior
server
that
controls
the
provisioning
and
access
to
these
services.
Whatever
they
may
are
an
admission
controller.
A
If
you
got
rid
of
Service
Catalog,
you
wouldn't
have
the
types
to
manipulate,
so
you
would
have
to
interface
with
a
broker
directly
to
get
the
credentials
and
then
put
that
into
a
pod,
preset
and
I.
Don't
think
I
could
I
wouldn't
have
a
reasonable
expectation
that
an
application
developer
would
sit
there
and
write
curl
requests
manually
of
a
broker,
so
you'd
have
to
implement
something
a
bit
fancier
and
at
that
point
you're.
Basically
just
reimplemented
Service
Catalog
in
an
admission
controller,
so
I
don't.
D
A
Sorry,
it
seems
I
I
might
have
forgotten
to
explain
a
bit.
Okay,
so
we're
an
extension
project.
While
we
have
an
AAA
API
server,
we
are
not
in
the
API
server.
We
exist
as
an
extra
API
server,
that's
aggregated
into
the
main
kubernetes
api
server
namespace.
So
we
don't
exist
in
the
same
code,
is
the
regular
API
server
and
we
aren't
really
adherent
to
the
same
restrictions.
A
D
B
A
Don't
really
maintain
a
list
of
the
available
brokers,
because
it's
kind
of
a
like
there's
way
too
many
to
count
so
I
personally
work
for
IBM
I
know
on
our
cloud.
We
have
something
on
the
realm
of
like
300,
plus
different
services,
that's
available
just
from
our
brokers,
and
we
know
of
you
know,
hundreds
more
and
they're
available
on
the
internet
from
various
companies,
cloud
providers,
etc,
etc,
who
offer
their
services
via
OS
via
API.
A
B
A
That
is
true.
We
don't
so
the
API
itself
does
have
a
mechanism
to
include
you
know
more
elaborate
information
like
billing
information
or
such
on
and
so
forth,
and
a
lot
of
the
major
cloud
providers.
Clouds
do
end
up
doing
that
in
some
way.
I
don't
really
work
on
the
close
source
sites
of
things
like
I,
know,
I
know,
IBM
cloud
specifically
does
that
we
have
integration
that
allows
the
billing
information
to
get
passed
through
the
whole
workflow
and
to
the
broker
and
back
I.
C
A
An
application
developer
so
really
the
only
thing.
That's
a
like
cluster
operator.
Restricted
action
is
creating
the
broker
and
that's
usually
because
when
you
add
a
broker,
the
system,
all
of
the
services
that
broker
offers
are
going
to
become
available
to
usually
everyone
who
accesses
the
cluster.
So
both
the
provisioning
of
the
instance
and
the
provisioning
of
the
binding
are
usually
something
that's
up
to
the
individual,
app
developer.
Okay,.
C
A
A
Technically,
yes,
normally
these
brokers,
like
I,
said,
have
more
involved
like
billing
systems
and
information
that
flows
through
the
system
like
the
identity
of
the
user
and
so
on
and
so
forth.
So,
while
in
a
naive
implementation
of
a
broker,
yes,
a
user
can
provision
as
many
resources
as
they
want
in
the
actual
world
with
actual
brokers.
No,
that
is
that's
not
really
the
case.
Okay,.