►
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
Intro to SIG Service Catalog - Jonathan Berkhahn, IBM & Mateusz Szostok, SAP
This is an introduction to the Kubernetes Service Catalog extension project. Service Catalog lets you provision cloud services directly from the comfort of native Kubernetes tooling, regardless of where the service is actually hosted. Service Catalog is a Kubernetes implementation of the Open Service Broker API, an open standard to provision and manage cloud services. Come learn how you can use Service Catalog to access third-party services from your Kubernetes applications or to offer your service to Kubernetes users. We will walk through provisioning a relational database through Service Catalog and and then connect to it from an application running on Kubernetes.
https://sched.co/UaiQ
A
A
Sa
P
I'm,
a
chair,
he's
a
chair.
We
both
work
on
Service
Catalog
so
before
I
get
into
what
exactly
Service
Catalog
is
I
want
to
talk
a
bit
about
the
problem
it's
trying
to
solve.
So
in
a
cloud
native
platform
like
kubernetes
people
who
write
applications,
they
want
to
run
on
kubernetes
and
these
applications
are
not
usually
completely
monolithic
applications.
They
also
interface
with
services
other
pieces,
whether
that's
like
a
relational
database
or
some
API
subscription
it
needs
or
like
billing
system.
A
It's
not
just
one
monolithic
Island,
it's
a
network
of
lots
of
little
islands
that
are
all
connected
together
and
these
services
are
often
completely
messed.
My
app
can
function
without
them.
I
need
a
database
back-end
to
store
my
data
in
and
keep
it
around,
and
if
I
don't
have
that
database,
my
application
just
isn't
going
to
work
so
they're
100%
required
for
my
application
to
function,
but
beyond
the
fact
that
my
application
needs
them
I
as
an
application
developer,
probably
don't
care
about
them
that
much
as
long
as
I
have
a
database.
A
B
A
It's
running
or
who's
managing
it
as
long
as
it's
his
hearing,
whatever
SLA
is
I
had
in
mind
when
I
developed.
My
app
I'd
also
I
want
to
talk
a
bit
about
that
term
services
so,
especially
in
kubernetes.
That
term
I
find
is
a
bit
overloaded,
especially
because
kubernetes
itself
has
this
notion
of
a
service
which
is
an
object
type
within
kubernetes
itself
that
it
uses
to
represents
some
application
running
somewhere.
The
cluster
can
see
using
DNS.
A
Now,
that's
that's
not
exactly
what
I
mean
today
when
I'm
saying
service
these
two
second
definitions
or
closer
to
what
I
mean
when
I
say
service.
So
we
have
the
idea
of
sort
of
a
platform
managed
or
hosted
service
like
object,
storage
like
s3
on
AWS
or
a
service,
that's
totally
external
to
any
cloud
platform
like
Twilio,
which
is
a
third
party
app
api
on
the
internet.
That
means
you
make
phone
calls
with.
So
that's
that's
more.
A
What
I'm
sort
of
thinking
of
some
sort
of
generic
thing
that
I
mean
I
can
see
it
from
my
cluster,
but
it's
not
necessarily
just
like
some
IP
address
that
I
can
access
via
DNS
discovery
and
accessing
these
services
is
a
non-trivial
task,
so
I'm
an
application
developer,
I
wrote
my
application
I'm
running
it
in
the
kubernetes
cluster
somewhere
and
I
need
a
database.
How
like
what
are
all
the
steps?
I
need
to
take
into
account
to
connect
my
app
to
that
database.
I
need
to
set
up
the
database.
A
I
need
to
have
a
team
of
people
who
sit
there
and
watch
it
and
make
sure
it
doesn't
catch.
Fire
I
have
to
have
some
sort
of
ecosystem
to
manage
access
the
credentials
to
physically
access
that
database,
and
then
you
know,
presumably
I
don't
want
to
just
pass
around
a
sticky
note
that
has
the
password
to
the
the
production
database
around
the
office.
So
there's
there's
a
lot
of
cruft
and
infrastructure
that
has
to
be
created
to
manage
all
of
this
and
again
I.
A
Really
don't
care
about
this
database
like
I
need
it
to
exist,
but
I,
don't
I.
Really
don't
care
about
it
beyond
that?
What
I
really
actually
should
be
caring
about.
Is
writing
my
application
I'm
an
application
developer
database
developer,
so
the
idea
of
Service
Catalog
is
what
if
we
can
take
the
burden
of
all
of
that
stuff.
That
needs
to
happen
and
offload
it
back
on
the
platform.
So
the
platform
can
manage
it.
A
Information
anything
so
here's,
here's,
the
the
quick
elevator
pitch
of.
Why
would
I
want
to
use
service
catalog?
So
what
if
I
told
you
right
now
today,
you
can
run
these
three
commands
and
get
a
my
sequel
database.
So
this
first
one
SV
cap
marketplace
is
show
me
all
the
things
that
are
available
for
me
to
use
on
my
cluster.
In
this
case
we
have
two
services,
my
sequel
of
MongoDB
and
a
couple
different
flavors
of
them
and
I'm.
Like
sure,
I
want
to
my
sequel
database
provisioning
me
in
my
sequel
database.
A
I'm
gonna
pick
one
of
these
t-shirt
sizes
off
the
list.
Free,
it's
gonna,
go
on
provision
in
the
database
and
again
I,
don't
really
care.
How
and
I'm
like
sv
cap
bind
my
database
and
I'm
gonna
get
a
secret
called
my
database.
That's
gonna
have
credentials
to
access
a
real
live
running.
My
sequel
database
and
I
can
just
use
that
my
application.
So
that's
that's.
A
What
we
deliver-
and
this
talk
today
is
to
try
and
explain
exactly
how
that
happens
in
the
backend
and
why
you
would
want
to
use
it
so
what's
actually
going
on
in
the
backend.
There
is
at
some
point.
In
the
past,
a
cluster
admin
has
connected
something
called
a
service
broker
with
Service
Catalog.
Now
the
service
broker
is
an
independent
server
outside
of
kubernetes.
It
could
be
an
application
running
on
kubernetes,
but
it
doesn't
have
to
be,
and
each
of
these
brokers
is
responsible
for
one
or
more
services.
A
A
We
query
that
broker
and
be
like
okay
show
us
all
the
stuff
you
sell
and
make
that
available
in
that
marketplace.
Then,
at
a
later
time,
application
developer
who's
using
that
kubernetes
cluster
says
I
need
a
service.
Show
me
all
the
services
that
I
can
pick
pick
one
provision
it
bind.
It
use
the
secret.
A
You
know
specified
that
the
broker
has
to
provide
and
the
platform
has
to
consume
in
order
to
control
the
information
flow
of
all
this
service
information,
and
the
point
of
this
is
to
abstract
the
lifecycle
of
managing
a
database
or
a
Billings
subscription
service
or
whatever
into
something
that
the
platform
can
consume.
Now
the
service
broker
itself
does
have
to
actually
care
about.
A
The
nitty-gritty
of
what
is
deploying
my
sequel
database
is
actually
mean,
so
there
is
somebody
who
still
has
to
worry
about
that,
but
it's
no
longer
the
application
developer,
who
has
to
you
know,
do
that
stuff.
In
the
same
way
they
deploy
manage
the
lifecycle
of
their
application.
That
can
be
abstracted
away
to
someone
who
probably
actually
cares
about
that
thing.
A
Like
company,
that
sells
my
sequel,
databases
or
the
infrastructure
provider
who's,
also
managing
the
cluster
itself,
so
Hughes
create
delete,
provide
credentials
that
can
also
have
extensions
like
Auto
scale,
backup,
depending
on
whatever
the
service
actually
is,
and
that
broker
like
I
said,
can
live
anywhere.
It
could
be
running
on
top
of
the
same
kubernetes
cluster
that
my
application
is
eventually
deployed.
On
top
of
it
could
be
running
on
a
rack
in
the
same
data
center
as
that
kubernetes
F
cluster.
A
A
So
what's
the
upside
of
all
this
so
like
I
mentioned,
if
I'm
a
kubernetes
application,
developer,
I-
probably
care
mostly
about
my
application
and
I
yeah-
and
you
know
these
services,
but
I,
don't
really
care
about
them.
This
allows
them
to
be
managed
by
the
experts,
people
who
do
actually
care
about
them.
This
sort
of
self-service
model
speeds
up
both
the
potential
for
CI
and
automating
these
things.
So
you
can
have
a
more
realistic
framework
running
in
your
test.
You
know
with
live
databases
or
whatever
the
platform
can
do
more
for
you.
A
So,
like
I
said,
if
you're
running
on
kubernetes
right
now,
you
will
have
this
one
broker
that
offer
services
that
you
like.
If
you
go
to
a
totally
separate,
kubernetes
cluster
or
provider,
if
they
also
have
service
catalog,
they
can
hook
it
up
to
the
same
broker
and
you
might
can
access
the
same
services
in
the
same
way.
A
If
you
go
to
even
some
other
platform
that
also
implements
as
bappy,
they
can
consume
the
same
brokers
at
the
same
time,
if
you're
a
service
provider,
this
is
also
a
huge
boon
because
it
allows
you
to
very
easily
access
new
customers.
All
the
people
who
use
kubernetes
would
be
able
to
buy
your
thing.
If
you
offer
it
via
a
broker,
you
can
offer
it
to
different
platforms
if
you
wanted
to,
and
hopefully
that
would
be,
you
know
very
easy
to
see
an
increase
in
the
potential
users
for
your
service,
whatever
it
is.
A
C
D
A
Sequel,
Postgres
read
a
whole
bunch
of
data
stores
and
I'm
gonna
go
ahead
and
provision
one
I'm,
gonna,
say:
I
want
my
sequel
so
to
sort
of
peel
back
the
the
mystery
of
what's
actually
going
on
here.
So
this
particular
broker
that
I
have
installed
is
actually
a
application
running
on
top
of
the
same
kubernetes
cluster.
It's
a
pod
that
I
deployed
manually
it's
running
on
my
kubernetes
cluster
and
then
I
registered
it
with
Service
Catalog.
Now
these
t-shirt
sizes,
these
plans
are
actually
held.
A
Chart
version
numbers
because,
what's
actually
happening
on
the
back
end
of
this
broker,
is
when
I
provision
this.
My
sequel
instance
like
I'm
about
to
it's
gonna,
go
provision,
helm
char
at
five,
seven
fourteen
of
V,
my
sequel,
DB
helm
chart.
So
that's
how
this
broker
in
particular
works.
So
the
end
result
of
me
asking
it
to
provision
that
is
going
to
be
some
pods
get
spun
up
on
the
scoober
Nettie's
cluster
and
I'm
gonna
have
credentials
to
access
them,
but
that's
not
a
requirement.
A
That's
how
this
specific
broker
works,
but
instead
of
pods
running
on
this
kubernetes
cluster,
like
I,
said
it
could
be
its
provisioning,
a
new
database
on
some
bare
metal
servers
in
a
data
center
somewhere
it
could
be
cutting
off
a
slice
of
a
pre-existing
large
database
in
a
data
center
somewhere.
I
don't
happen
to
know
I
don't
have
to
care,
that's
really
up
to
the
broker
offer
to
figure
out
so.
A
A
It's
provisioning,
a
pod.
You
can
also
see
the
broker
itself
down
here,
a
mini
broker,
so
it's
gonna
take
a
couple
seconds
to
come
up
here.
We
are
and
then
I'm
gonna
go
ahead
and
bind
to
it,
so
the
instance
is
sort
of
the
service
itself.
Whatever
that
means
a
binding
is
a
unique
set
of
credentials
to
access
that
service.
Whatever
that
means.
A
A
What
do
we
got?
We
got
user
name
and
password
the
my
sequel
password,
the
port.
It's
running
on
all
the
information
that
I
would
need
to
consume
that
service
and
that
that
was
it.
That
was
you
know
two
lines
and
I
have
a
running
my
sequel
database
and
I.
Don't
really
have
to
care
about
all
of
that
infrastructure
that
I
would
have
to.
If
I
was
maintaining
this
myself,
the
secrets
right
there
in
kubernetes,
presumably
if
your
kubernetes
application
developer,
you
already
have
expertise
in
dealing
with
secrets
to
contain.
A
A
All
of
that
work
fly
just
did
used
SV
cat,
which
is
a
tool
that
a
CLI
that
we
have
written,
but
everything
I
just
did
was
kubernetes
normal
interaction
out
of
the
covers.
So
if
I
wanted
to,
I
could
have
done
that
manually
by
coop,
creating
a
whole
bunch
of
VMO
to
represent
those
objects,
so
I
would
have
instead
of
provisioning.
A
service
I
could
have
created
a
service
instance
that
had
the
class
of
plan
as
tags
in
there
in
the
animal
and
then
done
the
same
for
the
binding.
A
The
end
result
would
have
been
the
same
now.
The
SV
cat
tool
is
just
a
sort
of
little
thing
to
make
it
easier,
but
if
you,
you
know
Yambol
all
the
things
and
that's
how
you
interact
with
kubernetes.
That's
the
same
way.
You
can
interact
with
service
catalog,
ok,
so
sort
of
summing
up.
Why
would
I
want
to
use
service
catalog?
You
would
want
to
use
service
catalog
to
help
developers
discover
interact
with
connect
with
third-party
services,
so
they
don't
have
to
care
about
them.
A
They
can
focus
on
what
they
should
care
about,
developing
their
application.
At
the
same
time,
service
providers
care
about
it
because
they
can
utilize
it
as
a
way
to
more
easily
connect
with
more
customers.
So
more
people
can
consume
their
stuff
and
then
the
projects
itself
we're
a
community
incubator
project,
we're
currently
in
kubernetes
sig
we're
a
beta
release.
A
We
have
a
helmet
art
to
deploy
a
thing
and
kubernetes
cluster
and
we're
in
currently
in
a
beta
release
and
again
so
I
would
allow
select
to
mention
most
of
the
examples
I
talked
about
today,
we're
in
the
context
of
a
database
of
some
sort
or
a
datastore,
and
that's
sort
of
the
archetypal
example
we
like
to
use.
But
what
a
service
can
represent
is
pretty
malleable.
It
could
be
any
kind
of
static
storage,
it
could
be
integration
with
some
sort
of
external
API.
It
could
be
infrastructure.
A
You
know,
sort
of
around
there
kubernetes
cluster
inside
the
cloud
infrastructure
of
the
whatever
provider.
It
could
be
something
more
esoteric
like
an
auto
scaling
service
that
actually
reaches
back
into
your
kubernetes
cluster
and
adjusts
knobs
for
you
anything
that
can
be
decomposed
into
that
sort
of
workflow
can
be
represented
as
a
service.
If
you're
interested
in
the
more
specifics
of
how
the
API
works
feel
free
to
come
to
a
deep
dive
session
tomorrow,
I
think
it's
in
the
same
room,
actually
we're
going
to
talk
a
little
bit
more
about
it.
Oh
yeah.
A
D
A
F
A
So
the
question
is:
I
already
have
an
operator
that
provisions
register
clusters.
How
can
I
use
that
with
service
catalog,
so
I'm
assuming
this
is
from
the
perspective
of
you-
want
to
offer
these
Redis
clusters
to
other
kubernetes
users
to
PCF,
ok,
so
you're,
actually
in
luck
and
that
Cloud
Foundry
is
actually
where
OSP
API
was
spun
out
of,
they
also
consume
brokers.
A
So
if
you
wanted
to,
you
could
write
a
broker,
that's
a
front-end,
so
a
web
server
that
specifies
the
five
endpoints
catalog
provision
of
service
bind
a
service
unbind,
a
service
D
provision
of
service
that
goes
and
talks
to
your
kubernetes
on
the
backend.
So
it
would,
you
know,
push
whatever
your
CID
is
and
on
the
front
end
would
have
those
five
endpoints
and
that
would
plug
directly
into
Cloud
Foundry.
So
that
would
be
super.
Would
you
have
to
write
a
broker
like
I
said
the
Shh
yeah?
A
A
So
we
service
catalog.
Do
not
we
don't
really
it's
a
bit
beyond
the
scope
of
our
project.
You
maintain
brokers,
we
just
kind
of
implement
the
API.
If
you're
interested
I'm
going
to
wait
for
this
gentleman.
This
is
on
the
shed,
whatever
you
want
to
call
it.
Oh
it's
on
the
page.
You
can
download
this
in
PDF,
so
service
catalog
does
not
the
open
service
broker
API
working
group
does.
If
you
go
here,
there
should
be
a
link
to
our
github
somewhere
I.
A
Don't
remember
exactly
where
it
is
in
here,
but
yeah.
We
have.
We
have
example,
brokers
as
well
as
like
conformance
test
suite,
so
you
can
like
give
it
a
broker
and
be
like.
Is
this
adherent
to
the
spec,
yes
or
no,
as
well
as
us,
like
swagger
specifications
of
the
API?
That
will
generate
an
example
code
for
you.
So
but
that's
that's
like
a
OSB
thing,
not
a
service
get
one
thing.
E
Thank
you.
So
the
question
is:
can
I
have
different
back-end
implementations
across
different
cloud
providers
for
the
same
sort
resource
and
posing
like
my
sequel,
yeah,
I'm,
sorry
trading,
RDS,
Alec
cloud
and
creating
the
other
cloud?
One
I'm
pre
me
doing
containers
my
super
all
expose
through
the
same
service.
So
it's
agnostic.
My
end
users
sure.
A
So
the
question
was:
can
I
have
different
back-end
implementations
that
are
opaque
to
the
end
user?
The
end
consumer
of
the
services
so
I
want
to
have
my
like,
for
instance,
my
single
databases,
one
of
them's
offered
on
pram,
one
of
them's
offered
in
the
cloud
one
of
them's
offered
dedicated
something
or
other
yeah.
So
me
take
a
step
back.
A
So
these
services
are
decomposed
into
a
permutation
of
classes
and
plans,
so
the
broker
I'm
using
here
each
class
is
the
different
databases.
This
broker
offers
and
the
plans
are
different,
helmet
art
versions
of
what's
actually
getting
deployed
in
the
back
end.
But
all
of
that
stuff
is
totally
up
to
the
broker
author
to
define
and
say
what
that
means,
so
it
could
have
instead
of
having
you
know,
these
different
help.
Chart
versions
of
Redis
I
could
have
one
plan,
that's
dead.
A
You
know
on
pram
one
plan,
that's
on
the
cloud
one
plan,
that's
whatever
or
I
could
have.
You
know
a
whole
bunch
of
plans.
It's
like
this
one's
on
pram
and
has
I,
don't
know
uptime
guarantee
of
99%
or
this
one.
You
know
whatever
that's
totally
up
for
the
broker
author,
that's
totally
transparent
to
the
user.
They
don't
have
to
know
or
care.
So
yes,
the
answer
is,
you
can
do
all
of
those
things.
C
Do
you
have
to
write
a
custom
broker
to
mix
that
those
sort
of
remote
managed
database
services
with
the
local
offered
ones,
or
does
it
just
naturally
mix
it?
If,
if,
if
you
had
a
broker,
if
you
were
subscribed,
I
guess
to
a
broker
that
provided
Amazon
services,
and
then
you
also
had
some
local
like
mini?
What
is
this
called
mini
broker
so
yeah?
Oh.
A
Exactly
well
sort
of
yes
and
sort
of
now
so
right
now,
this
mini
broker
I
have
is
installed,
is
just
a
single
broker.
It's
all
the
services
on
my
cluster
are
coming
from
that
broker.
If
I
theoretically
installed
amazon's
broker
and
they
also
sold
my
sequel
databases,
it
would
show
up
here.
Has
you
know
whatever
they
called
their
service?
Maybe
AWS
my
sequel
and
that
would
be
transparent
to
the
user.
All
they
see
is
the
classes
and
plans
that
are
available
to
them.
It
doesn't
say
which
broker
it's
coming
from.
A
You
know,
there's
there's
various
fields
in
the
descriptions
of
these
services.
This
is
sort
of
the
ten
mile
up
thing.
There's
more
stuff.
You
can
read
about
these
services,
so
they
could,
you
know,
say
Oh
AWS,
my
sequel.
Let
me
read
about
that.
It'll
say
you
know,
this
is
Amazon's
my
sequel
and
they
read
my
sequel
and
they're
like
oh,
this
is
the
mini
Broker.
This
is
just
you
know,
pushing
pods
here
in
the
kubernetes,
so
that
could
all
be
on
the
same
system.
A
B
A
A
Okay,
so
in
cobb
foundry
there's
this
notion
of
a
user
provided
service
which
is
rather
than
starting
with
a
broker
of
the
lifecycle
I'm
going
to
sort
of
shortcut
directly
to
creating
an
instance,
so
I'm
gonna
say
create
my
user
provided
service
and
at
that
provision
time,
I'm
going
to
pass
in
the
credentials
of
this
is
actually
a
preexisting
database
somewhere
when
I
create
a
buying
to
these
incidents.
Throw
these
back
up
at
me.
Now.
We
currently
don't
have
that
feature.
It's
something
we
talked
about
implementing,
so
no
not
currently,
but
it's
why
happen.
G
Yeah
my
question
is
like,
if
is
a
new
developer,
and
he
wants
to
start
using
the
marketplace
or
the
service
catalog
through
the
marketplace.
Is
there
a
way
for
the
user
to
query
for
the
particular
service?
This
is
maybe
not
how
is
configured
or
anything
but
the
capabilities
or
things
like
that
or
the
user,
because
you
just
show
the
example
for
my
sequel,
but
maybe
you
want
to
know
a
little
bit
more
about
my
sequel.
Is
there
a
possibility
to
learn
about
it
or
so.
A
A
A
H
So
is
there
a
once
you
get
the
credentials
and
a
secret?
Is
there
kind
of
a
best
practice,
for
you
know,
thinking
about
applications
moving
towards
adopting
a
service?
How
that's
rolled
into
kind
of
a
home
rolled
configuration
scheme
like?
Is
it
more
compatible
with
an
application
being
configured
via
like
environment
variables
or
command-line
arguments
or
a
configuration
file,
or
is
it
just
freeform?
It's.
A
Pretty
freeform
so
currently
today,
right
now,
the
form
of
that
secret
is
totally
up
to
the
service
broker
author.
So
what
it
could
be
is
pretty
up
in
the
air.
It's
usually
gonna,
be
you
know
some
form
of
username
password,
hostname
port,
something
like
that.
As
for
how
you
actually
consume
that
secret,
no,
we
currently
don't
make
any
stipulations.
There's
no
sort
of
the
best
practices
on
that,
and
that's
for
the
moment,
sort
of
beyond
the
scope
of
Service
Catalog
itself.
Now
I'm
I'm
also
contributed
to
the
OSB
API
itself.
A
I
can
let
you
know
about
the
plans
over
there,
where
we're
currently
in
the
process
of
coming
up
with
an
idea
of
how
to
introduce
more
structure
to
that,
so
that
it
would
there
would
be
a
best
practices.
The
current
working
idea
that
was
kind
of
hashing
out
is
a
broker
author
would
be
able
to
electively
say
you
know
this
I
sell
my
sequel,
databases.
A
My
credentials
adhere
to
the
database
credentials
format,
and
that
would
mean
something
that
mean
it
would.
You
know
look
exactly
like
this
and
they
have
to
have
these
fields
that
are
named
this,
so
that
the
the
eventual
consumer
would
know
what
they're
getting.
But,
that's
again,
that's
that's
currently
in
the
works.
Okay,.
H
Then
we'll
kind
of
follow
on
so
you
put
up
there
and
your
your
list
of
you
know
what
a
service
could
represent
and
you
had
like
volumes
and
networking
things
like
that.
So
I,
don't
guess
I,
don't
know
for
those
kinds
of
things
if
credentials
should
be
the
output
so
through
the
open
service
broker.
Api
is
the
result
of
like
a
binding,
not
necessarily
a
secret,
as
I
completely
kind
of
up
to
how
the
brokers
implemented.
Sure.
A
So
right
now
I
have
to
go
check,
so
it
is
you're
right.
It
is
potentially
based
on
what
the
service
is
that
binding.
Could
not.
It
could
return
nothing.
You
could
just
be
like.
Yes,
the
binding
happened,
but
no
I
don't
have
any
information
to
give
you
I,
don't
I,
don't
know
off
the
top
of
my
head,
whether
or
not
we
still
make
a
secret.
If
it's
blank
you
might
not
I
don't
have
to
go.
Look
but
yeah.
That's
that's.
Certainly
a
reasonable
use
case.
I.
C
D
B
A
D
So
I'm
kind
of
looking
at
things
from
the
data
protection
availability
point
of
view,
so
I'm
curious,
like
after
you
set
up
something
a
service
here.
Is
there
you
know
what
are
your
thoughts
on?
You
know
disaster
recovery
afterwards,
you
know,
would
it
just
come
up
if
we
backed
up
the
kubernetes
namespace
with
all
the
resources
be
there
properly
or
is
there
something
that
service
catalog
would
need
to
be
involved
in
to
bring
the
service
back
up
so.
A
That's
sort
of
depends
so
if
whatever
the
broker
is
actually
doing
in
the
backend,
is
totally
exterior
to
the
kubernetes
cluster.
So
if
this
is
my
sequel
database
is
you
know,
and
somebody
datacenter
on
the
internet
somewhere,
then
all
of
the
information
about
accessing
that
service
will
be
persisted
as
long
as
the
namespace
is
backed
up
and
if
your
cluster
explodes
and
you
restore
it,
it
should
work
everything
like
you
know.
The
database
is
still
out
there
on
the
internet.
Somewhere
we
backed
up
the
credentials
to
access
it.
That
should
just
work.
A
D
A
A
Currently,
I
believe
it's
technically
possible
to
write
a
broker.
That's
entirely
stateless,
so
it
just
passed
through
passes
through
to
whatever
the
infrastructure
layer
layer
of
whatever
it's
a
provisioning
is
so
again
I
guess
the
answers
depends.
It
depends
on
how
you
wrote
your
broker.
It
depends
on
how
smite
roker
author
was,
but
it's
currently
possible.
Yes,
okay,.
A
So,
like
I
said
currently,
no,
we
only
output,
we
have
as
a
secret
we're
currently
planning
on
having
increased
integration
with
an
actual
pot
or
deployment
and
no
I
don't
think.
We
currently
have
any
plans
to
do
more
at
closer
integration
with
the
kubernetes
secret
again,
because,
as
I
mentioned,
while
for
the
archetypal
example
of
a
database,
you
know
yes,
it'll
come
out
of
some
kind
of
end
point.
Some
kind
of
networking
end
point
that
doesn't
have
to
be
the
case.
It
could
be
something
weirder.