►
From YouTube: Webinar: Stateful Workloads and Kubernetes: A Gnarly Problem or an Awesome Opportunity?
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
Kubernetes has emerged as the de-facto standard for orchestrating containerized applications that are stateless. However, deploying and managing Stateful, especially Big Data and Database applications requires bringing together several elements across the stack, beyond just storage, to effectively meet their unique retirements.
In this webinar, Partha Seetala, ROBIN.io CTO, will walk through the challenges when it comes to running Stateful applications on Kubernetes, architectural approach to addressing these challenges and demo key scenarios and best practices in delivering any Stateful App as a Service in a multi-cloud world.
Join us for KubeCon + CloudNativeCon in 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
All
righty
I
think
it's
time
to
go
ahead,
get
started
so.
First
of
all,
let
me
welcome
you
to
this
CN
CF,
webinar,
stateful
workloads
and
kubernetes
Banali
problem
or
an
awesome
opportunity.
My
name
is
christian
jones,
I'm
in
CN,
CF,
ambassador
and
cloud
consultant
for
various
companies
and
I'll
be
moderating
today's
webinar.
First
of
all,
thanks
everyone
for
joining.
It's
a
pleasure
to
be
here
and
also
please.
Let
us
welcome
our
presenter
today,
which
is
part
of
sitala
who
is
CTO
at
Robyn
systems
or
Robyn
dot.
Io
there's
a
little
input.
A
A
B
Christian
and
as
Christian
mentioned
I'm
going
to
be
talking
about
some
of
the
challenges
that
one
would
face
if
you
are
trying
to
run
complex,
stateful
applications
on
kubernetes
and
then
I'll
follow
it
up
with
what
are
the
potential
solutions
to
address
those
challenges.
So,
let's
start
with
an
obvious
statement
right
when
kubernetes
is
a
great
platform.
It's
it's
it's
a
wonderful
platform
with
a
lot
of
primitives
that
help
the
deployment,
as
well
as
the
lifecycle
management
of
stateless
workloads.
B
Now
imagine
that
if
you
could
take
this
platform
and
then
you're
able
to
run
stateful
workloads
on
it
and
then
I
say
stateful
workloads,
I'm,
not
talking
about
any
workload
that
requires
a
persistent
data
volume,
I'm,
specifically
referring
to
the
ones
which
are
heavy
hitters
right
things
like
Big,
Data
Platform
such
as
cloud
arras,
Hortonworks
or
you
know
no
sequel.
Databases
such
as
a
sharded
replica
set
based
MongoDB.
We
talk
about
production,
scale,
deployments
of
on
couch
or
even
you
know
more
complex.
Our
DBMS
solutions,
like
Oracle
Oracle
RAC,
writes
plunk
s
AP
Hana.
B
B
Obviously,
these
workloads,
our
data,
heavy
workloads,
which
means
that
you
need
to
have
a
very
strong
persistent
story
around
that
as
well
as
they
are
networked
because
they
are
distributed
databases,
so
you
also
need
to
have
very
strong
networking
components
right
to
enable
these
workloads
and
if
you
look
at
the
state
of
the
art
right
now
in
both
networking
and
storage,
there
are
about
27
storage.
Vendors
who
are
CNC
are
certified
to
provide
storage
for
containers
tray
right
and
there
are
about
21
vendors
that
provide
CNI
plug-ins
for
kubernetes.
B
B
To
this
right,
I
mean
there
are
so
many
vendors
providing
storage
and
networking
right.
So
it
almost
feels
like
it's
a
solved
problem.
What
is
the
remaining
to
be
done
right,
especially
with
kubernetes
itself?
Introducing
things
like
stateful
said:
persistent
volumes
position,
volume
claims,
snapshot,
contents
and
things
like
that
right
now
there
was
a
survey
that
was
done
by
ciencia,
and
so
it
doesn't
tell
you
to
find
out
what
are
the
most
complex
challenges
that
people
face
with
kubernetes
today
right,
but
despite
so
many
vendors,
providing
storage
and
networking,
you
have
48%
of
the
responders.
B
Who
said
that
you
know,
storage
is
still
a
very
big
challenge
and
almost
similar
numbers
said
networking
is
still
a
big
challenge.
So
the
question
is:
why
is
it
that,
with
so
much
of
vendor
support
it's
still
difficult
for
many
people
to
run
complex,
stateful
workloads
on
kubernetes
right,
and
that
is
going
to
be
the
bulk
of
my
presentation
today.
The
challenges
as
well
as
I
do
want
to
also
end
with
solutions
right,
but
before
all
that
right.
B
What
makes
me
a
subject
matter
expert
on
talking
about
this
topic,
so
it
just
has
a
way
of
introduction.
Again.
My
name
is
partha
sita.
I
am
the
chief
technology
officer
of
Robin,
Systems,
Robin,
dot,
IO
and
prior
to
that,
I
was
a
distinguished
engineer
in
the
storage
division
of
Veritas
semantics
and
I
have
two
good
fortune
of
spending
several
years
building
multiple
products
and
distributed
storage,
big
data
and
data
analytics
space.
B
Now
when
it
comes
to
Robin
itself,
we
are
about
a
four
year
old,
startup
based
out
of
Silicon
Valley,
and
what
we
have
done
is
that
we
have
built
a
software
that
runs
alongside
kubernetes
and
it's
software
that
enables
the
deployment,
as
well
as
a
lifecycle
management
of
these
complex
workloads
right
and
just
as
the
kind
of
proof.
So
before
we
get
into
you
know
the
more
depressing.
What
are
the
challenges?
Part?
B
Let
me
just
give
you
a
hope
about
what
is
possible
by
actually
highlighting
some
of
our
current
customer
deployments
that
showcases
what
is
possible
with
kubernetes
today,
right
so
I've
showcased,
three
different
large
customers
here,
there's
a
variety
of
different
workloads.
The
first
one
is
a
security
analytics
pipeline.
It's
a
very
massive
ingest
that
happens
about
11
billion
security,
wins
every
single
day
into
this
pipeline.
B
It
runs
silastic
search,
logstash,
Cubana,
Kafka
on
kubernetes,
enabled
through
Robyn
through
our
storage
and
all
the
innovations
that
evening
I'm
going
to
talk
about
that
later
then,
the
next
one
is
again
an
analytics
company
that
is
running
a
crowd,
error,
Impala,
cough
and
Truett,
based
at
your
analytics
pilot
line.
Now
again,
look
at
this
right
if
you're
actually
running
a
6,
petabytes
cloud
or
a
cluster
on
kubernetes.
This
is
something
that
is
it's
typically
unheard
of
right.
B
Typically,
when
you
look
at
stateful
workloads
today
on
kubernetes
and
just
for
variety
right,
the
last
one
is
a
very
large
travels
company
and
they
run
about
400
Oracle
grogg
database
clusters.
That's
again
a
very
interesting
thing:
right,
running
Oracle
RAC
on
kubernetes,
so
clearly
it
can
be
done,
but
there
are
several
challenges
that
one
needs
to
all
come.
So
let's
get
into
that
right.
What
are
the
challenges
now
gluten
of
the
challenges,
because
now
it
right,
we
eventually
encountered
many
of
these
challenges
and
we
have.
B
We
have
build
solutions
that
in
that
essentially
overcome
those
challenges,
but
those
challenges
themselves
fall
into
four
categories:
around
storage,
networking,
general
CRI
or
container
management,
as
well
as
some
of
the
general
kubernetes
challenges
themselves.
So
let
me
dig
a
little
deeper
into
that.
Let's
start
with
storage.
Now,
siesta
is
of
course
now
GA,
so
one
rato
is
now
available.
B
Everybody
can
get
to
use
it
and
if,
if
any
storage,
when
it
tells
you
that,
are
you
know,
providing
persistent
storage
to
pods
is
a
big
problem,
then
I
think
they
are
lying,
because
it's
it's
a
with
si
si
and
such
a
large
under
support.
If
all
you
want
is
providing
storage
to
pods
and
ensuring
that
that
storage
is
available,
then
the
pod
relocates
are
crashes.
That
is
a
largely
solve
all
right.
B
So
the
real
challenges
that
you'll
face
when
you're
trying
to
onboard
complex
applications
are
bought
four
of
them
right
at
a
very
broad
level.
So
the
first
one
is
many
of
the
databases
will
require
data
management
that
goes
beyond
just
providing
storage
and
when
I
say
data
management
thinks,
like
you,
want
to
snapshot
your
database.
You
want
to
clone
it,
you
want
to
back
it
up,
you
want
to
restore,
or
you
want
to
migrate
it
from
one
cluster
to
the
other,
and
why
is
that
a
challenge?
B
Because,
obviously
storage
bay
snapshots
has
been
in
the
industry
for
30
years
right.
Adapting
that
to
kubernetes
is
just
a
matter
of
time
and
it
has
been
done
by
many
vendors
right.
So
why
is
data
management
a
challenge
so
a
couple
of
reasons
for
that
right,
number
one
is
even
with
the
csi's
introduction
of
the
snapshotting
capabilities.
It's
still
at
a
per
volume
basis
right.
But
when
you
look
at
a
distributed
database,
let's
say
a
database:
are
you
an
Oracle
RAC
and
all
that
right?
They
are
partitioned.
B
They
have
multiple
instances
running
and
when
you
take
a
snapshot,
you
be
application
consistent.
You
actually
how
to
create
a
consistency
group
that
spans
not
just
one
volume
but
all
the
volumes
across
all
the
shards
of
your
database.
Now,
that's
where
you
start
season
challenges.
How
do
you
essentially
coordinate
and
created
application,
consistent
snapshot
that
spans
multiple
partitions,
multiple
disks,
multiple
nodes
and
so
on
right?
So
it's
the
first
challenge
that
needs
to
be
overcome
because.
B
Management
databases,
it's
just
going
to
be
a
toy
to
what
the
hell
that
we
will
run
it
and
purge
the
next
one
is
around
data
placement.
Kubernetes
actually
has
a
very
great
Orchestrator,
it's
a
highly
flexible
Orchestrator
that
you
could
program
and
then
influence.
But
when
you
look
at
complex
workloads
such
as,
let's
say
Hortonworks
or
cloud,
there
are
Splunk
and
things
like
that
right.
B
They
have
certain
constraints
and
they
have
certain
built-in
assumptions
around
for
how
faults
are
going
to
be
tolerated
by
the
workload
itself
right
and
they
also
have
certain
constraints
around
how
performance
needs
to
be
handled.
For
example,
if
you're
running
your
Hadoop
distribution
right,
one
of
the
common
asses
can
I
get
data
locality
because
you
want
to
minimize
the
network
traffic
across
racks
and
things
for
that
right.
So
how
do
you
influence
data
locality
when
you're
doing
odd
place
right?
B
So
that's
a
challenge
because
clearly,
kubernetes
scheduler
by
itself
does
not
have
the
primitives
to
do
storage
based
scheduling
right,
that's
that's
resides
outside
provided
by
the
csr
driver.
That's
one
thing:
the
next
one
is
around
data
placement
all
not
just
for
data
locality,
but
for
things
like
affinity
and
anti
affinity.
B
So
the
voting
disk
can
all
that
stuff
right
and
typically,
when
you
deploy
an
Oracle
RAC,
you
want
to
ensure
that
not
just
at
the
pod
level,
but
at
the
storage
level
you
do
not
co-locate
your
voting
disk
volume
with
the
data
volumes
for
Oracle
RAC
right.
So
how
do
you
influence
that
in
a
preventive
scheduler,
when
those
things
are
not
available
right?
So
that's
the
other
challenge
that
you'll
have
run
on
or
overcome.
B
So
third,
one
is
kind
of
interesting
and
I
think
this
is
a
must-have
if
you
are
trying
to
onboard
many
of
the
complex
workloads
and
that's
around
the
management
of
changes
that
happen
to
a
root
filesystem
now,
clearly,
when
docker
came
about,
it
advocated
a
philosophy
where
the
root
filesystem
is
supposed
to
me.
We
maintain
stateless
right,
obviously,
because
docker
reconstructs,
that
when
you
bring
up
a
container
but
many
of
the
workloads,
are
you
talking
about
predate
board,
docker
and
kubernetes
right
and
for
them
they
sprinkle
state
all
over
the
place.
B
They
sprinkle
States
an
Etsy
directory,
slash
var,
slash
whatever
it
is
right,
and
if
you
reconstruct
that
upon
quod
failure
or
container
failure,
then
the
application
really
cannot
adjust
to
that
right
and
these
application,
as
I
said
they
predate
da
currents
it
doesn't.
It
essentially
means
that
they
cannot
change
very
easily
to
completely
adhere
to
the
docker
philosophy
right.
B
So
you
really
need
to
solve
this
problem
more
holistically,
so
any
changes
that
an
app
makes
to
the
root
filesystem
of
the
container
needs
to
be
preserved
when
the
container
is
relocated
to
a
different
host
or
it
is
restarted.
And
finally,
the
one
on
one
cool
thing
about
kubernetes
is
that
it
allows
you
to
consolidate
your
workloads
right.
You
take
beefy
servers
and
then
you
want
to
run
multiple
databases
on
that
you're,
essentially
putting
multiple
databases
on
the
same
physical
host
right.
B
This
is
a
great
benefit,
but
with
it
comes
a
bunch
of
operational
challenges,
right,
let's
say
you're
running
multiple,
let's
say
shards
on
the
same
horse
right
now,
each
one
is
running
a
massive
query
load
or
whatever
it
is.
So
there
is
no
predictability
of
the
query
performance
because
one
where
one
database
shard
could
be
essentially
load
up
the
entire
desk
or
the
host
and
taking
down
the
performance
guarantees
of
the
other
one.
B
So
it
is
very
crucial
to
enable
guaranteed
performance
SLS
when
you
are
trying
to
onboard
data
centric
workloads
onto
kubernetes
right,
so
that
those
are
the
four
storage
challenges
that
we
saw
and
our
customers
saw
when
we
were
enabling
them
to
run
these
workloads,
and
these
need
to
be
addressed.
So
now,
let's
move
to
the
next
one
right
is
a
storage
one.
Let's,
let's
look
at
the
next
part
of
it
at
CNI,
again
CNI.
There
are
quite
a
lot
of
providers.
B
20
such
CNI
providers
doing
14,
plus
security
providers,
I
think
so
much
mesh
is
making
it
incredibly
easy
to
do
many
things
today
and
all
that
right.
So
what
are
the
challenges?
So
a
couple
of
things
here
right
so
I'll
kind
of
highlight
three
challenges
that
we
had
to
overcome
to
enable
things
like
ICP,
Hana
and
crowder,
and
all
that
to
run
on
kubernetes.
So
the
first
one
is
around
how
kubernetes
makes
IP
addresses
right
even
with
stateful
Serbs,
when
a
part
is
a
sign
and
IP
address.
B
Apart
doesn't
move,
but
you
know
in
the
part
again
it
gets
a
completely
different
IP
address.
This
is
actually
not
a
problem
for
majority
of
the
bond
and
cloud
or
the
cloud
native
workloads.
But
if,
when
you
go
to
the
older
workloads,
they're
essentially
made
assumptions
around
how
IP
address
and
hostname
binding
the
main
static.
B
They
might
put
that
information
somewhere
in
their
configuration
database
or
somewhere
right,
and
if
you
don't
preserve
the
IP
address
persistency
upon
quadrey
locations,
then
it's
a
pretty
big
mess
right
and
those
work
wrote
essentially
see
that
some
partitions
of
your
work
wrote
the
part,
for
example
by
has
been
evicted
from
the
cluster
and
it
rejoined
back
and
something
new
rejoined
back.
So
those
are
the
kind
of
deal
inconsistencies
that
you'll
start
to
see
right,
which
break
the
correctness
of
your
application.
So
that
needs
to
be
addressed.
B
Clearly,
the
next
one
is
around
the
ability
to
connect
multiple
NICs
to
a
pod.
So
why
is
that
important,
so
complex
workloads
that
specially
required
data
rebalancing
or
data
rebuilds,
and
things
like
that?
They
ideally
would
like
to
separate
the
client
traffic,
which
is
the
north-south
traffic.
From
the
east-west
management
traffic
out
of
the
data
rebuild
data
management,
traffic
right
and
ideally
it's
best
done
on
two
different
Nix,
two
different
l3
subnets
connected
to
two
different
switches
and
all
that
right.
B
So
that's
been
a
challenge
you
this
traditional
CNI
framework
200
assigns
you
ought
to
enhance
it
a
little
bit
to
get
multiple
necks
and
finally
won.
One
challenge
that
he
found
was
around
connectivity
to
a
workload
that
is
running
on
kubernetes
by
clients
that
are
completely
outside
the
kubernetes
network.
B
Right
now,
traditionally
that
solved
through
the
port
mapping-
or
you
know
those
kind
of
primitives
in
kubernetes
the
ingress
routes
and
whatnot,
not
all
of
them
work
with
workloads
such
as
clowder,
and
all
that,
primarily
because
many
of
these
workloads
have
their
own
UI
and
they
embed
the
code,
names
and
IP
addresses
in
the
URLs
within
the
web,
page
revision,
HTML,
and
that
makes
connectivity
to
pods
from
outside
a
little
harder
if
you're,
navigating
to
the
part
through
the
web.
Ui
of
that
work.
Okay,
alright!
So
that's
on
the
cni
and
CSI
challenges
right.
B
So
next
one
is
around
CRI
right.
This
is
kind
of
strange
because
when
docker
is
everywhere,
everybody
knows
how
to
build
a
docker
container
and
pretty
much.
Every
vendor
is
now
building
out
a
docker
container
for
their
software
right.
So
what
else
needs
to
be
done?
It
feels
like
it's
always
all
problem.
So
when
we
were
running
these
workloads,
we
ran
into
about
four
such
challenges
and
on
the
CRI
that
had
to
be
handled
right.
So
the
first
one
is
around.
Let
me
expand
all
of
this.
B
The
first
one
is
around
the
fact
that
docker
shim,
which
is
the
default
CRI
for
kubernetes.
It
does
not
adequately
virtualize
all
of
the
see
group
settings
right,
because
if
you
look
at
it,
there
are
multiple
ways
in
which
a
container
could
query
for
how
much
memory
it
has
access
to
how
many
CPUs
it
has
access
to
what
disks
it
has
access
to
and
all
that
right,
doctor
actually
handles.
B
Many
of
the
cases
I
mean
many
other
sisyphus
and
proc
affairs,
and
all
that,
but
not
everything,
and
when
you
are
running,
for
example,
Hana
or
when
you
are
running
things
like
kuru
of
cloud
era,
right
you're.
Seeing
that
you
know
the
JVM,
for
example
right
it
I
should
initially
start
seeing
the
entire
hosts
memory
right,
even
though
your
cab,
the
memory
for
the
container
right
because
it's
the
off
heap
memory,
is
essentially
exposed
to
the
system
for
system
call
not
through
the
Sisyphus
and
talk
affair
system
calls
out
of
the
interfaces
right.
B
So
you
go
to
address
that
I
mean
you
go
to
virtualize
all
of
the
C
groups
to
a
container
so
that
the
container
and
the
app
running
within
the
container
actually
sees
exactly
what
has
been
allocated
to
it
right.
So
that's
one.
The
second
one
is
around
C
group
settings
for
IO
management,
so
the
BLK
IOC
group
setting
is
extracting
early
useless
for
I
mean
actually
it's
not
really
exposed
to
communities,
but
even
if
it
were
it's
practically
useless
to
do.
B
Tapping
off
storage,
I,
ops
per
pod,
and
the
reason
for
that
is
the
blk
IOC
group
setting
is
on
a
per
volume
basis.
Right
and
a
pod
could
have
multiple
volumes.
At
the
same
time,
right
I
mean
if
you
look
at
I
mean
any
other
complex
database
were
close
right.
You
could
essentially
have
multiple
data
files
each
sitting
on
a
different
volume,
and
things
like
that
right
now.
B
You
really
want
to
cap
your
iOS
across
all
those
volumes
right
which
essentially
makes
your
blk
I
always
see,
groups
sitting
useless
right
for
doing
noisy
neighbor
management
and
the
final
one
is
around
raw
disk.
Access
in
complex
workloads
do
not
want
to
rely
on
ext3
ext4,
LX
FS.
They
would
want
be
at
a
table
log
device
and
then
write
to
it
directly.
Things
like
map
our
Oracle
Act,
for
example.
B
Now
the
way
the
WWE
ends
for
those
devices
is
managed,
it's
kind
of
broken,
because
when
the
pod
restarts
and
all
that
the
WWE
ends
are
not
currently
assigned
and
as
a
result,
the
application
has
to
change
to
go
and
discover
whether
it's
actually
the
previous
volume
is
bound
to
the
same
wwhen
that
it
understands,
and
thanks
for
that.
So
those
are
the
four
CRI
challenges
that
you
can
build
by.
B
Of
these
can
be
overcome
just
kind
of
highlighting
what
are
the
challenges?
I'll
talk
about
how
to
overcome
them
and
subsequence
rights,
but
let's
just
go
through
the
challenges
for
us
now.
Finally,
kubernetes
we
talked
about
CSI,
we
talked
about
CNI,
we
talked
about
CRI.
What
are
the
K?
It
is
challenges
right,
I
mean
in
fact
it
would
feel
that
stateful
sets
persistent
volume
claims
volumes
and
all
those
should
typically
address
most
of
the
concerns
right,
but
few
things
that
I'd
like
to
call
out
here
right,
which
I
already
mentioned
earlier.
B
We
are
talking
about
workloads
that
period
docker
and
communities
right,
so
many
built-in
assumptions
around
how
they
are
designed.
For
example,
not
everything
is
designed
as
a
micro
service
right,
not
everything
can
be
stopped
and
restarted
very
easily.
There
is
restart
crash
recovery
phase
that
thing
things
need
to
go
to
rights,
which
means
that
you
just
cannot
kill
a
part
and
we
started
very
easy.
There's
a
cost
associated
with
that
scaling
is
slightly
different.
B
You
just
don't
use
the
replica
set
or
stateful
set
base
Kaling
by
throwing
another
pod
at
it
and
leaving
it
to
the
workload
to
figure
out
right
how
to
load
balance
across
those
pods.
All
right,
so
there
is
usually
built
into
the
application
or
to
work
load
itself
is
how
the
the
ring
of
all
the
spots
is
maintained
all
that
stuff.
So
it's
slightly
difficult
to
take
a
completely
microservices
oriented
architecture
and
then
fit
it.
Our
fit
complex
workloads
onto
that
architecture
right
and
that's
where
of
course,
operators
started
to
come
in
I.
B
Think
operators
are
a
very
good
framework.
It's
an
awesome
framework.
The
question
is:
wouldn't
operators
solve
this
problem
and
the
answer
is
here
to
a
certain
extent,
it
does
in
meant
operators
are
custom
logic
that
you
would
write
that
would
essentially
overcome
some
of
the
provisioning
and
scaling
challenges
that
are
natively
available
through
kubernetes
parameters,
but
you
essentially
put
workload
specific
logic
into
a
workload
specific
operator
right,
but
again,
the
operator
still
is
just
handling
the
workload
specific
challenges.
The
CNIC
SI
CRI
challenges
still
reside
outside
the
logic
of
an
operator.
B
Those
still
need
to
be
resolved
right
to
be
able
to
create
an
operator
that
is,
that
works
seamlessly
with
all
these
workloads.
The
next
one
is
around
lifecycle
management.
Unlike
stateless
workload,
stateful
workloads,
when
you
start
they
have
a
long
journey.
They
Yuliya
running
for
years,
Mangia
squatters,
which
means
that
you
have
to
handle
lifecycle
management
like
snapshots,
clones
backups
and
restores.
Now
all
of
that
staying
inside
the
operator
is
not
feasible.
You
really
need
to
rely
on
outside
things.
B
For
example,
two
big
snapshots
you're
to
rely
on
storage
level
primitives
to
take
a
snapshot
right
when
you're
trying
to
create
backups.
You
might
how
to
rely
on
a
backup
tool
to
do
that,
backup
and
stuff
right.
So
it
cannot
completely
be
solved
through
an
operator,
and
the
last
one
I'd
like
to
call
out
is
operators
are
great
for
individual
workloads,
but
if
you
create
a
multi
tier
workload,
how
do
you
handle
the
you
know
the
lifecycle
management
of
a
multi
tier
app?
B
Now
we
want
to
create
a
super
operator
that
spans
multiple
operators,
or
how
do
you
do
that
right?
So
that's
something
that
means
it's
a
it's!
A
very
interesting
problem
right:
it's
something
that
needs
to
be
addressed
too
right.
So
I
see
that
there's
a
question:
why
do
customers
want
to
run
big
data
databases
on
coupon?
B
It's
a
very
good
question
so
so
think
about
this
way
right
in
any
pipeline
or
in
any
multi
pad,
which
is
stateless
somewhere
along
that
pipeline
is
a
database
or
a
Big
Data
Platform
at
a
dive
site,
essentially
compute
only
workloads
either
rely
on
data
coming
in
over
the
network,
or
they
rely
on
data
that
is
sitting
out
in
a
database
or
a
I
mean
they
don't
exist
in
isolation
is
doing
computing
over
nothing
right
now.
Clearly,
kubernetes
has
demonstrated
the
agility
benefits
of
putting
all
the
compute
only
stateless
workloads
right
on
kubernetes.
B
B
If
you
can
do
that,
then
essentially,
you
can
spin
up
entire
stats
and
entire
multi
tier
Stags,
including
stateful
workloads
in
one
shot
I'd,
you
can
lifecycle,
manage
them
very
easily
and
all
that,
so
essentially
it
calls
out
for
the
agility
benefits
that
you
would
see
if
you
can
bring
the
state
full
workload,
sort
of
complex
ship,
full
workloads
also
into
the
kubernetes
world.
Okay,
I
hope
answer
the
question
that
was
posted
on
the
chat
window,
all
right
now,
moving
on.
B
Let's
talk
about
I
just
wanted
to
kind
of
summarize
this
whole
thing
by
looking
at.
If
you
were
to
put
all
of
this
together,
you
know
if
it's
like
assembling
this
nice,
you
have
all
these
great
parts
to
assemble
a
car,
and
you
put
all
of
these
parts
together
right
and
you
expect
that
you
want
to
see
a
car
that
looks
like
this
and
in
the
end,
you
start
you
actually
see
something
like
this
right.
It's
a
nightmare
to
manage,
maintain
troubleshoot
and
stuff
like
that.
B
Okay,
now,
how
do
you
go
about
addressing
thinking
more
solutions
for
this?
Okay?
So,
let's
before
we
jump
into
the
architectural
underpinnings
for
the
solution
right,
let's
look
at
it
from
a
slightly
higher
level
view,
instead
of
just
looking
at
an
infrastructure
components
and
all
that,
let's
reframe
our
thinking.
So
if
you
notice
as
identity
developers
or
DevOps
people,
they
rely
on
applications
right
and
applications
rely
on
infrastructure.
The
in
every
infrastructure
exists
to
sell
the
needs
of
an
application
which
in
turn
exists
to
serve
the
needs
of
a
user.
B
Now,
when
you
look
at
the
solution
space,
the
solution
space
that
we
have
been
essentially
as
all
the
vendors
right
I
talked
about,
are
along
the
lines
of
you
know:
let's
start
solving
it
from
infrastructure
upwards
into
users,
which
means
that
oh
in
order
to
deploy
something.
Oh,
let's
worry
about
first
creating
stateful
sides
and
deployment
bands
and
Peavey's
PVCs
and
all
that
stuff
right.
But
what
is
the
net
goal?
I
mean
if
you
look
at
what
is
the
business
job
objective
right,
your
line
of
business
user?
B
B
If
there's
a
way
in
which
you
can
express
the
apps
needs
and
then
have
a
think
about
like
a
super
operator
that
translates
those
needs
into
the
appropriate
CNI
CSI
entities,
all
those
things
right,
then
you
essentially
can
provide
the
agility
that
one
would
really
want
for
both
deployment,
as
well
as
a
lifecycle
management
of
this
complex
workloads.
Okay,
so
this
is
the
framing
right.
B
Essentially,
what
I
want
to
highlight
is
we
need
to
start
looking
at
the
problem
from
an
app
downwards
instead
of
looking
at
it
from
infrastructure
components,
upwards
right
and
when
I
say
infrastructure,
components,
I
put
things
like
stateful,
says:
replicas,
says
deployments
PVCs
all
that
into
infrastructure
complements
ok,
so
now,
let's
start
digging
a
little
deeper
into
what
would
be
an
ideal
architecture
right.
The
first
thing,
of
course,
is
kubernetes
movements
no-brainer
there
now
because
you're
targeting
data
centric
workloads,
you
need
to
have
a
very
strong
storage
story
here
now
again.
A
B
Does
this
very
strong
story
story
me
right,
so
obviously
you
need
to
have
disk
management.
Obviously
you
need
to
have
volume
management
and
all
that
CSI
is
a
great
framework
to
provide
and
allocate
those
volumes.
But
beyond
that,
what
you
really
need
to
simplify
operations
and
ensure
that
you're
meeting
the
performance
a
smaller
is
your
story
stack
to
understand
the
notion
of
an
application,
so
what
does
it
mean
to
understand
the
notion
of
an
application
and
what
are
the
benefits
right?
B
So
when
a
story
stack
understands
an
application,
what
I
mean
by
that
is
the
storage
stack
provides
primitives
which
allow
the
top
layers
to
go
and
program
it
and
tell
that.
Okay,
these
are
the
different
volumes
on
it.
These
are
the
different
SLA
characteristics
of
the
volumes,
and
this
is
the
deployment
hierarchy.
Slash
fall
domain
constrain
the
application
puts
on
those
volumes
right
see
anyway.
The
storage
sack
should
understand
the
topology
and
the
performance
characteristics
of
your
application
at
a
programmatic
low.
That's
a
very
key
thing
right.
B
The
second
thing
is
once
you
have
that
what
is
the
benefit
right?
The
benefit
is
once
it
understands
this.
You
can
truly
now
start
doing
application
consistent
data
management,
things
like
an
application,
consistent
snapshot,
because
all
you
can
now
do
is
okay.
I
want
to
snapshot
this
particular
app,
and
the
storage
tag
knows
if
I
get.
B
This
particular
app
is
composed
of
these
different
lands
that
are
spread
across
these
different
volumes
are
spread
across
these
different
discs
on
these
nodes
right
and
then
you
can
create
a
consistency
group
because
all
of
them,
and
then
you
can
truly
create
an
app
consistent
snapshot
in
a
similar
way.
It
can
also
truly
do
an
app
consist
or
app
aware
quality
of
service
management,
instead
of
doing
it
at
a
per
volume
basis.
It
can
essentially
do
QoS
management
for
ops
for
an
entire
app
or
partitions
of
an
app.
B
B
So
that's
one.
The
other
thing
I
actually
I'd
not
highlight
here
is
how
around
how
reverse
DNS
needs
to
be
I
also
handle
I.
Think
with
Gordian
is
the
latest
version
of
core
business
that
is
fixed,
but
sometimes
the
reverse
dns
for
apps
does
not
resolve
it
correctly,
and
things
like
louder
as
do
not
come
off
easily.
That's
not
addressed
so
net-net.
B
These
are
the
three
infrastructure
level
components,
but
what
I
said
earlier
is
we
have,
as
as
a
you
know,
as
participant
of
this
community
right,
how
this
ecosystem,
I
think
it's
a
responsibility
to
drive
simplicity
for
the
end
consumers
or
develop
positive
ops
force
right.
So
just
these
three
components
by
themselves
does
not
meet
that
goal
right.
What
you
really
need
for
simplicity
is
a
top-level
view
which
essentially
exposes
primitives.
B
It
translates
any
calls
that
are
made
at
the
top
into
the
appropriate
kubernetes
calls
a
storage
call,
networking
call
and
so
on
right
so
again
for
the
more
technically
inclined
audience-
and
this
is
just
still
a
block
diagram-
maybe
I'll
go
a
little
deeper
right
now,
I'm
actually
sharing
a
little
bit
of
how
we
have
solved
this
problem.
They
might
be
other
solution,
but
how
we
have
solve
this
problem,
I'm
going
to
show
you
share
with
you.
So
this
is
a
behind-the-scenes
architecture.
Again.
B
This
is
a
robin
io
solution,
so
you
here
you
can
see
the
traditional
master,
nodes
and
worker
nodes
of
kubernetes.
The
yellow
orange
components
are
stock,
open,
Eddy's
components.
Obviously
unmodified.
We
are
a
CNC,
have
certified
software
right,
so
everything
is
unmodified
here,
but
all
the
remaining
blue
components
is
what
you
really
need
to
do,
and
this
is
where
the
Robin
components
are
all
the
remaining.
The
blue
components
is
what
you
need
to
to
essentially
overcome
the
CNI
CSI
cri-kee
ATIS
and
operator
challenges
that
I
already
outlined
earlier
right.
B
So,
for
example,
there
is,
on
the
right
hand,
side.
You
see
a
CRI
switcher
that
you
have
built
that
Laos
during
poor
definition
and
all
that
it
would
basically
choose
different
types
of
CR
eyes
right
they
in
coitus.
At
the
same
time,
for
example,
Oracle
RAC
by
the
company
Oracle
is
supported
only
on
Alexei
containers,
so
we
are
able
to
run
Alexei
alongside
docker
on
kubernetes.
B
The
other
one
is
around
docker
extended.
This
is
nothing
but
enabling
certain
options
within
docker
so
that
you
can,
you
know,
purses
the
the
state
changes
made
to
the
root
file
system
across
pod
relocations
and
all
that
right,
so
so
that,
as
well
as
you
know,
things
like
GPU
based
things
right
when
you're,
using
in
Nvidia
as
darker
driver
and
all
that
that
happens
to
that
offer
extended.
Cri
CSI,
of
course,
is
our
storage
stack.
A
B
Of
all
of
that,
on
the
left
hand,
side,
we
have
this
data
I
have
super
operator
that
generalizes,
so
you
don't
have
to
write
an
operator
for
each
and
every
different
workload.
I
just
provides
all
the
primitives
so
that
you
can
bring
in
many
workloads
and
that's
the
way
we
were
able
to
bring
in
prouder
our
Hortonworks
plunk
oracle,
racks,
Kafka
elasticsearch.
What
have
you
SAT,
Hana
and
all
those
workouts
onto
kubernetes?
B
This
is
also
a
there's.
A
demon
set
that
runs
on
every
node
and
what
this
does
is
it
basically
takes
an
iron
trying
to
have
some
demos
but
I
think
it
is
it's
not
complete
without
really
showing
you
feel
fur,
giving
you
a
feel
for
how
it
actually
looks
and
functions
right,
so
I
do
have
the
most,
but
before
we
get
into
the
demo,
so
you
see,
on
the
left
hand,
side
there's
this
component
called
Rob
and
it's
a
tooling
which
is
a
CLI
rest
as
well
as
the
UI
based
pooling
that
we
are
provided.
B
That
simplifies
deployment
of
these
workers
to
an
extend
that
the
developers
does
not
how
to
write
Yaman
files
and
all
that
stuff
and
as
you'll
see
in
the
next
demo,
that
I
show
you.
It
is
the
one
that
takes
the
needs
of
your
application
and
it
translates
them
into
the
appropriate
calls
around
the
CNIC,
Ric
and
I,
as
well
as
kubernetes,
by
running
it
to
a
plan
manager
and
feeding
it
through
an
overlay
scheduler
on
top
of
chaos
scheduler.
B
So
in
all
this
diagram
here
you
see
that
we
are
not
really
modified
a
single
line
of
kubernetes
core,
but
you
use
the
extensibility
features
that
are
built
in
right
to
get
to
this
level
of
sophistication.
Now,
as
I
said
right,
it
will
think
it's
important
to
kind
of
get
a
feel
for
how
it
looks
because
it
this
is
real
right.
So
you
want
to
really
get
to
feel
it
right.
So
I'm,
just
going
to
I,
have
about
three
slides
on
just
few
demos
so
that
we
kind
of
highlight
things.
B
So
here
is
a
dashboard
where
all
these
workloads
are
running
on
kubernetes.
Let's
say:
I
want
to
deploy
a
Hortonworks
one
of
the
very
most
complex
workloads,
because
cotton
works
is
not
just
your
HDFS
and
all
that
it
has
so
many
different
services
right.
Each
other
services
has
so
many
different
quirks
around
Kerberos
integration,
sentry
and
whatnot
right.
So
you
have
to
simplify
how
you
define
or
how
you
compose
your
Hortonworks
deployment
with
all
those
services
right.
B
So
what
Robyn
allows
you
to
do
is
create
a
Yaman
file
that
just
talks
about
these
are
the
different
services
within
Hortonworks
right.
So,
let's
just
see
a
demo,
so
let's
say
somebody
clicks
on
Hortonworks
your
items
like
so
we
render
a
screen
that
looks
like
this
on
this
screen.
They
will
be
able
to
go
and
toggle
and
pick
whatever
services
of
interest
to
them
right,
but
they
want
kafka
with
autumn,
allows
them
on
hi
knots
and
atlas
whatnot
once
they
pick
that
they
can
just
go
and
say.
Ok,
what
are
this?
B
What
is
the
scale
at
which
you
like
to
deploy
each
of
these
services?
What
are
the
compute
resources?
Your
GPU
needs?
What
are
the
deep
units
right?
What
are
the
storage
needs
that
this
particular
workload
has
right?
You
can
here,
you
can
click
on
the
wrench.
You
can
also
go
and
specify
performance
isolates
isolation,
guarantees,
data
protection
policies
right,
whether
it's
replicated
or
it
is
encrypted
or
it's
compressed
and
all
that
stuff.
But
beyond
all
these,
these
workloads
also
have
a
said
earlier
right
have
for
domain
constraints
built
within
to
them.
B
They
have
data
locality,
constraints
built
into
them,
so
you
should
be
able
to
go
and
toggle
and
say
you
know
what
around
data
locality
I
want:
PF
Nikki
across
these
services,
not
just
at
the
board
level,
but
also
at
the
storage
level
and
just
toggle
it,
and
then
this
provision-
and
then
we
basically
take
in
previous
king
I,
showed
you
this
plan
manager
right
it
takes
this.
It
generates
a
plan,
then
it
emits
the
appropriate
pods,
the
PVCs
PVC
specs
services,
all
of
that
stuff.
It
emits
all
of
that
thing.
B
It's
talks
to
the
oven
storage
layer
which
again
as
a
setup
where
and
it
programmatically
goes,
and
provisions.
These
volumes
associates
each
volume
into
a
hierarchy
of
how
it
kind
of
maps
into
the
entire
app
and
all
that
right,
so
net
net
within
a
minute
fume
within
minutes,
you
are
able
to
deploy
very
large
deployments
of
complex
workloads
so
how?
When
I
say
minutes
right?
B
Let
me
use
an
example
right,
so
we
have
demonstrated
at
last
strata
a
500
note
cloud
era:
cluster
running
full-blown
right:
a
production
quality
founded
node
Laura,
the
clustered
about
1.4
petabytes
deployed
in
44
minutes
on
kubernetes
right.
So
that
is
the
power
of
bringing
these
workloads
on
to
kubernetes
right.
Using
a
platform
like
this.
So
beyond
deployment
as
I
said,
deployment
is
one
challenge.
B
You
got
to
worry
about
data
management,
so
let
me
kind
of
show
you
showcase
a
few
data
management
and
how
we
can
up
level
them
from
just
storage
level,
data
management
to
an
entire
app
level
data
management.
Here
we
have
a
Cassandra
cluster
running.
It's
a
ten
partition,
Cassandra
cluster
two
seats,
two
members
that
says
somebody
would
like
to
snapshot
this.
All
they
are
do
is
go
to
actions
and
it's
not
short
you're
the
name
and
then
click
tap
short
right
now.
Nobody
has
to
go
and
specify
what
storage
volumes
need
to
be
snapshotted.
B
How
do
you
snapshot
that
and
all
that,
because
this
commoner
understands
there?
Okay,
this
is:
there
are
n
partitions
here
or
10
components
if
10
pods
here
each
pod
having
certain
number
of
volumes.
This
is
the
consistency
group
and
within
seconds
it
can
snapshot
not
just
the
data
volumes,
but
also
snapshot
the
entire
application
material
right.
B
The
pod
specs,
the
PVC
services
all
of
that
stuff,
and
it
can
create
a
check
point
of
your
entire
app
right
and
even
if
the
apps
topology
changes
over
time,
you
can
just
dissolve
all
those
changes
very
easily
right
and
this
app
level
snapshot.
What
happens
only
how
these
snapshots,
like
obviously,
can
do
time
to
I,
would
like
to
do
with
your
math
right
in
time
crawl
across
different
application
snapshots.
Let's
say,
for
example,
if
Q
s
is
that
a
listen
I
found
a
bug
in
such-and-such
version
and
the
dev.
B
So
you
know
what
I'd
like
to
go
back
and
see
you.
The
bug
also
existed
in
a
pear
tree,
partitions
right-click
overboard,
and
you
can
essentially
go
back
to
that.
That's
one
obvious
benefit.
The
next
August
benefit
is
around
creating
instant
clones
right.
You
basically
go
and
say
this
Cassandra.
As
of
to
the
peaceable
I
want
to
create
a
quick,
lock
right
now
you
don't
have
to
go
and
specify
the
pods.
You
don't
have
to
go
and
say
you
know
persistent
volume
claim
the
source.
Is
this
snapshot
content
in
none
of
that
stuff?
B
Yes
say
you
know
clone
and
then
you've
got
to
translate
this
into
the
appropriate
calls.
You
have
to
go
and
tell
the
storage
if
this
is
a
thin
clone,
that's
happening,
so
you
don't
have
to
copy
the
entire
data
out.
Take
a
referential
copy
right
on
the
network
inside
you
have
to
provide
new
IP
addresses
and
all
that
stuff.
It's
all
automated.
It
happens
in
a
matter
of
seconds
right,
so
that
is
clone
I
mean
I
could
show
you
a
few
more
demos
but
I.
B
A
Awesome,
thank
you
so
much
for
the
great
presentation
we
do
have
some
time
for
questions.
70
minutes,
if
you
have
more
questions,
feel
free
to
drop
it
into
the
Q&A
section
on
the
bottom
of
your
screen
as
well.
Otherwise,
I
will
just
try
to
get
at
least
one
question
answered
from
everyone
that
asked
now.
A
B
Fantastic
question
so
for
the
example
that
I
showed
you
the
power
of
400
Oracle
RAC
clusters,
it's
running
entirely
on
containers,
Aleksey
containers,
specifically
that
because
Oracle,
the
company
only
certifies
Oracle
RAC
in
LXE
containers,
not
doctored,
but
the
moment
they
support.
Docker
will
support
that
as
well.
A
B
So
it's
a
lurid
question
right.
Essentially,
the
question
is
around:
is
a
multi-part
one
right,
NFS
versus
blaster
assassin?
Also,
maybe
can
let
me
generalize
the
question
itself
right.
So
if
your
work
load
requires
file
based
storage
right,
it
is
typically
not
databases
and
all
that,
but
several
other
workloads.
B
Then
you
have
multiple
choices
that
you
can
make
that
obviously
NFS
is
one
and
if
it
is
the
possessive
protocol,
so
you
have
to
go
with
vendors,
who
are
providing
the
protocol
access
right,
so
Gloucester
DFS
is
a
distributed
file
system
right
it
in
addition
to
its
own
proprietary
protocol.
It
also
supports
NFS,
so
it's
an
implementation
of
an
appreciating
world.
So
if
your
question
is,
do
I
choose
between.
Let
me
read
this
way
for
CSI.
So
if
I
have
an
FS
on
all
creators,
nodes
do
I
still
need
Russ,
Travis
I'm,
assuming.
A
B
B
A
B
So
we
don't
need
access
to
the
master
node,
so
it
can,
you
can
have
the
master
nodes,
be
a
completely
different
control
plane.
We
register
with
the
master
nodes,
we
have
our
own
service
account
and
all
that.
So
that's
the
first
part
of
the
question.
The
second
question
is:
does
it
work
with
managed
solutions?
We.
B
A
B
We
have,
in
fact
what
Lecter's
is
a
pretty
cool
project.
In
fact,
that's
one
one,
one
way
to
essentially
run
kbn
alongside
or
things
like
that,
so
we
have
looked
at
both
of
them.
I
think
it's
a
good
solution.
Yes,
I
mean
just
to
pull
other
folks
who
might
not
be
familiar
with
this
is
if
you
would
like
to
run
virtual
machines
alongside
your
docker
containers.
They
are
multiple
project
projects
for
that,
so
what
let
is
one
of
them?
So
if
you
looked
at
them,
okay,.
B
A
B
A
Perfect,
so
that's
one
question
from
anyone.
So,
let's
start
with
the
ones
that
already
had
the
question
so
Bruce
got
another
question:
do
you
find
that
the
storage
performance
is
equivalent
within
a
containerized
environment
versus
decompose
with
less
environment,
or
is
there
a
benefit
in
the
performance
for
one
infrastructure
choice
over
another
yeah.
B
It
doesn't
so
we
don't
have
a
preference
for
a
service
mesh
because
clearly
that's
not
something
I
mean
that
is
complementary
to
the
solution
that
it
is
not
like
it's
a
required
thing,
so
we
don't
prefer
anything.
Customers
use
me
anything
whether
it
is
to
you
on
whatever
it
is.
They
take
it
to
pick
whatever
they
want.
The
second
part
is:
does
it
help
not
Trillium
and
they
are
orthogonal
problems
from
that
perspective
right?
How
data
locality
is
managed
is
actually
a
storage
orchestration
problem
that
that
goes
beyond
the
scope
of
fire.
So
this
mesh.
B
B
Not
there
is
also
a
chicken-and-egg
problem,
I
think
it's
a
lot
of
vendors
who
are
shipping
their
container
of
docker
containers
right
now.
Right
so
I
mean
you
just
you
have
to
see
how
the
ecosystem
revolves
around
this,
but
I.
Think
CRI
o
is
also
here
to
stay.
I,
don't
know
if
there
will
be
a
time
when
it
will
overtake,
but
maybe
it
will
coexist
in
the
short
term
and
or
time
which
are
winds
which
are
has
more
broader
vendor
support
of
things.
B
A
B
So
obviously
there
could
be
managed
services
platform
that
makes
it
user
friendly
right,
but
I
can
answer
it
from
the
perspective
of
Robin.
So
we
do
support
machine
learning.
Work
loads,
such
as
you
know,
distribute
attends
a
flow
cafe
theon
of
those
kind
of
toolkits.
You
know
the
that
notebook
Jupiter,
notebooks
and
all
that
stuff.
B
So
clearly
it
can
be
made
a
lot
user-friendly
because
again,
when
you
are
deploying
all
these
things,
the
fact
that
you
order
Stitch
the
Nvidia
docker
as
your
CRI,
the
fact
that
you
have
to
go
and
kill
a
certain
number
of
GPU
cores
your
workload,
and
if
you
want
to
get
your
training
gear
done
sooner,
you
would
like
to
scale
your
GPUs
up
or
take
them
away
when
you
don't
need
them
all.
That
is
an
operational
challenge
right
and
all
of
that
typically
a
data
scientists
will
not
neither
know
nor
care
about
looking
at
right.
B
They
are
just
interested
in
building
their
models
and
working
at
you
know
the
math
level
of
things
right.
They
don't
want
to
be
worried
about
GPU
allocation
and
scaling
and
stuff
like
that
or
scaling
Mort
and
so
for
worker
nodes.
So
clearly
we
do
make
that
a
lot
simpler,
using
our
our
way
of
elevating
the
entire
experience
from
infrastructure
into
applications
like
the
demos
that
I
showed
you.
A
B
Is
extensible
framework,
although
it
depends
on
what
do
you
mean
by
extensibility?
That
will
be
good.
If
you
can
powered
me
an
email
with
specific
questions,
but
yes,
it
is
extensible
and
extend
that
with
the
single
super
operator,
we
are
able
to
on
board
all
the
workloads
that
I
just
talked
about
writing
coding.
B
It's
a
place
here
because
you're
talking
about
applications
that
have
data
and
that
data
could
have
sensitive
information
right.
So
the
policies
that
our
customers
typically
ask
us
to
enable
on
this
platform
is
the
following
number
one
is
hardware
level
isolation,
so
we
have
to
guarantee
them
that
there
are
certain
workloads
that
are
Hardware
isolated
right,
so
it
essentially
means
that
there's
one
database
that
can
run
only
on
these
set
of
nodes
and
another
database
can
only
the
other
set
of
right.
B
That's
one
way
of
looking
at
it,
then
the
other
way
of
looking
at
it
is
at
the
resource
and
quota
level
how
much
you're
giving
not
just
for
CPUs
and
memory,
which
is
again
mostly
solved
through
the
sauce
limits
and
all
that,
but
also
at
the
storage,
I/o
ops
level
right.
So
that's
the
second
one.
Now
the
third
level
of
multi-tenancy,
which
kind
of
becomes
very
interesting,
is
in
an
enterprise
account
right.
Let's
say
a
user
John
write
user
John
de
Poissy
zone
database.
Now
there
would
be
another
user,
let's
say
Sally
right
now.
B
Sally
also
deploys
her
database
right
now.
If
you
look
at
it
from
a
purely
kubernetes
namespace
perspective,
let's
say
both
of
them
belong
to
the
same
group.
Right
same
devil.
Look,
let
us
say
if
you
put
them
in
the
same
namespace,
then
both
of
them
can
see
each
other's
databases.
So
in
an
enterprise,
that's
a
big
no-no
right,
so
they
essentially,
they
say
that
ok,
whatever
database
is
that
John
spins
up
only
John
should
be
able
to
see
whatever
side
he
spent.
B
Seven
literally
should
be
able
to
see
whatever
John
and
Sally
spin
up
the
tenant.
Admin
should
be
able
to
see
right.
That
is
the
way
in
enterprise
consumes
Thanks
all
right.
So
what
we
had
to
do
is
we
have
to
build
a
our
back
as
well
as
a
multi-tenancy
on
top
of
kubernetes
are
black
mechanisms
so
that
we
can
provide
that
namespace
level
isolations
and
all
that
to
meet
this
particular
enterprise
again
happy
to
answer.
If
you
have
more
questions
on
this,
just
shoot
me
an
email
at
our
third
Robin
Fi,
great.
A
B
A
great
question,
so
our
storage
tag
itself
has
encryption
built
in.
So
when
you
are
deploying
your
workload,
you
can
say
K.
These
are
the
volumes
I
would
like
to
do
data
at
rest
encryption.
So
what
we
do
is
that
we
regenerate
a
40
by
ki
4
per
volume
and
that
key
is
then
encrypted
again
by
an
external
key
management.
Super
key
right
for
a
master
key
which
sits
in
an
external
kms
software
somewhere
else
outside
and
as
a
result,
you
know
the
the
workload
itself
does
not
have
to
worry
about.
B
A
You
so
much
that's
all
we
have
so
thanks
for
joining
us
today,
also
to
all
the
participants
who
didn't
have
any
questions,
the
webinar
recording
in
slides.
We
will
upload
them
later
today,
so
yeah
have
a
knife
for
them.
We
will
also
email
you,
your
link.
They
will
be
on
the
CNCs
website,
so
we
look
forward
to
seeing
you
again
at
future.
Cncs,
webinars
and
yeah
have
a
great
day.
Thank
you
so
much
and
if
you
have
more
questions,
feel
free
to
email,
Potter
thanks.