►
Description
Let's Run Cloud Foundry on Kubernetes - Vlad Iovanov & Nikhil Manchanda, HPE
"Cloud Foundry is an Open Source – Platform as a Service (PaaS) solution that has been widely adopted across industry segments to provide Cloud Native Application development constructs for deploying and scaling applications without locking to a particular cloud platform. The Cloud Foundry runtime supports both Buildpack and Docker based applications. The standard deployment and life-cycle management of Cloud Foundry roles is done via the open source project BOSH. BOSH manages resources at a VM level.
In this talk, the speakers will demonstrate how Fissile (a project open sourced by HPE) containerized Cloud Foundry and leveraged Kubernetes as the life-cycle management of its roles. As BOSH releases are precisely structured, we are able to craft Docker images that contain jobs and packages, similar to what you get after BOSH provisions you a VM.
HPE's containerized Cloud Foundry offering is built upon a Control Plane that abstracts and automates deployment of cloud-native services across multiple IaaS environments: OpenStack, VMware vSphere®, and Amazon Web Services.
The Control Plane leverages Kubernetes as its container management platform. HCP takes care of a lot of the details of running Kubernetes across multiple IaaS providers. HCP manages all components required for Kubernetes to operate – from load balancing endpoints to networks to compute and storage."
About Vlad Iovanov
Vlad Iovanov is currently working as a Technical Lead on the Helion Cloud Foundry project at Hewlett Packard Enterprise. He has given various talks in industry for topics ranging from Container technologies, Windows framework and Best practices for Application Development. Located in Seattle, USA
About Nikhil Manchanda
Nikhil is a Master Engineer working at HP Enterprise on Stackato v4.0 -- a PaaS solution based on Kubernetes and Cloud Foundry.His main areas of expertise lie in databases, identity, and distributed systems but he has also been known to occasionally dabble in machine learning, mobile applications, and software update intelligence.In a previous life, he was the Project Technical Lead for OpenStack Trove -- the OpenStack Database Service.In his spare time you can often find him hunched over his desk either assiduously hacking away on his Raspberry Pi or NAS4Free box, or writing verse and short stories.
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
B
And
I'm
Nikhil
manchanda
principal
engineer
for
Hewlett
Packard
enterprise
as
well,
and
today
we'll
be
talking
to
you
guys
about
running
cloud
foundry
on
kubernetes.
So
let
me
get
started
with
this.
So
as
part
of
running
cloud
foundry
on
kubernetes,
we
recently
announced
the
general
availability
of
HPE
product
called
Hylian
staccato
for
dough,
and
basically
what
this
is
is.
B
Certified
distribution
of
cloud
foundry
that
you
can
just
install
as
soon
as
you
have
the
control
plane
up
and
running,
and
you
you
also
have
healing
code
engine
which
is
a
CI
CD
engine
for
the
entire
lifecycle,
the
build
tests
deploy
of
your
applications
on
on
this
cloud
platform,
we
also
have
sort
of
a
plethora
of
regular
services,
like
my
sequel,
Redis,
all
of
that
in
the
catalog
that
that
you
can
deploy,
and
so
it's
it's
very
easy
to
get
started
with
it.
I
should
mention
that
this
particular
cloud
platform
here
in
staccato
for
ATO.
B
It's
multiple
ayahs
providers,
so
you
can
install
it
on
the
AWS
public
cloud.
You
can
install
it
on
OpenStack,
including
Helion
OpenStack,
which
is
an
HPE
offering,
and
you
can
also
install
it
on
vanilla
vSphere.
So
if
you
have
a
vSphere
installed
somewhere,
you
can
bring
it
up
there
and
then
install
the
control
plane
and,
like
I,
said,
install
the
service
manager
and
all
of
these
applications
that
we
talked
about
so
enough
about
healing
staccato.
B
C
B
B
And,
as
you
can
see,
this
particular
cluster
has
one
kubernetes
master,
3,
kubernetes
nodes
and
two
Gluster
nodes.
We
use
Gluster
here
to
provide
share
filesystem
services
for
applications
that
we
we
bring
up
and
when
your
bootstrap
it
you
do
definitely
say
what
your
cluster
size
is,
but
you're
not
limited
to
that
size.
So
you
can
grow
your
cluster.
You
can
use
the
same
HCP
command
line
too.
B
If
you
want
to
add
another
couple
of
kubernetes
masters
for
h.a,
you
can
do
that
or
if
you
want
to
add
nodes
to
grow
out
your
cluster,
if
you're
running
a
lot
more
applications
on
it,
you're
you're
able
to
do
that
as
well.
But
today
what
we're
going
to
see
is
actually
deploying
Cloud
Foundry
on
that
and
as
I
mentioned,
the
service
manager
is
sort
of
the
interface
for
folks
to
enter
the
Service
Catalog.
B
So
we'll
take
a
look
at
service
manager
and
get
a
list
of
all
the
services
that
are
available
for
us
to
deploy.
As
you
can
see
here,
we
out-of-the-box
we
have
quite
a
few
services
that
we
can.
We
can
deploy
and
the
way
we
are
going
to
deploy
any
of
these
services
is
basically
we're
going
to
use
HSM,
which
is
the
client
for
Hylian
service
manager,
to
create
an
instance
of
that
particular
service
before
I
show
you
that,
let's
just
you
can
list
all
of
the
instances
that
have
already
been
created.
B
So
if
I
do
that,
you'll
see
that
I
have
the
control
plane
as
an
instance
that
is
running
and
also
my
sequel
is
an
instance
that
is
running
that
I've
pre
created.
One
thing
that
I
wanted
to
mention
here
is
the
control
plane
itself
when
we
bootstrap
is
an
application,
that's
running
on
top
of
off
of
kubernetes
itself,
so
it
is
a
cloud
native
application
and
I'll
talk
a
bit
more
about
the
architecture
of
the
control
plane
as
we
progress,
but
let's
get
started
with
kicking
off
the
install
for
Cloud
Foundry.
B
So
one
thing
before
we
get
to
that
is
you
could
so
you
can
inspect
any
of
these
services
to
see
what
the
actual
service
entails?
If
this
is
just
a
very
simple,
my
sequel,
service
and
you'll
see
that
it
has
a
bunch
of
parameters
that
are
required
as
input
to
the
service.
When
you
bring
it
up,
you
notice
that
some
of
these
parameters
are
required.
B
Hsm
is
something
that
is
very
interesting
because
for
all
these
parameters
that
are
marked
generate
able,
which
tend
to
be
secrets
or
certificates,
or
things
like
that,
you
don't
actually,
even
though
they're
required
you
don't
actually
have
to
specify
a
parameter
when
you're,
creating
the
instance
and
HSM
will
heal
and
service
manager
will
take
care
of
actually
generating
these
for
you
and
populating
these
parameters
into
the
book.
What
we
call
the
SDL,
which
is
basically
a
domain-specific
language
for
deploying
applications
in
this
platform.
B
So,
as
I
said,
my
sequel
here
has
just
very
few
of
these
parameters,
but
when
we
talk
about
something
like
Cloud
Foundry,
it's,
it
has
quite
of
quite
a
lot
of
them
pretty
much
a
couple
of
orders
of
magnitude
more
than
what
you're
seeing
here.
So
it
makes
it
hard
to
deploy.
If
you
try
it,
if
you
have
to
figure
out
hey,
what
does
this
parameter
need
to
be?
Does
it
have
a
do?
I
do
I
need
to
like
more
than
30
or
so
certificates
do
I
need
to
generate
them.
B
B
So
all
I'm
doing
here
is
HSM,
create
instance,
that
the
name
of
the
instance,
the
instance
ID
and
and
the
version
another
thing
that
you
would
notice
here
is
that
when
you
do
a
list
of
services
you
can
have
multiple
product
versions,
and
so
this
makes
upgradability
really
easy.
So,
if
you're
on
product
version
like
over
here,
if
you
look
at
service
console
you'll
see
there's
two
versions
available
for
it
for
dodo
and
4.1.
B
If
you're
on
one
version,
you're
very
easily
able
to
upgrade
between
two
to
the
next
version,
service
manager
has
logic
that
basically
takes
care
of
using
this
DSL
called
STL
figures
out
whether
a
version
is
upgradable
to
another
version
and
will
let
you
upgrade
from
only
versions
that
are
upgradeable
to
versions
that
make
sense.
Okay,
that's
it.
Let's
go
ahead
and
kick
off
this
create
instance.
B
Okay,
so,
like
I
said
for
required
values
that
are
needed,
it
will
prompt
us
to
enter
values
for
it.
The
service
name
is
not
required.
It
will
generate
one,
but
it's
nice
to
have
something:
that's
human
readable.
So
it
gives
you
the
option
of
that
I'm
just
going
to
call
it
ACF
the
cluster
password
for
the
cluster
administrator.
B
And,
as
you
can
see,
it's
off
creating
the
instance,
so
since
Cloud
Foundry
is
pretty
big,
it
involves
around
30
or
so
pods,
and
things
like
that.
It
takes
a
little
while
to
create
so
I'm
just
going
to
go
back
to
the
slides
and
tell
you
a
little
bit
more
about
the
architecture
of
the
control
plane.
That
is
makes
this
happen.
B
B
We
have
added
services
which
basically
are
services
that
the
control
plane
brings
up
and
uses,
but
are
also
available
to
other
applications
that
get
installed
in
this
same
platform
and
in
addition
to
that,
we
have
dependencies
which
are
basically
dependencies
that
are
required
for
some
of
the
functionality
of
the
control
plane
to
work.
So
talking
about
just
the
the
backbone
or
the
brains
of
the
control
plane.
We've
got
three
different
micro
services.
We
have
instance,
policy
manager,
resource
policy
manager
and
Hylian
service
manager
and
I'll
go
a
little
bit
into
all
these
three
in
detail.
B
B
It
is
the
interface
into
two
kubernetes,
so
all
of
the
translation
between
the
service
definition,
language,
the
the
DSL
that
I
mentioned
earlier
and
the
actual
kubernetes
definitions
is
done
by
that
instance,
policy
manager,
so
really
the
the
brains
that
sort
of
controls,
kubernetes
that
sits
in
this
platform
resource
policy
manager.
The
second
one
over
here,
on
the
other
hand,
is
sort
of
the
brains
that
controls
the
underlying
infrastructure
service.
So,
if
you
think
about
so,
this
is
deployed
on
the
AWS
public
cloud.
B
So
when
we
extend
the
size
of
the
cluster,
we
have
to
do
a
bunch
of
vayas
operations.
We
have
to
do
things
like
bring
up
new
nodes.
We
have
to
do
things
like
create
volumes,
delete
volumes
if
an
application
goes
away.
Things
like
that,
so
the
resource
policy
manager
is
really
the
micro
service
that
knows
about
what
I,
as
it's
running,
on
top
of
and
makes
the
actual
AI
as
specific
calls
to
perform.
Whatever
operations
are
required.
B
I
mentioned
the
Hylian
service
manager.
Briefly
before
this
is
the
brains
that
is
responsible
for
the
application
catalog,
so
it
takes
care
of,
for
example,
listing
out
the
services
that
are
available
to
you
doing,
service
discovery
and
also
things
like
doing
the
parameter
generation
that
we
talked
about
earlier
in
the
added
services
piece.
We
have
sort
of
three
different
added
services
that
applications
on
the
platform
can
leverage.
B
We
have
user
account
and
authentication,
which
is
basically
the
Cloud
Foundry
you
a
a
service
which
is
a
fully
fledged
Roth
provider
that
the
control
plane
makes
you
yourself
in
the
default
zone
and
through
the
SDL
that
I
was
talking
about
earlier.
Other
instances
of
applications
can
also
make
use
of
this
in
their
own
zone.
B
Keatster
is
an
added
service
for
resource
analysis.
It's
to
keep
stir
from
upstream
sort
of
kubernetes,
and
so
you
can.
It
can
tell
you
how
much
memory
applications
are
taking
and
you
can
do
a
bunch
of
resource
analysis
using
it.
Dependencies
are
fairly
straightforward.
We
use
Postgres
as
a
datastore
for
a
lot
of
the
instance
that
we
keep
track
of
in
in
the
in
the
backbone
and
we
use
Nats
as
a
message
queue
to
basically
just
for
the
task
system.
So
we
create
async,
asynchronous
tasks
to
do
things
and
we
use
Nats
for
that.
B
A
So
we
learned
about
the
control
plane,
which
is
this
platform
that
sits
on
top
of
kubernetes
that
helps
us
deploy
containerized
applications
on
top
of
kubernetes,
I'm
going
to
talk
a
bit
about
how
we
made
it
so
that
you
could
deploy
Cloud
Foundry
on
top
of
on
top
of
kubernetes
using
the
control
plane.
So
if
you're
not
familiar
with
the
cloud
foundry,
it's
usually
deployed
using
a
tool
chain
called
Bosch
and
in
a
very
simplistic
way.
A
The
Bosch
tool
chain
tells
you
how
to
organize
the
code
in
your
software
so
that
it
can
easily
be
deployed
on
VMs
and
then
after
you've
written
your
software.
Bosch
can
also
help
you
deploy
and
manage
your
software
on
top
of
VMs.
But
it's
an
important
thing
that
Bosch
is
a
solution
and
a
good
solution
for
for
VM
infrastructures.
But
we
wanted
to
deploy
stuff
on
on
kubernetes.
A
So
we
wrote
this
tool
called
Fissel
that
helps
us
convert
bashed
like
things
to
darker
containers
and
it
it
has
this
ability,
because
we're
live,
leveraging
the
structure
of
the
code
that
is
prescribed
by
Bosch.
So
because
this
structure
exists
and
all
of
the
cloud
foundry
project,
we
know
how
to
automatically
compile,
configure
and
run
all
of
Cloud
Foundry
automatically
during
a
build
process
supported
by
fizzle
and
a
really
nice
side
effect
of
using
a
tool
like
this
is
that
it
gives
you
mechanisms
to
make
deployments
year
for
the
user.
A
If
you
just
noticed,
when
you
kill
deployed
Cloud
Foundry,
you
only
had
to
specify
three
parameters
which
is
really
cool.
Usually
when
you
have
to
the
political
autonomy
with
Bosch,
you
have
many
many
things
to
configure
and
it's
really
complicated,
and
it
also
allows
you
to
deliver
compiled
bits
to
the
user,
so
usually
with
with
Bosch
the
the
operator
would
compile
things
locally
on-premise
using
Bosch.
This
way
we
actually
deliver
images
that
contain
precompiled
bits
to
the
customer,
and
the
configuration
mechanism
is
also
different.
Using
fizzle.
A
A
The
bar
structure,
that's
available
inside
the
Cloud
Foundry
source
code,
to
create
containers
for
the
entire
Cloud
Foundry
Cloud,
Foundry,
release
and
Fissel
creates
these
containers
from
Bosch
releases
because
we
want
it
to
be
cloth
under
certified,
and
this.
This
containerized
cloud
foundry
that
you
just
saw
deployed,
has
been
certified
by
the
cloud
foundry
foundation
and,
as
you'll
see,
it
runs
on
on
kubernetes,
so
I'm
gonna
switch
back
to
a
console,
hopefully
you'll
be
able
to.
A
A
So
physical
doesn't
actually
use
a
Bosch
manifested
it
uses
something
similar.
Actually,
let
me
go
to
the
next
slide,
so
we
open
sourced
Fissel
a
few
months
ago
during
the
cloud
foundry
summit
in
the
u.s..
At
that
point,
not
a
lot
of
people
were
able
to
use
it
because
there
weren't
examples
for
it.
So
today
we've
we've
released
CF
solo,
which
will
serve
as
a
as
a
component
as
an
example
on
how
to
containerized
cloud
foundry
using
Fissel
and
I
can
actually
show
you
the
code
for
this.
A
Falou
you
can
read
this,
so
Fissel
will
expect
you
to
have
a
bunch
of
Barcia
releases
and
the
roll
manifest
the
roll.
Manifest
will
tell
fissile
how
you
want
your
botched
jobs
and
packages
split
up
into
multiple
darker
images
in
this
example
we're
actually
building
one
one
one
container.
So
it's
actually
a
pretty
interesting
project.
You
can
run
all
of
Cloud
Foundry
inside
one
docker
container,
so
you
do
docker
run
a
few
things
and
then
all
of
cloud
foundry
will
start
up
in
in
one
container,
with
all
the
bits
that
come
from
from
upstream.
A
So
to
give
you
an
idea,
you
have
all
the
jobs
listed
here
with
a
release
similar
to
to
how
a
barge
deployment
manifest
specifies
things
and
then
at
the
bottom
you
write
some
mustache
templates
that
basically
translate
environment
variables
into
Bosh,
Bosh
property
values,
and
let
me
also
show
you
the
releases
that
come
into
play
for
building
this,
so
you
have
CF
release
the
root
FS
for
CF,
Linux,
FS
to
Diego
garden
Linux
and
the
routing
release.
So
essentially
you
build
dev
barse
dev
releases.
A
D
A
Right,
so
the
question
was
normally
when
you
deploy
cloud
founder,
you
have
a
lot
of
parameters
when
we
deployed
there
were
just
three:
how
how
do
we
handle
the
rest
of
the
things
that
get
configured
so,
as
Nikhil
mentioned
earlier,
the
HSM
part
of
the
cloud
of
the
control
plane
that
we
have
has
the
ability
to
generate
parameters
so
most
of
the
parameters
inside
Cloud
Foundry.
It's
like
that.
You
need
to
specify,
as
a
user,
that
you
you
must
specify
as
a
user
our
secrets,
things
like
passwords
certificates
and
so
on.
A
Hsm
has
the
ability
to
generate
all
of
these.
For
you,
of
course,
we
could
have
specified
each
one
each
certificate,
each
password
each
secret,
but
we
don't.
We
just
automatically
generate
those
and
and
move
on.
So
it's
a
it's
a
bit
of
a
value
add
on
top
of
silver
Nettie's.
If,
if
you
weren't
using
HSM,
you
would
have
to
just
specify
all
of
these
all
of
these
secrets
manually
still,
it
would
be
a
lot
less
than
all
the
properties
you
find
in
a
barcia
deployment
manifest
and.
A
They're
kind
of
easier
to
deal
with
because
their
environment
variables,
so
you
could
take
each
image
and
docker
run
it
manually.
If
you
think
about
it,
there's
no
other
way
for
you
to
actually
run
each
component
of
Cloud
Foundry
manually
without
resorting
to
Bosh.
So
this
gives
you
an
alternative,
there's
also
another
helper
file
here,
which
we
call
opinions.
This
looks
like
a
Bosch
manifest
as
well.
This
is
basically
a
collection
of
values
that
you
as
a
as
a
let's
say,
vendor
of
a
Cloud
Foundry
distro.
A
You
feel
that
the
defaults
that
Cloud
Foundry
comes
with
are
not
proper
and
you
want
to
change
them,
so
these
values
will
actually
give
be
baked
into
the
image
that
you
deploy
to
the
to
the
to
the
end-user,
and
you
can
override
them
here.
In
this
opinion,
siamo
and
Fissel
will
embed
them
in
the
image
for
you.
A
A
A
So
I'm
going
to
so
I
talked
about
CF
solo
and
please,
if
you
get
a
chance,
go
to
these
projects,
you
can
run
CF
solo
very
easily
on
a
Linux
machine.
It's
literally
one
command-line
and
it
runs
all
of
Cloud
Foundry
in
in
one
container,
and
you
should
be
able
to
target
a
deploy
apps
immediately
after
that,
it's
based
on
Cloud
Foundry
version
241.
And
if
you
like,
this
idea
of
being
able
to
run
all
of
Cloud
Foundry
in
one
darker
container,
please
let
us
know
and
help
us
make
this
thing
better.
A
Ok,
so
the
final
piece,
a
thing
that
we
call
furnace,
so
we've
just
established
that
we're
running
Cloud
Foundry
on
top
of
kubernetes,
and
if
you
think
about
it,
we
still
have
Diego
release.
So
question
is:
are
we
running
containers
in
containers?
Yes,
we
are
basically
garden
containers
which
are
which
are
the
way
that
Cloud
Foundry
deploys
applications
for
you.
They
run
inside
the
docker
containers
that
get
deployed
by
kubernetes
and
this
works
fine.
We
haven't
seen
any
performance
issue
issues,
but
why
do
I
do
this?
Why
run
containers
in
containers
the
obvious?
A
So
this
would
mean
if
you're
familiar
with
Cloud
Foundry,
the
the
current
scheduler
is
called
Diego
and
we
just
wanted
to
to
put
out
an
obstruction
layer
in
the
middle.
So
we
can
swap
it
up
for
something
different
and,
of
course,
what
would
be
a
good
first
alternative
implementation
other
than
kubernetes.
A
A
Okay,
so
what
I'm
going
to
do
now
is
deploy
the
Dora
app,
which
it's
a
reference
application
that
the
Cloud
Foundry
community
uses
to
test
to
test
alternative
deployments,
and
this
is
going
to
get
deployed
on
a
local
bar
slight
deployment
of
Cloud
Foundry.
That
has
this
furnace
project
embedded
into
it.
So
I'm
just
going
to
do.
Cf
push
Dora.
A
Okay-
and
we
should
see
in
about
a
few
seconds
some
logs
coming
up
these
already-
don't
look
like
the
normal
logs.
You
would
see
in
a
cloud
foundry
deployment
and
it's
because
the
staging
is
actually
happening
inside
a
docker
container
on
kubernetes.
So
if
we
quickly
switch
to
our
furnace
dashboard,
we'll
see
that
we
have
a
job
here,
this
job
is
26
seconds
old
and
it's
running
staging
for
us
for
the
application
that
I've
just
deployed
so
moving
back
we're
downloading
stuff.
A
Here
we
don't
have
caching
yet
so,
every
time
we
deploy
an
application,
it
actually
downloads,
all
the
bill
packs
tries
to
figure
out
which
bill
back
to
to
use
the
deploy
and
then
actually
deploys
the
thing.
So
if
you
notice
logs
will
also
work
so
the
whole
logger
Gator
system
works
as
well
and
we
got
an
application
running.
So
how
does
that
look
like?
So
if
we
refresh,
we
should
see
a
new
replication
controller
here
which
is
29
seconds
old.
A
A
A
This
is
running
bill
pack
based
applications
using
cloud
foundry
on
kubernetes,
but
as
you're
probably
aware,
cloud
foundry
can
also
deploy
darker
based
applications.
So
this
is
actually
interesting
if
you
do
something
like
push
a
darker
test
application.
This
is
a
very
small
node
based
docker
image.
A
This
is
really
cool
the
staging
part,
because
it's
it's
kubernetes
is
a
no
op.
So
it's
really
fast.
So
we
for
the
staging
part,
normally
Cloud
Foundry
has
to
download
the
docker
image
it
has
to
upload
to
the
image
to
a
blob
store.
Then
it
has
to
come
back
and
so
on
for
us
for
kubernetes.
We
actually
do
nothing,
it's
an
op
and
then
we
just
pass
on
through
and
tell
kubernetes
to
run
the
docker
image
that
we
want.
So,
as
you
can
see,
it's
it's
pretty
fast.
Let's
see
if
this
one
works
and
it.
D
A
These
are
basically
all
the
all
the
pieces
that
we
wanted
to
show
you.
You
can
see
here
that
we've
we've
completed
the
work
to
run
Cloud
Foundry
on
top
of
kubernetes.
It
runs
well,
it's
a
fully
Cloud
Foundry
foundation,
certified
distribution
and
we're
also
thinking
about
ways
to
make
the
whole
thing
simpler
by
trying
to
trying
to
deploy
applications
on
top
of
kubernetes,
not
doing
containers
and
containers.
Of
course,
there's
still
a
lot
of
work
to
be
done.
A
A
Okay,
so
first
the
the
Gluster
FS
system
is
for
the
control
plane.
It's
only
available
to
two
distributed
systems
that
get
deployed
exclusively
through
the
the
control
plane
that
we've
built
and
second,
the
furnace
project
is
just
an
experiment.
It's
it
it's
not
tied
to
staccato
in
any
way.
It's
just
an
experiment
that
runs
off
of
upstream
barf
releases
in
bars
light.
So
we
don't
have
file
system
support
for
applications
running
in
Cloud
Foundry.
B
Right
so
just
talk
to
answer
that
question.
The
question
is
whether,
if
I'm
getting
it
right,
the
Gluster
pieces
that
we
deploy,
whether
that's
usable
by
the
control
plane
at
all,
so
for
stuff,
that's
deployed
using
the
DSL.
That
I
was
talking
about
the
service,
the
service
language.
You
can
specify
whether
you
want
a
volume,
support
or
shared
volume
support.
If
you
specify
you
want
volume
support,
then
we
use
volumes
in
the
eye
as
providers.
So,
for
example,
you
would
get
AWS
provisioned
volumes.
B
If
you
say
you
want
shared
volume,
support
for
your
application,
then
you'd
get
a
volume
on
cluster
that
you
can
attach
to
multiple
containers
in
kubernetes
itself.
So
we
we
make
use
of
kubernetes
notion
of
volume
and
shared
volume
to
leverage
either
the
underlying
I
as
provider
volumes
or
Gloster
offense
volumes
in
this
case.