►
From YouTube: Hybrid Cloud Powered by Kubernetes [I] - Aparna Sinha, Eric Brewer & Matthew DeLio, Google
Description
Hybrid Cloud Powered by Kubernetes [I] - Aparna Sinha, Eric Brewer & Matthew DeLio, Google
Open Source Software (OSS) is great because it gives us freedom. OSS users by nature want to roll their own on premises, and use best-of-breed services in public clouds an without lock-in. Fortunately, Kubernetes runs everywhere so developers and operators don't need to learn new technologies to run hybrid and multi-cloud applications.
In this talk, we will demonstrate the use of two new extensibility features in Kubernetes to connect legacy on-premises applications and managed public cloud services with services running on Kubernetes in both places, creating an environment where users can have the best of all worlds. We will show the type of use cases this technology enables using examples from Google's cloud platform.
About Eric Brewer
Eric joined Google in 2011 and leads the company’s compute infrastructure design, including Google Cloud Platform. He focuses on all aspects of Internet-based systems including cloud computing, scalability, containers, and storage.
As a researcher, he has led projects on scalable servers, network infrastructure, IoT, and the CAP Theorem. He has also led work on technology for developing regions, with projects in India, Indonesia, and Kenya among others, and including communications, power, and health care.
In 1996, he co-founded Inktomi Corporation and helped lead it onto the NASDAQ 100. In 2000, working with President Clinton, Prof. Brewer helped to create USA.gov, the official portal of the Federal government.
About Matthew DeLio
Matthew DeLio is product manager at Google for Kubernetes multi-cluster, networking, and storage. He's also the PM SIG representative for storage. Prior to product management, Matthew was a software engineer at Google and has worked on search and platforms. He holds and MBA from the University of Chicago.
About Aparna Sinha
Aparna Sinha leads the product team at Google for Kubernetes and Container Engine. She started and co-leads the community PM Special Interest Group (SIG) to maintain an open backlog for the Kubernetes project on Github. Aparna is currently a secondary member of the CNCF Governing Board. She has worked in enterprise software for 15+ years, and was formerly a Director of Product at NetApp. Aparna holds a PhD in Electrical Engineering from Stanford and has co-authored several technical papers during her research.
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
why
did
users
choose
kubernetes,
there's
a
lot
of
reasons,
I
think
to
start
with
the
easy
ones
like
open
source
and
they,
like
the
community,
love
the
community.
You
didn't
notice,
there's
a
lot
of
community
here
this
week.
It's
kind
of
amazing
this
is
my
third
I
guess,
my
third
coupon,
maybe
more
I,
don't
know
that
actually
been,
then
there's
the
you
know
frequent
releases
and
resource
efficiency.
A
That's
actually
what
got
Google
to
use
containers
ten
years
ago
was
really
how
many
apps
can
we
pack
in
a
fixed
number
of
machines
and
containers,
make
that
much
easier
runs
anywhere.
In
this
case,
I
mean
different
clouds
and
on-prem.
That
was
I
was
not
an
original
goal
for
Google
in
terms
of
internal
use,
but
certainly
for
external
use.
It's
important
that
we
meet
customers
where
they
are,
which
we'll
talk
about
quite
a
bit
today
and,
of
course,
what
developers
like
most
is
the
fast
deployments
now
in
2014.
A
We
had
somewhat
similar
reasons
about
why
to
do
kubernetes
at
all,
and
the
short
answer
is
we
felt
like
we
were
building
applications
internally
using
containers
and
fast
deployments
and
services
and
the
rest
of
the
world
wasn't
really
doing
it.
The
way
we
thought
they
could
and
we
felt
like
here's
there's
a
platform.
Maybe
we
can
change
what
cloud
means
and
I
think
we're
actually
in
the
middle
collectively
of
changing
what
cloud
means.
A
Enterprises
have
a
few
things
they
like
about
this
all
the
same
things,
but
really
it's
it's.
This
apply,
that's
got
to
be
the
favorite
command
of
kubernetes.
Apply
right.
Do
you
do
your
stuff?
You
hit
apply,
magic,
stuff
happens
and
you
have
a
new
version
right
and
when
enterprise's
think
about
what
they
want,
both
for
themselves
and
I
moved
to
the
cloud.
What
they
want
is
really
velocity.
They
want
to
feel
like
they
have
a
good
developer,
experience
that
is
effective
and
and
frankly,
fun.
Right,
I.
A
A
Do
my
mobile
app
I
can
build
that
in
the
cloud,
but
it
still
need
to
connect
back
to
my
actual
giant
database
on
Prem
and
that's
not
gonna,
move
to
the
cloud
anytime
soon,
so
I
have
to
have
a
hybrid
solution
for
that
another
one.
That's
interesting
is
I
want
to
run
a
little
coober
days,
cluster
on
all
of
my
big
box
stores
or
all
of
my
oil
rigs
right
and
so
I.
That's
not
gonna,
be
in
the
cloud.
I'm,
not
gonna.
Put
my
oil
rig
in
the
cloud.
A
It
doesn't
work
right,
so
I
need
some
local
development
environment.
That's
consistent
across
all
these
different
sites
and
that
I
can
manage
as
a
whole
group
there's.
You
know
lots
of
jurisdictional
reasons.
I
need
to
keep
this
data
in
Germany,
or
this
data
in
Europe
I
need
to
track
all
user
data
and
keep
that
in
country
all
right
that
ends
up,
meaning
that
you
have
either
cloud
restrictions
or
more
commonly
I
have
this
data
center
that
manages
these
particular
sets
of
assets
and
they
have
to
stay
there.
A
So
we
need
some
non
cloud
solution
for
those
things.
There's
a
lot
of
other
things.
The
ones
we'll
talk
about
today
really
and
give
some
demos
of
our
local
execution
and
hybrid
services,
and
then
you
say
well
what
do
you
really
care
about?
This
is
enterprise.
You
know.
Cio
is
kind
of
top
level
view
down
and
I
think
the
ones
that
ring
true
for
me
are
this.
First,
one
moved
to
the
cloud
at
our
own
pace,
meaning
moving
cloud
is
not
something
we
can
do
in
a
week
right.
A
It's
going
to
be
five
years,
maybe
10
years
right.
So
what
does
that
mean?
That
means
I
have
a
long
period
where
I
have
to
run
in
both
places,
and
it
also
means
I
can't
not
modernize
on-prem
right.
So
the
strategy
here
is:
give
you
the
choice.
You
can
modernize
on-prem.
You
can
move
to
the
cloud.
You
can
do
any
mix
of
those
two
actions
on
a
fine-grained
basis,
kind
of
app
by
app
in
your
enterprise.
That's
the
freedom.
A
They
actually
want
right,
which
is
let
us
move
the
things
we
can
to
the
cloud
as
we
can.
Let
us
modernize
the
things
that
we
can't
so
kubernetes
in
this
context
is
about
modernizing
things
on
Prem,
because
it's
not
ready
time
for
those
things
to
move
to
the
cloud.
Yet
when
you
want
to
move
operate
in
this
way,
you
have
to
have
a
pretty
consistent
environment,
meaning
that
I
wanted
to
point
out
in
different
clouds
or
on-prem
that
the
environment
in
which
I
deploy
those
apps
have
to
be
very
consistent.
A
Otherwise,
I
have
to
write
multiple
versions
right,
so
what
we
want
to
do
is
kind
of
take
all
the
things
that
vary
by
the
environment
and
pull
them
out
of
the
source
code,
I'm
going
to
call
that
externalize
them
we'll
talk
more
about
that
in
a
minute,
and
then,
on
top
of
that,
it's
not
enough
to
run
the
app
I
need
all
the
supporting
infrastructure
of
security
and
auditing
and
how
do
I
know
where
the
keys
are?
How
do
I
manage
the
keys
and
I,
like
all
that
stuff
to
be
consistent
across
the
environments?
A
Also
like
how
do
I
have
a
policy
that
says
here's
user
access
control
to
this
data
and
that
access
control
has
to
be
implemented
consistently
on
different
clouds
and
on
Prem
right?
That's
a
good
goal,
not
easy
to
do
so.
The
strategy
we
have
to
make
hybrid
work.
It
really
has
these
two
parts.
First
realize
that
the
easiest
way
to
get
consistency
is
to
run
the
same
code
right
then
it's
consistent.
It's
not
just
consistent
at
the
API
level.
It's
actually
consistent
at
the
semantic
level,
because
the
code
determines
the
semantics
right.
A
A
A
bunch
of
open
source
right,
open
source
will
give
us
the
same
code
in
different
environments,
and
we
will
get
consistently
because
of
that
consistency,
because
of
that,
so
this
shows
up
is
kubernetes,
but
also
shows
up
as
sto
and
tensorflow
and
open
service
broker
and
we'll
talk
about
a
couple
of
those
today
and
the
second
core
idea
to
the
strategy
is
that
it's
got
to
be
based
on
services.
The
service
is
the
unit
of
placement
of
functionality.
A
If
you
break
your
app
into
many
services,
you
decide
on
a
service
basis
where
it
runs
and
some
services
will
run
on
multiple
environments
and
that's
ok
right,
the
ones
you
need
everywhere
say
like
DNS
right.
That's
gonna,
run
in
every
environment.
Right
other
services,
like
managing
your
European
user
assets,
may
only
run
in
one
data
center,
because
that's
the
only
place
that's
needed,
but
the
way
you're
thinking
about
it
is
is
creating
and
consuming
services
that
span
environments
and
we'll
show
how
to
do
that
with
open
service
Brooker.
A
A
The
key
here
is
that
all
the
things
that
need
to
vary
across
the
environment
can't
be
in
the
source
code
right,
so
we
have
to
externalize
them.
What
does
that
mean?
Well,
it
means
you
put
them
somewhere
else,
so
it
turns
out
containers
already
do
this
right.
They
actually
in
the
container,
tell
you
which
libraries
you
need
right
and
you
don't
have
to
worry
about
how
libraries
get
on
to
an
operating
system
or
onto
a
machine
right.
The
package
manet
part
goes
away,
and
that
is
something
it
will
vary
by
environment
services.
A
A
A
So
all
three
of
these
big
open
pieces
actually
give
us
some
of
this
external
ization,
kubernetes
I,
hope
you
know,
but
really
it's
decoupling
development
and
deployment.
We
can
do
all
of
our
development
stuff.
First
deploy
different
environments.
That
deployment
is
consistent.
We'll
show
that
today,
sto
is
really
a
it's.
The
envoy
routing
mesh
that
goes
under
all
services
and
because
it's
a
mesh
of
proxies
as
essentially
interposer
interposing
on
all
traffic,
which
means
that
we
can
do
access
control.
We
can
do
security,
we
can
do
authentication
of
services
to
each
other.
A
We
can
do
telemetry
so,
for
example,
if
you
wonder
the
SLO
sorry,
the
latency
distribution
of
a
service,
we
can
collect
that
at
the
proxy
does
not
again,
it
does
not
go
in
your
source
code.
It's
externalized
and
therefore
consistent
across
all
environments
and
finally,
open
service
broker
is
really
decoupling
service
providers
from
service
consumption.
A
You
know
decouple
development
and
deployment
a
couple:
traffic
management,
operational
things
setting
a
policy,
that's
what
you
get
from
sto
and
the
decouple
services
producers
from
consumers
and
we'll
show
this
open
service
broker.
Today,
where
we
produce
a
service,
that's
found
in
the
search
broker
and
then
actually
gets
consumed
and
sure
that
on
different
environments,.
A
Where
do
we
get
when
we're
all
done
with
this?
Well,
you
get
a
open
multi-cloud
way
to
deploy
applications,
but
not
just
deploy
actually
monitor
them
as
well
right.
So
all
the
things
you
get
you
want
to
know
about
your
service,
including
how
are
they're
running
latency
for
all
the
things
all
that
you
just
get
to
collect
in
a
uniform
way,
so
that
we're
gonna
move
to
the
the
fun
part
of
this
talk
with
the
Poorna
in
matt,
giving
some
demos
thank.
B
You
Eric,
that
was
amazing.
All
right,
so
Matt
and
I
are
gonna.
Do
demos
by
the
way
there
are
some
seats
up
front.
If
folks
want
to
move
in
a
little
bit,
you
know
we
can
make
room
at
the
edges.
That
would
be
great.
So
thank
you.
Eric
there
are
a
set
hybrid
abstractions
that
are
under
development
and
Matt
and
I,
and
many
of
the
Google
engineers
here
are
involved
in
them,
and
so
we're
gonna,
try
and
demo
two
of
them
here
today.
B
If
you're
a
developer,
that's
developing
an
application
that
you
want
to
deploy
on
premise
and
in
the
cloud
you
might
want
a
systematic
way
of
doing
that.
I
mean
you
could
go
sort
of
cloud
by
cloud
and
deploy
it,
but
we're
working
on
something
called
a
multi
cluster
registry,
which
is
actually
Christian.
Bell
here
is
leading
that
work,
which
is
a
component
in
the
kubernetes
open
source
project
that
makes
it
more
systematic
to
deploy
your
applications
across
clouds.
B
B
The
other
building
blocks
that
I'm
calling
hybrid
primitives
are
ISTE.
Oh
and
the
kubernetes
cluster
API.
We're
not
gonna
go
demo
those
today,
just
because
of
lack
of
time,
but
these
are
more
for
operators.
If
you
are
managing
a
large
hybrid
environment,
you
want
to
manage
the
services
and
make
sure
that
they
are
authenticated
and
credentialed.
Sdo
is
a
really
great
tool
for
that,
as
well
as
visualizing
those
services
and
then
lastly,
the
kubernetes
cluster
API
allows
operators
to
deploy
and
upgrade
clusters
in
a
consistent
way
across
clouds.
B
So,
let's
get
started
so
Matt
and
I
have
decided
that
we're
going
to
go
into
business
and
start
up,
it's
gonna
be
a
bookstore
and
it's
gonna
be
a
really
awesome.
Bookstores
and
a
half
fiction,
nonfiction
all
kinds
of
books
and
you're
actually
gonna,
be
our
customers.
You're
gonna
buy
these
books.
We've
decided
that
we
want
a
major
online
presence,
so
we're
going
to
have
you
know,
books
online
in
a
website
hosted
in
the
cloud,
but
we've
also
struck
a
deal
with
a
number
of
different
stores.
B
Hundreds
of
stores,
where
we're
gonna
set
up
kiosks
and
the
kiosks
are
going
to
be
running
the
same
application,
that's
running
in
the
cloud
and
you
can
go
there
and
you
can
purchase
your
books
in
the
store.
So
that's
the
business
we're
going
into
and,
of
course,
these
two
applications
that
are
running
on
premise
and
in
the
cloud
need
to
have
a
shared
inventory.
So
we
know
who's
buying.
What
and
how
much
more
we
need.
So
they're
gonna
write
back
to
a
shared
inventory
and
that's
what
that's.
B
What
we're
gonna
show
you,
the
hybrid
bookstore,
of
course,
given
our
heritage,
we've
decided
that
the
online
app
is
gonna,
be
Google
Cloud
and
we
do
have
some
stickers
for
you
for
Google
Cloud
later
on.
If
you
want
to
come,
get
those
and
we're
gonna
use
google
kubernetes
engine
for
this.
So
that's
where
we're
gonna
put
the
bookstore
front-end
online
in
terms
of
the
kiosks.
So
we've
had
a
donation
from
Cisco
they've.
Given
us
a
set
of
UCS
servers
on
which
they've
installed,
VMware
and
open
source
kubernetes
and
that's
gonna,
be
our
consistent
environment.
B
We're
gonna,
we're
gonna,
run
the
kiosk
app
on
those
clusters.
So
let's
get
started
and
show
you
here.
We
are
we're
in
Google
cloud
and
this
is
kubernetes
engine,
so
we
can
just
go
ahead
and
create
a
cluster
and
you
can
see
me
type
with
one
hand
and
hold
the
mic.
So
we're
gonna
create
our
cloud
central
cluster
in
the
cloud
central
cluster.
You
know,
I,
don't
want
it
to
be
a
zonal
cluster,
because
I
never
want
this
bookstore
to
go
down
so
I'm.
Actually,
gonna
choose
a
regional
cluster.
This
is
a
beta
feature.
B
Just
went
beta
on
Monday
of
this
week,
West
Hutchins-
if
he's
here
he
worked
on
this,
but
essentially
it
takes
the
control
plane
of
kubernetes
and
spreads
it
across
three
zones
by
default,
but
not
just
that.
It
also
spreads
your
nodes,
so
my
application
will
be
spread
across
three
zones
so
that
you
know,
should
there
be
an
outage
in
one
zone,
my
books
are
still
gonna
survive
and
I'm
gonna
choose
the
latest
version
of
kubernetes
because
that's
gonna
have
the
maximum
patches
and
it's
gonna
be
the
most
secure
I'm
a
startup
owner.
B
So
I'm
gonna
go
with
two
nodes
per
zone
for
a
total
of
six
nodes
in
this,
and
that's
it
and
I
can
go
ahead
and
create
it.
That's
gonna
take
a
couple
of
minutes,
so
we
have
a
pre-warm
cluster
here
in
US
central
one
called
cloud
central
as
you
can
see,
it
has
six
nodes
and
that's
distributed
across
three.
These
three
zones,
so
central
one,
a
central
1b
and
one
F,
two
nodes,
each
and
I'm
actually
gonna
login
to
this
cluster
from
this
VM.
B
B
All
right,
so
we've
got
credentials,
here's
cloud
central,
that's
running
in
gke
and
here's
the
on-prem
cluster,
that's
the
that's
the
kiosk
and
let
me
go
ahead
and
get
nodes
in
a
nice
format
for
you
for
the
for
the
cloud
central
and
it's
what
we
saw
before.
It's
got
six
nodes
two
in
each
zone
and
then
let's
also
connect
to
the
on-prem
cluster
and
see
how
that's
looking
and
what
does
that
have.
So
this
one
is
a
simple
non
H,
a
cluster.
B
It's
got
three
nodes
in
one
master
and
it's
running
a
different
version
of
kubernetes,
one
seven
and
a
different
operating
system,
and
one
of
the
things
you're
gonna
see
is
that
it's
not
going
to
matter.
Actually,
the
bookstore
app
is
going
to
run
on
both
of
these
clusters
and
the
service
catalog
is
going
to
run
on
both
of
these
clusters
and
they're.
Gonna
connect
just
fine.
B
So
now
I
could
go
ahead
and
deploy
the
bookstore
app
on
the
cloud
cluster
and
then
separately
on
the
kiosk,
but
I
have
hundreds
of
stores
that
these
kiosks
are
gonna
run
in
so
I'd
have
to
do
it
individually
and
Matt
DeLeo
who's.
My
CTO
has
been
participating
in
the
multi
cluster
sig
and
he
told
me
that
there's
this
thing
called
the
multi
cluster
registry
and
he's
created
an
image
of
it
in
GCR,
and
he
told
me
to
deploy
that
so
I'm
gonna
go
ahead
and
deploy
that,
and
this
is
how
I
deploy
it.
B
C
Thanks
Aparna,
so
one
thing
we
realized
after
talking
to
two
users
of
kubernetes
is
that
they're
already
running
multiple
clusters,
often
even
dozens
for
the
reasons
we
kind
of
enumerated
earlier.
They
really
need
a
way
to
keep
track
of
them
all.
They
need
a
way
to
perform
operations
on
the
on
a
subset
of
them
or
maybe
on
all
of
them
and
they're
right
now.
C
What
they're
doing
is
a
lot
of
them
are
using
hard-coded
lists,
maybe
checked
in
to
get
or
maybe
files
on
network
resources
that
they
kind
of
share
between
between
operators
and
CD
tools
and
what
the
cluster
registry
is.
It
allows
users
to
kind
of
have
a
centralized
store
of
their
clusters.
They
can
define
labels
that
they
can
then
use
to
filter
and
enumerate
the
clusters
that
they
want
to
perform
these
operations
on
and
in
in
terms
of
the
sig.
You
know
it's.
C
B
C
We've
applied
a
few
labels
to
this
cloud.
Central
cluster
we've
got
the
app
bookstore,
so
it's
going
to
indicate
that
we're
gonna
deploy
our
book
store
app.
There
we've
set
the
provider
type
to
cloud
and
we
have
a
zone
for
it.
Since
we
said
it
was
going
to
be
a
che,
we
hadn't
went
ahead
and
marked
it
as
a
che.
So
we
can
kind
of
you
know
again
keep
track
of
all
the
things
we
care
about
with
the
cluster
and.
C
B
By
attaching
this
metadata
to
these
clusters,
when
we
go
ahead
and
we're
gonna
switch
context
to
cluster
registry
and
then
apply
these
yamo
files
to
register
these
clusters,
as
well
as
a
set
of
fake
clusters
to
model
the
hundreds
of
stores
that
you
know
we're
gonna
have
kiosks
in
we're.
Gonna
register
all
of
those
now
with
the
cluster
registry.
So
now
we've
got
a
central
database
that
has
all
of
our
clusters
and
let's
see,
get
clusters.
So
now
we're
running
this
against
the
cluster
registry
API,
and
we
see
that
we've
got
cloud.
B
C
So
let's
go
ahead
and
filter
our
list
down
to
figure
where
we
want
to
deploy
our
book
store
app
so
gives
us
the
two
clusters
there's
a
little
bit
of
obscuration,
but
it's
it's
cloud.
Central
and
an
on-prem
is
the
second
one,
and
thanks
sorry
about
that
and
then
so,
let's
go
ahead
and
Whittle
it
down
a
little
bit
more.
Let's
deploy
to
our
cloud
one
okay,.
B
So
we're
in
a
switch
contest
to
the
cluster
registry
up
to
cloud
central
and
then
start
to
deploy
our
book
store
app,
and
so,
let's
take
a
look
at
our
book
store
app.
It's
got
the
usual
services
that
you
would
expect.
It's
got
a
front-end
deployment
and
service.
It's
got
an
inventory
service
and
deployment
user
service
and
purchase
service.
So
that's
looking
good
I
think
we
can
go
ahead
and
create
a
namespace
for
it
and
then
apply,
and
this
is
the
power
command
rights
cube,
could
all
apply
and
everything
in
that
registry
and
pretty
much.
B
What
looks
like
the
user
service
is
up,
the
purchases
service
is
up,
the
inventory
service
is
up,
but
the
bookstore
front
end
didn't
deploy
and
we
could
wait
for
it
to
deploy,
but
it's
actually
not
going
to
deploy
and
that's
because
we
want
to
show
you
the
feature
here.
The
book
store
app
actually
has
a
dependency
that
doesn't
exist
yet,
and
so
it's
not
going
to
deploy
until
that
dependency
is
met.
So
let's
go
into
the
deployment.
C
C
C
B
Right
we
talked
about
the
front
end
and
in
both
of
the
locations
you
know
publishing,
what's
happening
with
the
inventory
and
we're
gonna
use
pub
sub
for
that,
so
we
are
gonna
need
the
pub
sub
service
as
well
as
the
I
am
credentials.
These
are
dependents
right.
These
are
third-party
services
that
you
might
want
to
use
in
your
application.
B
So
what
we
could
do
now
is
we
could
go
to
cloud
platform
and
we
could
set
up
a
pub
subtopic
and
we'd
have
to
learn
the
semantics
of
that
or
we
can
and
then
we'd
also
have
to
get
an
iamb
service
account
and
so
that
we
could
get
credentials.
So
we
could
do
all
of
that
or
there
is
a
simpler
mechanism.
I
think
we
Eric
talked
about.
You
know
the
open
service
broker
API.
B
This
API
provides
a
standard
way
to
instantiate
and
consume
any
service
and
GCP
Google,
Cloud
and
other
clouds
can
create
and
any
any
provider
frankly
can
create
brokers
into
which
they
publish
these
services,
so
that
users
like
Matt
and
I
are
trying
to
start
a
bookstore
can
go
and
discover
these
services
and
connect
to
them
without
having
to
worry
about
the
specific
semantics
of
each
service,
and
so
the
GCP
service
broker
is
actually
live.
It's
an
early
access.
B
We're
actually
going
to
use
the
service
catalog
to
deploy
the
Service
Catalog
I
need
to
be
a
super
user
in
the
cluster,
so
I
am
going
ahead
and
giving
a
PC.
Now.
That's
me
admin
rights
to
the
cluster,
and
then
I
can
run
this
powerful
command
se
install
and
that
is
going
to
install
a
service
catalog,
which
will
then
give
me
access
to
the
full
service
broker
that
UCP
publishes.
So
now,
let's
see
if
that's
installed,
it
usually
takes
a
little
bit.
B
So
it's
not
done
yet
so
the
controller
manager
and
the
API
server
is
still
coming
up
and
what
is
the
service
catalog
really.
So
this
is
quite
it's
quite
a
powerful
mechanism.
It's
using
cube
aggregator,
which
is
a
way
to
add
and
extend
the
kubernetes,
api,
natively
and
so
what's
happening,
is
that
the
service
catalog
is
deploying
as
a
separate
API
server
with
its
own
controller
manager,
and
it's
at
CD
backup
store
it's
deploying
in
one
of
the
nodes
in
the
cloud
central
cluster.
B
But
the
more
important
thing
is:
it's
also
registering
with
the
master
of
the
cluster
and
so
it'll
become
an
extension
to
the
normal
kubernetes
api
and
I'll
be
able
to
access
the
Service
Catalog
features
just
like
I.
Do
you
know
anything
else
in
kubernetes
and
that's
really
the
Kubb
aggregator
extensibility
functionality.
So,
let's
see
what
do
we
got
now.
B
B
So
let
me
now
show
you
this
actually
in
the
UI.
So
if
I
go
to
kubernetes
engine
there's
this
thing
called
service
instances
and
I
can
go
to
service
instances.
You
have
to
be
part
of
the
EAP
program
and
then
I
can
click
on
browse
Service,
Catalog
and
in
here
I
should
see
all
of
the
services
that
the
GCP
service
broker
publishes,
and
this
list
is
gonna
get
longer
over
time.
But
here
you
can
see
that
Google
is
providing
all
of
these
services
through
the
open
service
broker.
B
So,
let's
see
you
see
the
same
set
of
services
here
in
the
command
line,
and
now
I'm
gonna
go
ahead
and
create
an
instance
of
the
GCP
I
am
service
in
the
bookstore
namespace,
so
that's
been
created
and
then
similarly
an
instance
of
the
pub/sub
service
and
that's
been
created,
and
actually
this
is
going
to
run
a
little
bit
in
the
background.
So
I
am
instance
has
been
provisioned
and
let's
wait
for
the
pub/sub
instance
to
provision.
C
And
what
it's
doing
behind
the
scenes
is
right
now,
when
the
I
am
insisting
for
the
provisioned,
it's
creating
a
service
account
for
our
our
namespace,
and
it's
also
creating
a
pub
sub
topic
for
our
namespace
and
when
we
bind
to
it,
I
can
discuss
that
a
little
bit
more.
Hopefully,
I
won't
take
too
much
longer
there.
We
go
yeah
so
that
when
we're
binding,
we're
actually
going
to
take
the
service
account
and
inject
the
credentials
into
our
kubernetes
cluster
as
a
secret.
C
This
takes
sometimes
a
little
bit
longer
than
the
provisioning,
at
least
during
the
demo,
but
once
it's
done
we'll
have
the
secret
sitting
there.
We
can
consume
it
from
our
application,
but
remember
we
need
to.
We
need
the
IAM
binding
so,
and
we
also
need
the
pub/sub,
binding
and
so
I
think
it's
almost
ready.
So.
C
B
Then
we
have
to
do
this
also
for
the
pub
sub
service
and
then
wait
for
that
binding
and
then
we're
almost
there.
After
that,
our
bookstore,
our
online
bookstore,
should
deploy
automatically
and
then
we'll
be
able
to
see
what
books
are
available
and
you'll
be
able
to
buy
the
books.
So
that's
just
the
online
bookstore.
B
C
So
now
we
have
our
two
secrets
that
are
service
dependent
on
and
I
bet.
If
we
look
now,
we
should
hopefully
see
some
pods
that
will
come
up.
This
might
take
a
few
seconds
because
it's
probably
in
a
back
off
loop,
but
in
a
few
seconds
we
should
see
the
front
end
come
up
and
our
service
has
already
been
provisioned.
There's
a
load
balancer
for
it
we'll
show
that
in
a
minute
and
we
should
be
ready
to
go
yeah.
B
There
we
go
all
right
so
get
service
and
the
external
IP
address
is
104
dot
198
that
195
dot
152.
If
you
want,
you
can
go
to
this
external
IP
address
and
you
can
shop
online
as
well.
So
this
is
the
bookstore.
Let
me
make
this
a
little
bit
bigger.
This
is
our
online
website
and
you
got
a
lot
of
different
kinds
of
you
know.
As
I
mentioned
fiction
nonfiction,
you
can
go
here
and
you
can
purchase
and
now
I'm
gonna
ask
Matt
to
talk
about
the
the
on
premise,
bookstore
sure.
C
So,
just
to
show
you
what
we
did,
we
don't
have
time
during
the
demo
to
show,
but
we
did
the
exact
same
steps
that
we
just
showed
you
we
ran
through.
We
we
already
had
the
service
broker
and
service
catalog
installed.
So
all
we
did
was,
you
know,
create
an
instance
and
bind
to
it
for
GCP
and
I
am
it's
talking
to
the
same
project,
and
it
creates
a
new
topic
that
then
we
can
then
use
for
our
inventory
control.
So
speaking
of
inventory
control,
let's
set
up
the
two
topics.
We
have
a
pub/sub
reader.
C
This
is
going
to
run
I.
This
particular
one
who's
going
to
run
in
our
cloud
environment
because
that's
the
most
makes
the
most
sense
and
what
it's
going
to
do
is
it's
going
to
listen
to
the
topics
and
the
topics
are
being
again
published
by
both
bookstores
and
it's
going
to
give
us
a
kind
of
a
real-time
view
of
the
of
the
purchases
coming
through
right.
B
So
both
bookstores
as
you
purchase
books
and
it
does
look
like
someone-
has
bought
books
right
like
so
so.
Three
people
have
bought
books
in
in
the
online
store
and
we
yeah
four
or
five
people:
okay,
yeah.
This
is
here
the
the
on
premise,
bookstore,
and
we
should
give
them
that
you're,
the
the
IP
address
for
the
on
premise,
bookstore
too,
so
they
can
go
shopping
on
premise,
especially
if
a
book
is
sold
out
online,
you
can
buy
it
on
premise
because
it
is
essentially,
we
have
the
same
inventory
here.
B
B
B
B
The
use
cases
that
we
demonstrated
here,
where
the
local
execution
and
the
hybrid
services,
so
local
execution,
being
you
know
we're
executing
the
same
application
on
premise
that
we
are
in
in
the
cloud,
and
you
can
also
imagine
doing
CI
CD
should
I
want
to
update
my
bookstore
I
can
roll
it
out.
You
know
from
the
cloud
to
all
my
hundreds
of
kiosks
as
I
go
as
I
go
public,
and
then
we
demonstrated
the
use
of
hybrid
services
as
dependencies
through
the
open
service
broker
work.
B
So
there
are
a
number
of
other
use
cases
that
these
primitives
also
apply
to,
but
those
are
the
ones
that
we
want.
We
were
most
excited
about
and
wanted
to
show
you
today
again.
You
know
these.
We
believe
that
these
are.
These
are
really
helpful,
primitives
for
those
who
want
to
deploy
applications
across
clouds
and
in
on
and
on-premise
and
I
think
I
hope
that
you,
you
all
have
a
chance
to
try
this
out.
Okay,
we're
gonna
open
it
up
to
QA.
D
A
E
E
B
So
the
legacy
dependencies
use
case
is
often
when
you
have
a
cloud
native
app
that
you're
developing
saying
gke,
and
you
want
to
connect
to
dependencies
that
are
on-premise,
maybe
an
ERP
system
and
and
and
really
there.
If
you
can
put
an
API
gateway
in
front
of
that
application
and
create
a
restful
api,
then
you
can
do
any
of
these
things
right.
You
can
obviously
connect
to
the
cloud
native
application,
but
you
can
also
use
this
tio2
to
manage
that
the
to
manage
that
service,
along
with
your
other
cloud
native
services.