►
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 provides well defined interfaces to integrate storage and networking through CSI and CNI. However, deploying Kubernetes on hyperconverged infrastructure (HCI) poses multiple challenges.
In this session, we will explore the evolution of public cloud infrastructure and explain how they have overcome some of these challenges using hardware offloads. We will further demonstrate how Diamanti’s bare metal hyperconverged infrastructure has solved these challenges for private cloud environments by leveraging Kubernetes orchestration to deploy containers as well as virtual machines to co-exist on the same platform.
A
I'd
like
to
thank
everybody
who
is
joining
us
today
and
welcome
to
today's
CN
CF
webinar
challenges
in
deploying
kubernetes
on
hyper-converged
infrastructure,
x'.
So
two
things
yeah
we'll
go
back.
Let
me
do
our
Q
con
slide.
I
do
want
to
also
remind
everybody
that
Q
con
cloud
native
con
North
America
our
flagship
event,
and
it
is
coming
up
in
November
in
San
Diego.
A
It
should
still
be
very
sunny,
lovely
in
November,
and
this
is
as
many
of
you
who
have
attended
before
this
is
a
time
for
the
community
to
come
together
to
further
their
education
and
advance
cloud
native
computing.
You
can
go
to
cube
condo
for
more
information
information,
get
your
ticket
and
we're
expecting
about
12,000
people
and
to
sell
that
out.
So
before
we
get
started,
I'd
like
to
also
go
through
a
few
some
housekeeping
items
during
the
webinar,
you
are
not
able
to
Thaksin
attendee.
There
is
a
Q&A
box
at
the
bottom
of
your
screen.
A
B
Thank
you
good
morning,
good
afternoon
and
good
evening.
Folks,
wherever
you
are
greetings
so
I'm,
not
in
director
of
product
marketing
at
diamonte,
along
with
me,
I
have
Naveen
set,
will
be
founding
engineer
at
the
MRT
and
here's
Patel
founding
engineer
at
giamatti
all
right
today.
Today,
we're
gonna.
Take
you
through
the
background
of
AWS
ec2
evolution
as
an
example
I.
C
B
All
right,
Thank,
You
Hiro.
So
let's
take
you
through
some
evolution
here
for
the
next
few
minutes.
The
credit
goes
to
their
two
stalwarts
at
Amazon
Web
Services.
They
are
also
known
as
AWS
Jerry
Hargrove,
who
is
very
famously
known
as
AWS
geek.
Look
him
up
as
it
obvious
geek
and
you'll
find
lots
and
lots
and
lots
of
beautiful
pictures
about
how
things
work,
how
things
are
architected
at
AWS
and
this
picture
a
part
of
the
this
is
a
part
of
the
picture
from
one
of
Gerry
har
cross
drawings.
B
Credit
also
goes
to
James
Hamilton,
with
a
distinguished
engineer,
at
AWS
being
a
dear
oblivious
forever
and
there's
a
bunch
of
publications
that
he
has
done
through
embedded,
rona
and
others
that
we
are
going
to
use
today
to
walk
you
through
some
of
the
evolutionary
aspects
of
the
easy
to
compute
instance
at
AWS.
So
it
all
began
this
way
for
all
of
us
anybody
in
IT.
This
is
a
standard
picture
right,
and
this
is
the
crawl
phase
of
what
Gerry
calls
it.
B
As
for
an
Amazon
compute
instance-
and
this
is
specifically
Amazon
ec2
instance-
and
if
you
go
back
to
history,
the
first
incarnation
of
ec2
came
about
in
2006,
alright
and
up
to
2013.
This
was
the
constant
picture
for
any
compute
node
or
host
at
AWS.
And
if
you
look
at
this
picture,
you
know
it's
got
hardware
on
top
of
hardware.
Its
software
software
that
runs
networking
that
runs
storage,
provides
management,
security
monitoring.
B
You
know,
if
you
look
at
what
Jameis
Hamilton
has
written,
he
basically
sums
it
up
in
one
sentence,
which
is
networking
is
in
effect
in
the
way
and
blocking
the
efficient
optimisation
of
valuable
resources
in
the
data
center.
So
why
is
this?
A
server
is
the
most
expensive
component
in
a
data
center
on
our
server
and
all
the
components
that
go
into
a
server
and
think
about
it.
B
Every
data
center
in
for
a
public
cloud
provider
like
AWS,
there's
hundreds
and
hundreds
of
server
in
any
data
center
and
if
that's
the
most
valuable
asset
that
you
have
something
else
coming
in
and
coming
in
your
way
of
efficient
you
desire
utilization
means
a
lot
in
terms
of
the
cost
means
a
lot
in
terms
of
the
capabilities
at
which
the
they
have
to
provide
to
the
customers.
So
let's
take
a
look
at
now
and
see
how
this
ec2
instances
award
over
time
all
right.
B
B
So
what
we
see
on
the
left-hand
sides
here
is
the
picture
from
ec2
instance,
circa,
2013,
all
right
in
2013,
Amazon
introduced
the
nitro
car
or
the
nitro
system
by
using
the
Nitro
system,
they
offloaded
the
networking
component,
which
was
running
in
software
onto
a
hardware
offload
known
as
nitro,
and
this
nitro
system
was
built
on
quartz,
meaning
commercial,
off-the-shelf
components,
and
basically,
just
by
doing
this,
they
got
20%
additional
bandwidth
on
the
network,
and
this
is
the
c3
instance.
So
this
the
evolution
from
c2
to
c3
20%,
additional
bandwidth
and
50%
latency
reduction.
B
So
your
latency
went
down
by
50%
reduced
performance
variability,
which
means
you
could
expect
much
more
deterministic
performance
when
you
ran
something
ran
a
virtual
machine
on
top
of
the
system
compared
to
an
ec2
system,
alright,
so
that
was
the
first
technique
that
they
used
to
offload
the
network.
Of
course,
you
know
the
taste
was
good,
so
next
comes
C
3
instance,
and
that
was
one
year
later
in
2014
and
with
the
introduction
of
Annapurna.
B
At
that
time,
the
storage
subsystem
of
the
storage
system,
which
was
running
in
software,
got
moved
to
Hardware
offload,
and
that
was
also
a
cart
system,
meaning
of
the
shelf
system
ASIC
based
and
by
now,
moving
the
storage
component
to
the
hardware
layer
to
offload
the
system.
They
gained
12.5%,
more
compute
out
of
the
environment.
What
that
means
is
if
we
have
a
hundred
data
centers
previously,
they
basically
eliminated
at
least
12
of
them.
That's
a
huge
huge,
huge
cost
savings.
First
of
all,
on
top
of
that,
it's
not
only
about
cost.
B
C
B
You
know
more
wiggle
room
to
play
with
and
more
applications
to
be
on
loaded
onto
the
same
infrastructure
because
of
higher
performance.
So
there
is
a
few
things,
though,
that
we
need
to
work.
You
know
compare
and
contrast
here
by
the
time
we
got
to
the
c5
instance.
The
unimportance
system,
which
was
used
to
the
management,
security
and
monitoring,
was
based
off
a
custom
ASIC,
not
cots
all
right.
That's
just
you
know,
that's
what
it
is.
B
That's
what
the
picture
says
as
well
as
one
other
aspect
here
is
the
hypervisor
layer
stayed
on
from
left
to
right.
However,
the
hypervisor
on
the
first
three
is
different
from
the
hypervisor
on
the
right
hand:
side,
because
the
right
hand,
side
I
per
visor,
you
know-
is
known
as
the
nitro
hypervisor,
with
additional
capabilities
to
enable
certain
other
applications
to
be
run
on
the
system.
B
Alright,
so
by
separating
control
and
data
plane,
they
also
were
able
to
easily
do
billing
of
instances
and
so
on
all
right.
So
now
this
is
the
evolution.
That's
happened
over
a
period
of
time,
so,
in
summary,
you
know
offloading
storage,
networking
capabilities
on
you
know,
cards
based
systems
or
custom
ASIC
based
systems
provides
us
better
in
our
reduces
performance.
Variability
provides
us
with
better
performance,
reduces
latency
and
so
on,
all
right.
B
So
let's
have
that
in
our
mind
and
that
evolution
in
mind
and
let's
see
how
data
center
has
award
over
a
period
of
time.
So
here
for
your
reference,
these
are
the
four
variations
or
the
form
factors
of
the
e.r
obvious
nitro
cards
for
your
reference.
There's
the
URL
take
a
look
at
them
at
your
free
time.
So
now
let's
go
ahead
and
take
a
look
at
how
data
center
looks
today.
B
How
hyper-converged
infrastructure
in
a
data
center
looks
today
and
what
are
some
of
the
parallels
that
we
can
draw
from
public
cloud
providers
like
AWS
and
see
where
we
can
land
or
where
we
should
be
heading
towards
in
the
data
center?
So
here
is
a
picture
and
I
walk
you
through
this
from
left
hand,
side
to
right
hand,
side
next
couple
of
minute
and
there's
a
little
bit
of
reality
here,
there's
a
little
bit
of
a
fiction
here
and
then
there's
a
little
bit
of
a
reality
here.
B
So
I
will
tell
you
why
I
am
saying
that
in
such
a
funny
manner,
all
right!
So,
let's
start
on
the
left-hand
side
here.
So
it's
known
as
first
of
all
hyper
control
infrastructure
is
the
de
facto
infrastructure
that's
being
deployed
in
the
data
center
today,
in
every
enterprise
in
every
service
provider,
environment
for
any
IT
workload
deployment
all
right.
So
with
I
watched
one
dot,
o
the
pioneers
of
HCI.
B
You
know
visible
Nutanix
VMware,
as
you
all
know,
started
off
by
packing
networking
storage,
compute
onto
a
single
node,
a
single
server
and
basically
bringing
more
efficiencies
in
terms
of
packing
things
into
a
server.
At
the
same
time,
the
what
we
also
observed
with
hyper-converged
1.0
is
that
host
is
heavily
taxed
in
terms
of
utilization
and
performance.
There
is
applications,
application
starvation
due
to
the
way
that
virtual
machines
run
on
an
AI
provider
environment.
B
The
noisy
neighbor
problems,
persisted
SaaS
could
be
only
guaranteed
to
a
certain
extent
or
maybe
not
at
all,
sometimes,
and
it
it
costed
a
whole
bunch
of
money
still
to
deploy
these
systems.
So,
alright,
let's
keep
that
keep
that
one
dollar
picture
in
mind.
Now,
let's
take
the
learnings
from
AWS
and
say
and
say
what
is
we
offloaded?
The
networking
component
in
NHC
I
want
Auto
environment
and
made
that
HCI
1.5
right.
So
that
is
the
second
picture
from
the
left-hand
side.
Alright,
let's
fast-forward.
B
What
is
we
also
learnt
from
the
storage
evolution
in
AWS
and
offloaded
that
onto
another
storage
system
in
hardware?
Okay,
that's
HCI,
2.0!
That's
basically
following
AWS
as
your
in
terms
of
and
areas
in
terms
of
outpost
and
nitro
that
you
might
have
seen
some
announcements
on
right.
So
if
this
is
a
what-if
scenario
where,
if
we
are
offloaded
both
networking
storage
on
to
HCI
to
dot,
oh,
we
would
have
gotten
much
more
efficiencies
in
parallel
with
what
AWS
got
with
respect
to
networking,
storage
and
so
on.
B
However,
hypervisor
still
remained
in
the
picture,
not
only
that,
let's
also
take
a
look
at
the
current
HCI
solutions
that
we
have
in
the
market
today,
right
in
all
of
the
HCI
solutions
that
are
available
today.
The
instant
storage,
which
is
also
known
as
ephemeral
storage,
is
always
in
a
pooled
storage
environment.
It
is
never
in
a
local
storage
environment
on
the
host,
however,
public
cloud
providers
have
been
able
to
solve
this
problem
with
hardware,
offloads
and
other
mechanisms
to
actually
provide
an
instant
storage
on
the
host.
B
That
brings
a
lot
of
efficiencies
that
provides
the
QoS
capabilities
that
is
critically
needed
for
a
workload
to
run
in
the
environment.
So
that's
absolutely
missing
today,
all
right,
so
diamonte
looked
at
these
progress
being
made
in
the
industry
as
well
as
the
learnings
that
we
picked
up
along
the
way,
and
we
adopted
these
things
right
from
day,
one
in
our
approach
to
building
the
hyper
current
infrastructure
for
kubernetes.
So
at
the
MRT
we
have
networking
and
storage
offloads
along
with
open
source,
kubernetes
patch
packaged
together
for
a
cloud
native
infrastructure.
All
right.
B
So
with
this
we
are
able
to
achieve
95%
hostel
is
butyl
ization.
The
hypervisor
is
completely
eliminated.
There
is
no
noisy
neighbor
problems.
All
those
are
taken
care
of
due
to
the
way
the
hardware
offload
works
for
both
networking
and
storage
SLA
guarantees
can
be
provided
to,
as
granular
has
100
microseconds
of
latency
and
providing
the
lowest
TCO
at
the
same
time.
B
Now,
not
you
know,
if
you
look
at
every
IT
team
out
there,
they
are
not
given
a
white
piece
of
paper
everyday
or
a
blank
piece
of
paper
every
day
to
restart
their
IT
environment.
They
will
always
have
a
set
of
legacy
workloads
which
may
not
be
containerized
at
all,
which
are
yet
to
be
containerized,
so
they
would
need
to
run
in
a
virtual
machine-based
environment.
So
how
would
we
solve
that
problem
so.
B
In
the
CSA
of
community,
you
know
the
community
is
together
brought
forward.
The
notion
of
C&V
or
container
native
virtualization
and
coop
board
is
one
of
the
projects
in
this
under
this
umbrella
within
coop
word.
The
idea
is
to
using
collaboration.
Coop
word.
The
idea
is
to
run
containers
and
virtual
machine
as
equal
citizens
on
the
same
infrastructure,
which
is
either
conversate,
auto
plus
here
with
kubernetes
as
the
orchestrator,
and
why
is
why
is
this
important?
B
This
is
important
because,
regardless
of
the
workload,
whether
it's
a
container,
whether
it's
a
virtual
machine,
they
both
can
be
orchestrated
using
kubernetes
if
they
are
a
set
of
port
specs
and
you
deploy
a
container.
You
deploy
a
set
of
containers,
you
deploy
a
virtual
machine
or
a
set
of
virtual
machines.
It's
the
same
mechanism.
It
is
the
same
tool.
It's
the
same
learning,
it's
the
same
training
that
you
need
to
have
right,
and
this
is
very
important,
because
simplicity
drives
efficiency.
B
The
the
most
important
aspect
to
observe
there
is
that,
for
anybody
to
run
a
virtual
machine
there
to
go
through
the
vSphere
way
of
doing
things,
whereas
when
somebody
wants
to
light
up
a
set
of
containers,
they
will
have
to
go
through
a
different
path
and
that
results
in
two
sets
of
tools
for
dudas
two
different
workload,
types,
two
different
training,
training,
two
different.
You
know
multiple
training
sessions,
etc,
etcetera,
etcetera,
so
that
kind
of
comes
in
the
way
of
simplicity.
B
C
Hey
thanks
marine
thanks
for
walking
through
the
whole
evaluation
process
that
happened
over
these
few
years.
Let
us
now
look
at
the
requirements
that
came
up
during
this
process.
Right
I
mean
if
you
step
back
five
years
or
so
container
technology
had
just
started
being
touted
as
the
next
wave
of
disruption.
The
way
applications
will
be
deployed
and
delivered,
and
this
with
oncoming
change,
the
requirements
for
an
HCI
flash
comm
had
to
be
revisited.
So
so,
let's
look
at
from
just
containerized
applications
perspective
right.
You.
A
C
Multiple
applications
running
what
are
the
new
requirements
from
network
and
storage
side.
From
this
perspective,
you
want
multiple
application,
but
you
want
guaranteed
SLS
for
these
applications
from
network
and
storage.
You
want
consistency
in
performance
predictability
in
performance.
So
what
does
it
map
to
on
network
side?
If
you
look
at
it,
the
technology
has
already
started.
C
They
were
already
off-the-shelf
chips
that
could
guarantee
performance
that
could
give
Hardware
cubes
to
your
application
right
these.
These
allowed
you
to
program
minimum
guarantees
maximum
limits,
as
at
each
container
level,
at
each
virtual
function
level
that
virtual
function
could
always
be
extended
to
container.
C
Let's
extend
this
on
the
storage
side.
Around
the
same
time,
nvme
started
becoming
standardized,
so
now
you
could
have
the
same
way.
You
had
it
on
networking
site.
You
could
have
chill
function
which
could
map
to
namespaces
at
the
volume
at
the
storage
layer,
where
you
could
have
hardware
queues
for
each
of
these
virtual
functions,
and
then
you
could
basically
guarantee
minimum
guarantee,
as
well
as
put
maximum
limits
on
each
of
these
virtual
functions,
basically
meaning
for
each
application.
You
could
guarantee
a
certain
amount
of
AI
ops.
C
A
C
This
evolution
that
happened
there
was
a
physical
aspect
also
that
was
out
there
networking
side.
The
bandits
were
going
from
10
gauge
to
25,
gig
or
party
gave
50k
and
even
hundred
gigs
with
sub-millisecond
latency.
Similarly,
on
the
storage
end,
we
are
talking
about
a
million
I
ops
becoming
very
normal
again
at
some
millisecond
level.
So,
with
all
this
in
mind,
now
you
have
to
really
review
revisit
how
your
HGH
platform
is
going
to
look
at
move.
C
1-Year
forward
and
kubernetes
starts
getting
a
strong
foothold
as
orchestration
platform
of
choice
from
multiple
applications
running
on
a
node.
You
are
transitioning
to
multiple
instances
of
applications
running
on
multiple
nodes
and
handling
of
application.
Failover
is
now
part
of
the
core
design
of
this
orchestration
platform
through
different
sync
groups
and
see
in
a
CS
playing
of
course,
an
important
role
here.
C
The
CNI
and
CSI
standards
evolved
I
mean
of
course,
flex
volume
being
a
precursor
for
this,
on
the
CSI
side
and
on
the
scheduler
side,
a
way
to
extend
the
scheduler,
which
was
way
more
aware,
could
take
decision
more
intelligently,
based
on
its
knowledge
of
the
resources
of
the
underlying
hyper-converged
infrastructure.
So,
let's.
A
C
Side,
IP
address
or
network
endpoint
being
another
way
of
referring
to
it.
It
should
be
dynamically
manageable
without
the
user
having
to
provision
it
for
each
and
every
application.
Instance
that
comes
up
goes
away,
but
then
look
at
the
other
way.
There
could
be
certain
application
that
would
require
static
configuration.
They
want
a
nice
endpoint
to
be
persistent
with
the
instance
of
an
application
ability
to
have
visibility
of
these
endpoints
at
the
network
layer
to
allow
monitoring
or
even
enforcing
policies.
C
C
C
Sorry
about
that,
similarly,
on
the
storage
end,
you
wanted
static
and
dynamic
provisioning
from
so
it's
perspective
or
from
volume
perspective.
You
want
it's
synchronous,
mirroring
where
your
application
would
have
persistent
data
across
different
nodes,
and
there
should
be
synchronous
you,
the
application
failover,
should
not
have
to
worry
about
a
Delta
between
the
state
of
data
across
these
nodes.
You
want
rich
feature
set
from
enterprise
customers
perspective.
You
want
snapshots,
you
want
ability
to
restore
the
snapshot,
you
want
to
take
backup
and
you
want
the
ability
to
restore
these.
C
Now,
high
availability
zones
from
enterprise
customers
perspective
normally
maps
to
campus
clusters.
These
are
data
centers,
not
that
far
apart,
let's
take
from
1550
miles
or
so
now
the
requirements
are
from
network
and
storage
a
little
bit
different.
On
the
networking
side,
you
want
your
administration
to
be
able
to
configure
different
subnets
across
different
zones.
C
So
when
applications
are
coming
across
up
on
different
zones,
they
get
IP
addresses
they
get
endpoint
assigned
dynamically
automatically
on
the
subnet
where
that
application
comes
up
and
the
network
should
be
laid
out
such
that
these
are
routable
across
these
data
centers.
On
the
storage
side,
you
want
your
mirrors
to
be
created
to
be
placed
across
these
zones
so
that
a
failover
on
one
zone
allows
you
to
move
the
application
to
another
zone
and
having
the
data
available
synchronously
in
that
zone
as
well.
C
Now
all
this
works
very
well
for
containerized
applications,
but
what
about
applications
that
are
still
on
this
path
of
transformation?
The
yet-to-be
containerized
application?
You
don't
want
to
have
a
separate
infrastructure
dip,
deploy
such
application
and
through
Cubert
project
under
ciencia.
There
have
been
some
great
work
done
here:
ability
to
run
applications
in
a
virtualized
environment,
but
inside
a
container
framework
refer
to
as
container
native
virtualization
on
networking
and
storage
perspective.
C
You
don't
want
anything
to
change
from
the
way
you
did
your
cloud
native
application
itself.
You
want
the
same
feature.
Parity,
you
want
the
same
performance
and
you
want
a
single
pane
of
managing
these
applications.
You,
you
have
learned
Kuban.
It
is
all
ready
to
deploy
your
applications
natively.
You
want
these
application,
but
yet
to
be
containerized.
Applications
to
be
also
managed
exactly
in
the
same
way.
You
don't
want
to
learn
a
different
framework
for
the
such
applications.
C
Now,
stepping
back,
given
all
these
requirements
defined
for
an
HDI,
the
management
of
these
components
is
also
an
integral
part
of
an
HDI
requirement,
again
not
very
different
from
the
offerings
in
the
cloud,
whether
it
be
for
configuration
management,
user
management,
Active,
Directory
or
user
policy.
Informant
enforcement
Arbor
should
also
be
considered
when
designing
or
evaluating
a
platform
for
deploying
cloud
native
application
under
this
new
paradigm.
So,
given
all
these
requirements
are
defined,
let's
look
at
one
of
the
solutions.
C
D
You
Naveen
and
Narine
for
the
great
introduction
in
this
section,
I'll
go
ahead
and
give
a
demo
of
a
multiple
demos.
So
there
are
three
demos
that
I've
set
it
up.
First,
we'll
go
over
the
setup
that
I'll
be
using
it.
The
kubernetes
cluster,
which
is
deployed
on
to
the
HPI
appliance
and
the
same
cluster
will
use
to
deploy
a
containerized
workload,
which
is
a
wordpress
application.
That's
an
example:
I'll
use
it
to
deploy
it
and
we'll
use
the
same
of
cubanía
test
cluster
and
deploy
or
KVM
to
showcase
that
yet
to
be
containerized.
D
Applications
can
also
be
deployed
onto
the
same
infrastructure
using
the
same
Kuban,
a
test
cluster
and
in
the
fourth
section,
which
will
be
the
last
demo
in
that
one.
We
will
showcase
the
benefits
of
hardware
offloading
for
the
network
and
storage
resources
and
how
we
can
use
those
benefits
to
provide
the
I/o
isolation
for
application.
First,
VM
instances
along
with
the
QoS
for
the
performance.
D
Now,
let's
go
ahead
and
take
a
look
at
the
demo
demo
setup
type
I'll
be
using
it.
So
I'll
use
a
three
node
cluster
as
I
mentioned.
This
is
an
HCI
platform
of
and
on
which
we
have
clustered
the
three
node
Cuban
a
test
cluster.
As
you
can
see,
there
are
blue
and
green
components.
Blue
are
all
open
source
cuban
a
test
component.
D
D
Benitez
construct,
called
storage
class
2
dynamically
provisioned,
the
persistent
storage
onto
the
diamonte
IO
layer,
as
you
can
see
there
are
three
discs-
are
drawn
onto
the
picture:
green
disc.
Those
are
nothing
but
the
three
replicas
after
persistent
volume
that
my
sequels
will
provision.
These
three
reps
replicas
are
synchronously
replicated.
What
does
that
mean?
D
Now
the
mi
di
layer
also
provides
a
way
to
take
the
snapshots
of
these
replicas,
because
these
replicas
are
synchro
a
synchronously
replicated.
You
can
use
either
of
the
replicas
to
take
a
snapshot
into
given
a
time
trip,
and
these
snapshots
can
also
be
used
to
back
up
into
the
third-party
backup
storage
like
NFS
or
AWS.
D
D
So
first
I
will
go
ahead
and
login
to
the
cluster
that
we'll
be
using
it
to
do
a
to
the
demo.
So,
as
I
mentioned
before,
it
is
a
three
node
cluster
using
a
four
note,
but
fourth
node
is
using
as
a
standby
right
now.
We'll
use
this
fourth
node
into
the
later
part
of
the
demo.
So
we'll
go
ahead
and
mainly
use
the
three
nodes
of
the
cluster.
D
Using
to
see
allies
here,
one
is
the
cube
city,
which
is
open
source
kubernetes
CLI,
which
gives
you
third
details
from
the
queue
bonitas
clusters.
Time
point-
and
there
is
another
CLI
here
as
a
dcpl
CLI,
which
is
a
DM
Aunty
infrastructure
level
CLI,
which
gives
you
the
more
awareness
from
the
infrastructure
force
and
resource
pooling
standpoint.
D
D
Now,
let's
look
at
into
the
details
of
what
is
the
pod.
Spec
looks
like
so,
if
you
remember
from
the
our
pictorial
way
how
the
storage
is
going
to
be
provision,
we
have
mentioned
that
we
will
be
using
a
dynamic
provision
and
we'll
use
a
storage
class
that
is
Pro
construct
that
is
provided
by
the
Kuban,
a
test
to
provision
that
storage
or
perturbation
the
volume
onto
the
Diamanti.
Here
it
says
that
storage
class
we'll
be
using
is
a
mirror.
That
means
we
will
go
ahead.
Let's
look
at
the.
What
is
this?
D
D
Now,
let's
go
ahead
and
deploy
the
WordPress
stateful
set
now
once
the
application
of
right
now
we
have
my
sequel
instances
turning,
so
this
is
the
WordPress,
my
sequel
instance
that
we
deployed
and
we
had
requested
that
we
needed
a
three-way
mirrored
volume
or
mirrored
replicas
for
a
given
my
sequel
instance
to
be
deployed.
Now,
if
we
zoom
in
into
this
volume,
which
was
dynamically
provisioned,
we
will
see
that
it
has
provision
or
3-way
map
replicas
on
two
or
three
different
nodes
of
the
cluster,
and
these
all
replicas
are
synchronously
replicated.
D
D
Now,
let's
take
a
look
at
the
pod
speed,
so
sv
deployed
one,
my
sequel
instance:
it
is
into
a
running
state.
It
is
running
into
the
node
1
and
we
have
three
instances
of
the
WordPress
stateful
site
running,
because
we
have
three
node
cluster
and
we
had
requested
for
the
three
replicas.
So
we
have
all
three
instances
off
the
replicas
running
on
to
the
three
different
nodes
of
the
cluster.
D
Now,
let's
go
ahead
and
in
this
section
we'll
go
ahead
and
deploy
a
KBM
instance
which
can
be
used
to
run
the
yet-to-be
containerized
application
on
to
the
same
queue
bonitas
cluster.
This
gives
us
a
view
on
how
you
are
able
to
deploy
the
same,
how
we
are
able
to
use
the
same
node
and
also
deploy
the
containerized
workload
along
with
the
KBM
workload
here.
I'll
just
give
before
we
go
ahead
and
deploy
it.
D
I'll
just
give
a
little
little
bit
deeper
view
into
how
we
are
able
to
achieve
that
and
how
we
are
able
to
use
the
same
infrastructure
to
deploy
both
of
KVM
workload
along
with
the
container
workload
so
and
high-level.
If
you
are
aware
of
the
q''-word
project,
the
design
is
very
much
similar
to
the
Q
part.
Where
the
philosophy
is,
we
want
to
run
a
key
VM
inside
a
container,
so
they
can
coexist
on
to
the
same
infrastructure
along
with
the
container
workload
in
this,
we
are
using
a
premium
as
an
this.
D
D
We
will
use
the
same
humanities
Orchestrator
to
deploy
the
V
ends
the
same
wave.
It
deploys
the
container
workload
and
so
based
on
the
because
of
the
HCI
and
by
F
offloading
the
network
and
the
storage
resources.
We
are
able
to
achieve
the
consistent
IO,
isolation
and
quality
of
service
for
the
both
containers
and
the
VM
workload
using
the
PCI
pass-through
mechanism.
D
So
here
in
the
diagram,
you
are
seeing
two
Nick
components
or
one
as
a
tonight
VF
and
another
one
as
an
nvme,
V
F,
so
every
application,
or
every
every
container
or
every
VM,
which
gets
probation
on
to
the
HCI
or
dr.
diamante
x-ray
out
adapter.
It
gets
in
its
own
isolated
or
its
own,
isolated,
vs,
/,
a
container
or
the
Pearl
VM.
D
So
here
let's
say:
if
the
VM
requires
a
network
and
the
storage
resource,
both
of
them,
both
of
them
will
get
its
own
Silv
function
for
be
at
a
fork
network
and
the
storage.
So
this
gives
you
a
way
of
provisioning
or
make
a
consistent
way
of
getting
an
isolation
and
also
guaranteed
QoS
for
a
given
application
or
for
a
given
VM
instance.
D
Now
this
is
a
little
more
technical.
I
won't
go
into
each
and
every
component
detail,
but
this
is
kind
of
a
high
level
picture
which
gives
you
the
details
on
how
the
same
code
path
or
same
Cuba,
Cuba
needed
orchestration
can
be
used
to
deploy
the
power
pot
container
or
a
VM
instance
onto
the
same
infrastructure.
So
here
there
are
two
workflows
which
are
drawn
one.
The
orange
one
is
a
part
of
the
regular
container
native
workload
and
the
red
one
is
the
KVM
deployment
workload.
D
So
if
we
say
VM
deployment
is
here
in
this
case
is
actually
implemented
using
of
Cuban
itis
construct
called
CI
these
custom
resource
definition,
so
kvn
objects
are
exposed
as
a
custom
resource
definition
on
to
this
Cuban.
It
is
cluster.
So,
whenever
a
KBM
object
gets
created,
the
custom
controller
kvn
controller,
which
is
in
the
green
component,
underneath
the
API
servers
will
wash
onto
those
instances
and
it
will
act
on
it
here.
D
We
are
seeing
other
components
like
scheduler,
Network,
Controller,
x2h
controller,
so,
whether
you
probation
or
better,
you
will
deploy
a
container
all
your
deploy
of
VM,
underneath
all
the
green
components
will
be
used
in
a
similar
manner.
It
is
there
they
are
both
same
in
case
of
provisioning,
the
storage
or
network
for
the
container
or
the
VM.
The
code
part
will
remain
same.
This
gives
us
the
benefit
of
having
the
same
features
like
storage
classes.
Dynamic
provisions
was
static,
provisioning
for
the
storage
and
network
to
be
exercised
for
both
pod
and
the
KVM
workloads.
D
D
Now
this
is
the
pictural
view
of
how
we
will
how
I
will
go
ahead
and
deploy
the
kvn.
So
if
you
remember
from
the
first
demo,
we
had
deployed
a
my
sequel
and
one
of
the
wordpress
instance
was
running
into
the
node
one
in
this
demo.
I
will
go
ahead
and
deploy
a
KVM
instance
onto
the
same
node.
Just
to
demonstrate
that
you
can,
you
are
able
to
deploy
pub
KVM
and
container
workload
onto
the
same
node
of
the
same
kubernetes
cluster
underneath
io
layer
is
exactly
the
same.
The
way
we
will
provision.
D
In
this
case
I
will
take
an
example
of
provisioning.
The
persistent
storage
using
us
static,
provisioning
just
to
showcase
the
static
provision
onto
the
cabinet,
is
cluster
for
the
KVN,
and
you
can
still
use
the
same
storage
features
like
mirroring
synchronous,
replication
snapshots
and
also
taking
a
backup
of
these
snapshots
and
restoring
this
back
up
into
the
persistent
volume.
D
So,
as
I
mentioned,
we
have
extended
the
kids,
kubernetes
CR
DS
to
support
octavian
as
a
primary
object
onto
the
cluster.
So
this
is
the
KPM
IRC
ID,
and
this
is
the
custom
JVM
controller
that
we
have
written
to
watch
on
to
the
k,
vm
c
ID
is
being
created
on
to
the
Kuban.
It
is
cluster
and
then
take
on
or
take
an
action
on
it.
D
D
This
is
a
static
color
endpoint
because
for
the
PM's
you
want
to
make
sure
the
IP
addresses
which
are
allocated
once
they
persist
for
reboot
or
redeployment
of
the
same
instances
or
in
case
of
node
failures
or
zone
failures
onto
the
same
kubernetes
cluster.
So
end
user
doesn't
have
to
worry
about
IP,
address
changes
and
node
configuration
changes,
and
things
like
that,
as
I
mentioned
before,
we
are
using
a
webserver
base
of
pulling
the
image.
D
So
this
is
the
HTTP
endpoint
from
where
the
sent
os7,
dots,
forth,
Q
curve
image
will
be
pulled
and
booted
it
will
be
used
for
VM
boot
up.
This
is
the
way
we
are
able
to
expose
the
reserve
the
resources
for
a
VM
instance.
The
number
of
CPU
cores
that
we'll
be
using
is
16
and
memory
will
request
it
for
32
gig
of
memory.
D
Today
there
are
two
ways
to
access
the
terminal,
our
serial
console.
They
are
itself
a
graphical
VNC,
a
remote
control,
way
of
for
graphical
remote
control,
way
of
accessing
the
VM.
This
is
just
the
index
for
it
to
use
it
for
which
index
to
use
for
the
graphical
VNC
index,
and
here
these
are
all
the
same
volume
constant-
that
you
would
persist
and
volume
constant
that
you
would
see
it
into
a
container,
regular
container
or
regular
spots
back
here
you
there
are
two
persistent
volumes.
D
We
have
specified
a
one
as
a
volume,
images
and
another
one
is
a
data
volume
which
is
a
volume
one,
so
volume
images
is
the
persistent
volume
that
I
will
use
to
persistently
save
the
configuration
or
the
boot
image.
So
the
reason
we
want
to
use
the
persistent
volume
is
once
the
VM
is
boot
booted.
If
the
end
user
is
making
any
configuration,
changes
like
it
is
making
any
changes
in
two
hours
without
local
or
the
way
the
application
should
start
once
the
VMs
booted.
D
You
want
to
keep
those
configuration
changes
persistent
on
to
the
persistent
volume
to
make
sure
that
they
are
persisted
across
reboot
their
persisted.
If
the
KVM
instance
moves
from
one
node
to
another
node
or
it
moves
from
one
zone
to
another
zone,
this
volume
two
is
the
volume
one
is
the
data
volume.
D
This
volume
is
exposed
as
a
PCI
pass-through
inside
the
VM
and
we
are
using
a
block
device
as
an
SS
type,
and
this
support
was
added
into
the
Flex
volume
to
make
sure
that
we
are
able
to
do
the
PCI
pass-through
for
a
storage,
persistent
volume,
storage
and
also
able
to
get
the
guaranteed
QoS
and
iOS
relation
for
the
VM
instances
same
way.
We
are
able
to
get
it
for
the
container
workload.
D
Now
we'll
go
ahead
and
deploy
the
k,
vm
instance
using
the
same
pot
spec.
Let's
go
ahead
and
provision
the
endpoint,
which
is
the
EP
one
and,
as
I
mentioned,
will
provision
the
storage
with
the
static
provisioning,
so
we'll
use
a
back-end
CLI
to
create
a
persistent
volume.
This
is
a
volume
image.
One
is
the
persistent
volume
for
storing
the
boot
image,
and
this
is
our
block
volume,
which
will
be
exposed
as
a
PCI
pass-through
device.
D
Now,
as
we
see,
the
KVM
instance
is
created
under
the
kV
MC
IDs
and
now
custom
KVM
controller
would
have
created
the
KVM
pod
for
the
given
CI,
a
given
K
VM
instance
that
we
created
here
as
we
see
that
same
k,
vm
instance.
We
deployed
it
on
to
the
same
node,
where
we
have
one
of
the
wordpress
instances
running
and
also
the
my
sequel
instance
is
running.
D
Now
this
is
the
IP
address
got
attached
or
it
was
reserved
for
a
given
k.
Vm
instance,
as
you
can
see,
it
is
underneath
using
an
SRO
BBF
for
this
given
instance,
and
these
are
the
two
storage
wall.
These
are
the
two
persistent
volumes
that
got
assigned
for
a
VM
instance
and,
as
you
can
see
the
first
one
wall,
one
one
was
the
block
device.
D
D
D
Okay,
now
we
will
move
on
to
the
next
demo,
which
is
the
last
demo
of
this
section.
We
would
like
to
do
and
I'd
like
to
do
showcase
the
IO
isolation
with
us
for
performance
which
showcases
the
benefits
of
offloading
of
both
Network
and
storage
to
the
hardware
and
how
you
can
get
the
guaranteed
or
QoS
or
guaranteed
performance
for
a
given
container
or
a
VM
workload.
D
So
in
this
demo,
so
we
have
four
node
cluster
I,
just
uncoordinated
to
take
advantage
of
using
a
four
node
cluster
and
I
would
try
to
deploy.
I
would
try
to
dedicate
a
node
one
for
all
the
KVM
instances
deployment.
So
we
just
use
the
same
kubernetes
construct
to
label
the
node
for
the
KVM
deployment,
just
to
make
sure
that
you
are
all
the
KBM
instances
that
we
deploy
on
to
the
cluster
only
goes
on
to
the
node
one
and
all
the
container
workloads
we
will
dedicate
on
the
node
two
three
and
four
here.
D
D
So
we
just
unguarded
the
1/4
node
into
the
cluster,
so
we
have
a
four
node
cluster
here
we
want
to
take.
We
want
to
demonstrate
to
use
our
usage
of
a
performance,
fear
and
guaranteed
io
isolation
and
the
performance
for
the
container
and
VM
workload.
So
we
have
divided
tub
webs
were
deployed
at
three
performance
tiers.
Here
one
is
a
best-effort
high-end
medium,
as
you
can
see
there
reserved
or
storage
I
ops
for
bicipital,
zero
and
network
bandwidth
is
zero.
D
That
means,
if
a
system
has
system
have
any
two
gifts,
they
will
get
some
storage
I
of
the
network
bandwidth
based
on
the
best
effort.
Hi
is
going
to
get
the
maximum,
which
is
20,
K
and
500.
Meg
and
medium
is
the
next
level
which
is
5,
K,
+,
125
Meg.
You
can
still
use
the
same
constructs
to
get
the
maximum
to
limit
the
maximum
storage,
I,
ops
and
maximum
network
bandwidth
also,
but
in
this
case
we'll
just
will
demonstrate
the
mint
requirement.
D
D
D
Okay,
so
here
is
the
way
we
are
able
to
look
at
the
different
applications.
Let's
go
and
take
a
look
at
them
good,
while
the
other
container
workload
is
coming
up.
As
we
see,
we
hide
deployed,
ok,
VM
instances
on
to
the
node
one
of
the
cluster
here,
as
we
can
see
because
of
the
hardware
offload
network
and
storage
hardware
offload
your
we
are
able
to
get
a
1
million
iOS
or
more
than
a
million
I
have
forgiven
node,
and
we
are
also
able
to
get
a
network
throughput.
D
If
you
see
a
title
in
this
case,
we
are
not
running
victim
is
not
running
any
network
traffic.
It
is
only
running
a
storage
traffic,
so
you'll
be
only
seeing
the
storage
iOS
and
which
is
close
to
a
million.
You
are
able
to
get
it
just
because
of
the
hardware
offload
for
the
storage,
as
we
see
the
all
parts
of
these
containers.
Yes,
here
we
see
a
9
k,
vm
instances
that
we
deployed
using
a
different
performance,
tiers
a3
with
best-effort
3
with
medium
and
3
with
high.
D
Now,
let's
look
at
the
other
instances
that
we
deployed
will
filter
onto
a
specific
node
to
see
a
container
workload.
So
here
are
this:
here
are
the
three
container
workload
for
the
s
io,
which
is
nothing
but
a
storage
benchmarking
application
I
first,
which
is
a
network
I
personal
benchmarking
tool
as
you
can,
it
is
still
coming
up
once
the
application
is
fully
able
to
drive
the
traffic.
We
will
see
a
dial
see
the
numbers
in
such
a
manner.
High
workload
will
be
getting
the
maximum
I/o
salable
on
to
the
node
right
of
next.
D
So
here,
as
we
can
see,
we
are
able
to
see
240,
K,
iOS
and
I'll
go
ahead
and
enable
a
performance
tier
to
show
that
that
was
the
performance
tier
and,
along
with
the
read
and
write
latency,
to
see
how
much
latencies
we
are
able
to
gain
for
a
given
specific
of
performance,
fear
workload.
So,
as
we
can
see
here,
all
the
high
workload
are
around
the
under
500
microseconds
latency
there
around
480
microsecond
latency,
for
a
read
workload
and
as
we
can
see
here,
they
are
in
turn.
D
All
of
them
are
about
to
get
260
ki
off.
We
have
a
best-effort
which
are
running
around
the
16th
I/o
with
a
higher
latency,
because
a
view
will
be
make
giving
the
high
priority
to
the
high
workload.
The
hardware
is
giving
the
high
priority
for
the
high
workload,
which
requires
the
maximum
I/o,
and
the
next
is
a
medium
which
is
getting
a
66
ki
ox
and
with
the
1.9
millisecond
latency.
D
D
B
B
All
right
so,
if
you'd
like
to
learn
more
about
diamonte,
go
to
diamonte,
comm
email
us
at
info
at
the
MRT
comm
or
follow
us
on
twitter
at
be
Amati,
calm
or
we're
also
on
LinkedIn.
So
in
closing,
thank
you
for
your
time.
We
appreciate
it
a
lot
hope
we
were
able
to
share
some
insights
from
the
industry.
B
So
in
closing,
diamonte
is
an
enterprise
kubernetes
platform
with
hardware
offloads
based
on
you
know:
cim
quartz-based
chipsets.
It's
a
full
stack
solution
is
hardware
and
software
prepackaged
with
open
source
kubernetes
with
million
I
ops
for
one
ru
and
sub
one
at
100,
millisecond
latency
check
out
our
website
for
all
the
use
cases.
Solutions
of
course
also
plan
to
attend.
Coop
con,
we'll
see
you
there
and
you
can
expect
more
from
us
coop
con.
So
until
then
have
a
great
day
back
to
you.
Kim.