►
From YouTube: Cost-effective Compute Clusters with Spot and Pre-emptible Instances - Bich Le & Arun Sriraman
Description
Cost-effective Compute Clusters with Spot and Pre-emptible Instances [I] - Bich Le & Arun Sriraman, Platform9
Kubernetes and Spot/Pre-emptible Instances (SPIs) are arguably a match made in heaven. Traditionally, the uncertainty of SPIs (they can be terminated at any time due to price fluctuations) have made managing them tricky, and restricted them to specific workloads and use cases.
Kubernetes, in contrast, not only handles node failure very well, it has trained developers and architects to design applications to tolerate and even embrace failure. The prospect of Kubernetes abstracting the complexities of SPIs is now a reality, enabling applications to take advantage of low-cost compute across different clouds and possibly vendors.
The purpose of this talk is to educate the audience on strategies for making the most out of this powerful combination. Specifically, we will discuss these topics:
1. What are spot bidding strategies, and what is their cost vs. predictability trade-off?
2. What class of Kubernetes applications would benefit the most from SPIs?
3. Available Kubernetes mechanisms (e.g taints/tolerations, affinity, availability zones) for placing applications based on their tolerance with SPIs
3. Implementation strategies (e.g. blending multiple autoscaling groups to satisfy both SPI-optimized applications vs. applications that are more mission-critical or stateful)
4. What out-of-the box solutions exist, either free or commercial?
5. How to take abstract away clouds from different regions and vendors, allowing workloads to always take advantage of the best available pricing?
The talk concludes with real-world test results involving multiple use cases and configurations, giving the audience an idea of the potential cost savings and trade-offs (if any) of combining Kubernetes and SPIs.
About Bich Le
Chief Architect, Platform9
Co-founder of Platform9 and veteran of VMware. Career in virtualization, cloud management and containerization.
About Arun Sriraman
At Platform9 Systems I work on everything networking with deeper focus on Kubernetes and Openstack. Architecting, designing and writing code to solve interesting problems gets me on and recently I've been dabbling with the internals of container technology. Before Platform9, I've worked with Cisco Systems, Aruba Networks and Siemens. I hold a Masters in Computer Networking degree from North Carolina State University.My interests are in the field of Computer Networks, Virtualization, Cloud computing, Operating systems, System architecture and of late Machine learning.
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
Thanks
for
coming
to
this
talk
just
before
we
start
I'd
like
a
show
of
hands
how
many
of
you
have
plans
or
are
already
running
kubernetes
on
public
clouds?
Oh
great,
okay,
how
many
of
you
would
like
to
save
on
op,
X
costs?
Okay,
so
I
think
you've
come
to
the
right
talk,
so
my
name
is
piccoli
and
here's
Arun
with
me
were
from
platform
9,
and
today
we
want
to
discuss
ways
to
run
kubernetes
clusters
on
public
clouds
more
cheaply.
Ok,.
B
A
To
motivate
our
talk,
let
me
just
give
you
a
quick
introduction
to
what
we
do
at
platform.
9.
We
are
in
the
business
of
running
open
source
software
as
a
service
for
our
enterprise
customers,
and
we
specialize
in
infrastructure
management,
and
this
means
we
offer
kubernetes
OpenStack
and
fish'n
as
an
integrated
product.
A
So
in
our
journey,
what
we've
learned
and
what
we've
been
exploring
is
you
know
what
we've
discovered
is
one
of
the
best
ways
to
reduce
costs
is
to
take
advantage
of
spa
instances
on
AWS
or
preemptable
instances
on
Google
Cloud
right.
There
kind
of
equivalent
and
are
most
of
you
familiar
with
the
concept
of
spot
instances.
We
can
do
a
quick
review,
so
spot
instances
are
essentially
the
same
virtual
machine
instances
that
you
can
get
regularly.
A
They
have
the
same
types
except
that
they
are
considerably
cheaper
from
a
per
hour
cost
right,
and
our
observations
have
shown
that
on
average
they
can
be
60
to
80
percent
lower
cost
than
the
regular,
on-demand
instances
right.
So
the
potential
savings
are
huge.
However,
they
come
with
a
drawback.
You
know
that
there's
a
catch
to
them,
and
so
the
issue
is
bought.
Instances
or
preemptable
can
be
terminated
at
any
time
for
reasons
that
are
beyond
your
control
right.
A
So,
for
example,
on
AWS,
if
the
real
time
price
exceeds
your
bid
price,
then
you
can
lose
the
instance
on
Google
cloud.
They
can
get
terminated
for
a
variety
of
reasons,
but
even
if
nothing
happens
after
24
hours,
you're
guaranteed
to
lose
the
instance,
but
by
policy.
So
what
this
means
is
to
really
take
advantage
of
spot
instances.
A
Historically,
if
you're
an
application
developer,
you
really
need
to
understand
the
trade-off
between
availability
and
price
and
kind
of
match.
Your
application
to
this
trade-off,
and
what
this
means
is.
Typically,
people
have
been
running
specialized,
workloads
on
spot
and
have
required
special,
tooling
or
scripting
to
handle
a
node
failure
right.
A
So
the
good
news
is
fast
forward
to.
Today
we
have
kubernetes
and
we
think
that
kubernetes
is
going
to
make
spa
instances
mainstream
right,
and
why
is
that?
Kubernetes
can
really
hide
the
complexity
and
the
details
of
spot
instances,
because
it
is
really
built
to
handle
note
failure
right
under
the
scenes.
It
will,
for
example,
leverage
public
cloud
resources
like
auto-scaling
groups
that
will
automatically
spin
up
a
new
instance
if
one
dies
and
at
the
pod
level,
if
you
use
the
correct
constructs
like
deployment
or
replica
set.
A
If
your
pod
resides
on
one
of
those
nodes
and
disappears,
kubernetes
will
reschedule
another
pod
somewhere
else
for
you
and
crouppen.
Ats
has
really
taught
us
to
design
applications
for
failure
right
to
be
resilient,
with
constructs
like
replica
sets
and
services
which
can
distribute
requests
across
a
pool
of
pods,
so
that
if
you
lose
a
bunch
of
pods
once
in
a
while
no
big
deal,
your
application
continues
to
run
right.
A
So
we
think
that
crouppen,
Eddie's
and
spa
instances
are
really
a
marriage
made
in
heaven,
but
the
Devils
in
the
details
right
and
today,
arune
is
going
to
walk
us
through
all
the
details
about
how
to
understand
spa
instances
and
how
to
best,
take
advantage
of
them
within
the
context
of
kubernetes.
Thanks
Rick.
C
So,
let's
dig
deeper
and
jump
in
to
see
how
to
save
money
on
your
bills.
I
wanted
to
look
at
this
blog,
that
Jeff
Barr
from
AWS
wrote
in
2015,
and
he
spoke
about
how
you
choose
instances
or
how
you
group
them
into
pools.
So
he
spoke
about
a
concept
of
capacity
pool.
So
this
capacity
pool
is
a
logical
encapsulation
of
instances
that
are
both
standard
or
on-demand
instances
and
preemptable
instances
or
spot
instances,
and
these
instances
are
pretty
much
of
the
same
type
so
t2
medium.
C
They
are
on
the
same
availability
zone
and
they
belong
to
the
same
region
and
these
capacity
are
attributed
to
be
able
to
create
a
instance
or
launch
an
instance
at
any
given
time
for
a
given
price.
So
what
we
need
to
take
into
account
when
we
choose
such
capacity
pools
for
our
cluster
are
some
of
these
best
practices.
So
one
is
when
we
build
our
applications,
we
can
make
them
price
aware.
So
if
our
applications
are
built
in
a
way
that
they
don't,
they
are
not
attached
to
a
particular
instance
type.
C
We
can
choose
a
specific
instance
which
is
of
lower
cost
for
running
that
application.
The
other
important
thing
is
about
checking
the
history
of
the
instances,
so
this
can
be
either
manual
or
it
can
be
automated.
So
it's
always
nice
to
go
back
to
history
figure
out
what
the
costs
are
and
then
think
about
which
a
type
or
which
capacity
pool
would
be
best
to
use.
C
One
main
important
thing
is:
we
need
to
make
sure
that
when
we
deploy
a
cluster
and
choose
capacity
pools,
we
we
choose
multiple
of
them.
We
compose
them
of
both
preemptable
instances
and
spot
instances
so
that
our
application
always
runs
and
our
service
never
goes
down.
Let's
quickly
take
a
look
at
what
big
mentioned
with
respect
to
spot
instances
in
Amazon.
If
you
look
at
the
graph
there,
it's
an
m1
medium
over
three
months.
C
C
It's
it
doesn't
run
on
the
surplus
capacity
market.
They
give
you
a
flat-out
discount
on
the
price.
The
only
catch
is
that
the
instance
is
ease
always
terminated
somewhere
around
twenty
four
hours
or
within
24
hours.
The
good
thing
is:
if
it
gets
terminated
within
ten
minutes,
I
think
Google
does
not
charge
you.
So
that's
the
other
thing.
Let's
look
at
what
type
of
applications
would
be
best
suited
for
such
infrastructure?
C
Another
use
case
is
the
HPC
industry,
where
the
most
amount
of
work
you
do
is
number
crunching,
and,
and
if
these
processor
or
your
applications
are
more
or
less
stateless,
you
can
always
run
them
on
preemptable
instances
of
spart
instances
and
it's
not
too
much
of
a
pain
if
an
instance
goes
down
to
restart
from
where
it
was
where
the
part
left.
Another
use
case
is
highly
available,
clustered
apps.
C
So
there
are
still
people
writing
applications
in
a
way
that
there
is
one
which
runs
active
and
there's
another
copy
of
the
app
running
standby
waiting
for
waiting
to
take
over
in
case
of
the
active
app
going
down.
So,
in
those
cases
again,
the
standby
app
would
just
be
syncing,
and
if
it's
not
participating
in
an
active
active
configuration
it,
it
can
be
offloaded
to
a
spot
instance
and
pretty
much
take
lesser
of
our
money
than
otherwise
another.
Is
the
node
auto
scaling,
so
the
first
one
is
with
elastic
bursting?
C
Is
you
increase
or
dynamically
expand
your
app
and
with
expanding
app?
You
will
probably
need
to
expand
your
infrastructure
as
well
and
horizontal
power
order,
scaling
and
horizontal,
nor
order,
scaling
and
kubernetes.
Pretty
much
gives
you
a
very
good
mix
to
solve
this
use
case
and
it's
great
to
work
on
support
instances.
C
Having
said
that,
let's
look
at
what
we
can
do
to
deploy
clusters
with
either
sparked
instances
or
preemptable
instances
on
gke,
we'll
look
at
GK
and
we'll
also
look
at
AWS
with
respect
to
K
ops.
So
in
gke
the
instance
groups
are
are
also
called
node
pools.
So,
given
a
node
pool,
you
can
specify
a
type
of
instance
whether
that
node
pool
is
going
to
be
preemptable
or
not
so
a
catch
is
that
within
a
node
pool,
you
cannot
have
a
preemptable
instance
and
fixed
instance.
It's
either
other
rather
so.
C
The
best
way
to
build
your
app
is
to
have
two
node
pools,
one
fixed
and
one
preemptable
to
start
off
with.
You
can
always
have
a
fixed,
node
pool
and
then,
as
in
when
capacity
grows,
you
can
add
node
pools
dynamically
to
the
cluster.
You
can
also
have
note
pools
with
zero
nodes
in
it,
so
that
auto
scaling
will
kick
in
when
your
application
is
needing
the
capacity.
C
This
was
one
of
the
examples
of
an
app
that
I
had
on
uke,
where
the
the
way
I
deployed
the
cluster
is
created.
Two
pools,
one
is
the
fixed
pool
with
preemptable
in
nodes,
disabled
and
the
other
one
is
enabling
preemptable
nodes,
and
if
you
go
with
k,
ops,
k,
ops
has
various
backends.
You
can
deploy
clusters
across
multiple
cloud
providers
with
k.
Ops
I
choose
this.
Since
it's
an
open
source
tool,
let's
see
how
you
deploy
and
a
cluster
using
K
ops
and
using
sparked
instances.
So
how
chaos
does
it
is
4k
ops.
C
The
instance
group
is
the
binding
and
instance
group.
Pretty
much
consists
of
instances
of
the
same
type,
so
an
instance
group
can
either
be
spot
or
preemptable
or
the
fixed
pool,
and
when
you
create
a
cluster
with
K
ops,
it
creates
multiple
instance
groups,
one
for
the
master,
node
master
components
and
one
for
the
nodes
or
the
workers,
and
these
are
more
more
or
less
backed
by
auto-scaling
groups.
So
if
a
node
gets
terminated
within
that
node
node
pool
or
an
instance
group,
it
gets
recreated.
C
How
many
of
you
used
K,
ops,
here,
Johanns,
okay,
so
and
have
you
used
chaos
with
sparked
instances
by
any
chance?
Okay,
perfect,
so
we
will
see
how
to
do
that
in
a
bit.
This
is
how
it
looks
when
you
deploy
a
cluster
with
K,
ops
and
AWS.
You,
you
get
a
auto
scaling
group
for
a
master
and
you
get
an
auto
scaling
group
for
the
worker.
C
In
our
example,
we'll
create
another
instance
pool
or
an
instance
group
that
are
is
a
worker
type
node
and
it
has
spot
instances,
k,
op
ml
file
defines
the
role
and
it's
defined
by
either
a
master
or
a
node,
and
the
only
difference
between
an
instance
group
which
is
supporting
spot
instances
and
an
instance
group
that
does
not
support
spart
instance
is
a
fixed
instance
pool.
Is
the
max
price
what
you
can
see
there?
C
So
as
soon
as
you
add
this
max
price
key,
the
instance
pool
that
is
defined
by
the
samel
becomes
a
spot
instance
pool
with
K
ops.
You
can
add
new
instance
groups.
You
can
also
edit
instance
group,
so
one
difference
between
google
gke
and
k.
Aws
is
DKE.
If
you
create
a
node
pool
with
preemptable
nodes,
you
cannot
change
it.
You
need
to
create
a
new
node
pool
with
k,
ops
with
AWS.
You
can
switch
a
instance
group
from
preemptable
to
fixed
or
fixed
to
preemptable
and
so
on.
C
So
what
you
pretty
much
do
is:
first,
you
run
AWS
configure
onto
the
node
and
specify
the
access
key
secret,
key,
the
region
name
and
the
format
that
you
want.
All
your
commands
to
output
in
once.
That's
done.
Let's,
you
can
run
kayoppe
commands,
so
we
just
run
@k
ops,
get
cluster,
I
have
already
a
cluster
deployed
because
caustic
Department
takes
time.
We
look
at
that
in
a
bit.
How
do
you
create
a
cluster?
You
run
the
k,
ops,
create
cluster
command,
give
it
a
zone
and
a
name.
It
goes
through
a
bunch
of
tasks.
C
It
assigns
a
CIDR
for
that
cluster
and
then
it
creates
a
cluster.
A
cluster
object
with
all
of
the
resources
locally.
So
you
can,
it's
still
not
created
on
AWS.
You
can
go
ahead
and
look
at
it
and
manage
and
modify
configuration.
So,
let's
quickly
take
a
look
at
the
instance
groups
that
the
cluster
create
went
through.
So
there
is
a
master
instance
group
and
an
organizational
group.
Let's
quickly
change
the
node
instance
group
to
just
have
one
node
in
it,
because
we
will
create
a
another
pool
for
the
sparked
instances.
C
That's
done.
Let's
now
create
a
new
instance
group
using
the
create
ID
command
and
the
only
difference
or
to
do
this
is
to
specify
a
max
price.
Let's
say
something
like
0.08:
that's
pretty
high
up
there
for
the
T
to
medium
instance,
and
that's
done
so.
Let's
now
take
a
look
at
the
instance
groups
that
we've
created,
so
there
is
a
spot
pool
that
we
created
there's
a
nodes
that
it
created
and
a
master
group.
We
update
the
cluster
with
this
change
of
configuration.
C
C
Console
so
this
is
the
cluster
that
ID
earlier,
as
it
didn't
take
a
bit,
and
you
should
see
new
ones
coming
up
here.
But
if
you
look
at
the
spot
pool
for
the
launch
configuration
that
that
is
responsible
to
bring
up
instances
in
AWS,
it
has
a
spot
price
set
and
the
others
don't
so
that's
that's
the
main
difference
of
creating
instances
or
groups
in
AWS
which
supports
part
pricing,
I,
think
it
should
have
created
the
other
ones.
There.
B
C
It
created
another
one,
the
point
eight
that
we
just
ran.
So
it
takes
about
five
to
six
minutes
to
eight
minutes
and
the
cluster
is
up.
Then
you
should
be
able
to
deploy
apps
on
it
will
not
wait
for
it
we'll
go
with
another
demo,
so
this
is
on
GK.
We
saw
AWS.
Let's
take
a
look
at
GK.
This
take
this
demo.
Pretty
much
shows
you
how
I
have
multiple
pools,
a
fixed
pool
and
a
preemptable
pool
and
I
deploy
app
and
I
create
load
on
it.
So
it
runs
a
horizontal
power
order.
Scaler.
C
It
creates
instant,
more
instances
or
more
nodes
for
to
support
it,
but
those
nodes
are
created
in
the
preemptable
pool
and
not
the
fixed
pool
and
then,
as
soon
as
the
load
goes
down,
it
again
shrinks.
So
there's
a
cluster
that
I
have
an
GK.
Initially
I
had
three
nodes:
a
fixed
pool
with
just
one
ordinate
and
preemptable
pretty
much
disabled
I
have
another
pool
with
300
enabled
and
it
can
be
auto
scaled
up
to
three
nodes
and
I
have
another
one
that
is
just
there.
C
That
that's
going
to
serve
our
traffic
for
us
and
we'll
also
create
a
busy
box
or
a
normal
instance
where
we
can
start
generating
traffic
for
it
before
that
I'm
going
to
create
an
auto
scaler
group
and
I
say
that
if
the
load
goes
above
75%
the
horizontal
power,
auto
scaling
should
trigger
and
it
can
trigger
to
a
maximum
replicas
of
eight.
So
that
load
is
now
running.
C
If
you
look
the
bottom
right,
you
can
see
that
the
load
now
is
running
and
the
number
of
parts
that
are
running
for
this
is
just
one
but
the
load
increase
to
223.
So
the
horizontal
power
order,
scaler
created
multiple
instances,
but
you
can
see
that
one
of
the
part
is
now
in
pending
State,
so
that
part
is
in
pending
state,
because
it's
it
has
already
ran
out
of
resources.
C
The
cube
cut
will
describe
pod
logs
is
going
to
show
us
that
it
it
didn't
happen
because
of
insufficient
CPU.
The
DKE
will
now
automatically
trigger
a
node
order,
scalar,
and
it
creates
a
new
node
that
from
the
preemptable
pool
and
it's
it's
getting
authorization
ares
cluster.
So
we
had
one
earlier
and
it
is
two
now
as
soon
as
it
gets
ready
you
can.
You
will
see
that
the
parts
now
start
creating
again
and
the
Lord
should
slowly
reduce
on
our
app.
C
The
load
is
still
there,
so
it's
going
to
try
more,
creating
create
more
instances
till
it
reaches
eight
replicas,
and
since
we
had
an
order
scalar
on
the
node
pool
set
to
maximum
of
three
nodes.
Now
we
have
three
preemptable
nodes
there
and
everything
is
running
the.
If
you
look
at
it.
The
target
now
is
about
63
percent
or
the
the
load
on
the
app
is
63
percent.
So
it's
fine.
Let's
quit
the
load
I
just
quit
the
load
there
and
killed
my
load
generator.
C
You
can
see
that
the
deployment
the
autoscaler
deployment
target
will
now
fall
to
zero
quickly
and
as
soon
as
it
falls
to
zero,
you
can
see
that
all
of
the
app
apps
pods
are
being
terminated
and
once
the
app
pods
are
gone,
the
nodes
from
the
node
pool.
Also
we
will
get
cleaned
up
by
gke,
so
you
can
see
that
one
went
away
to
and
away
and
now
we
are
again
back
to
three
nodes
in
our
task
in
our
original
faster.
C
C
Now
we
saw
how
you
design
a
cluster
to
use
part
instances
or
orders
killing.
Now
we
look
at
how
you
design
an
application
to
use
part
instances
of
preemptable
instance,
because
you
don't
want
the
application
to
die
completely
and
not
have
your
service
pretty
much
going
down
right.
So
some
of
the
application
considerations
that
are
required
are
easier
application,
stateless
or
is
your
application
stateful?
If
your
application
is
stateless,
it
is
better.
C
It
is
a
very
good
match
for
such
a
use
case.
What
about
the
application,
replica
or
distribution
of
your
application?
So
if
you
have
six
parts
that
is
print
backing,
your
application
and
all
those
six
parts
running
on
the
same
preemptable
pool
may
not
be
a
good
idea.
Definitely
not
a
good
idea
because
it
goes
down
what
happens
when
a
node
fails
communities
automatically
reschedule
those
parts
to
different
nodes
or
instances
and
if
kubernetes
reschedules
them
to
the
preemptable
pool.
C
Again
again,
you
have
a
problem
that
all
of
the
nodes
might
end
up
in
the
preemptable
pool,
which
is
also
a
problem.
So
there
are
also
cases
where
applications
require
specific
GPU
processing,
for
example,
machine
learning
or
big
data
analysis.
So
there
again
preemptable
pools
might
might
be
present
in
your
cluster,
but
you
might
not
want
your
apps
to
go
and
sit
in
the
preemptable
pool.
So
to
do
this,
kubernetes
kind
of
has
a
bunch
of
mechanisms
I'm
sure
most
of
you
would
have
used
it.
If
not
I
think
you
should
use
it.
C
One
of
it
is
the
node
selector.
So
nodes
come
with
labels
or
you
can
apply
labels
to
nodes,
and
you
could
use
that
as
a
node
selected
when
you
deploy
our
application
to
say
if
your
parts
go
to
that
particular
node
or
not.
Now,
let's
say,
for
example,
you
need
to
deploy
an
application
on
this
cluster
with
preemptable
instances
and
fixed
instances.
So
one
way
of
deploying
this
or
one
example
is
I
have
to
deployment
specs
of
my
same
app.
C
Just
an
engine
X
server
I
deploy
one
on
the
preemptive
Poole
by
specifying
the
DKE
preemptable,
true
and
I
deploy
the
other.
The
other
part
of
my
apps
are
it's
the
same
app
but
another
deployment
on
to
the
fixed
pool
using
the
node
selector,
using
the
name
of
the
node
pool
so
gke.
When
you
create
node
pools
it
adlai,
it
adds
labels
to
those
node
pools
and
for
instances
that
are
preemptable.
They
come
with
a
label
inbuilt
and
that's
the
GK
preemptable
equal
to
true
label.
C
So
what
are
the
supporting
mechanisms
here?
So,
let's
look
at
another
example
right,
the
H,
a
app
that
we
were
talking
about.
So
let's
say
we
have
to
know
note
pulls
we
have
a
bunch
of
apps
running
on
them.
We
want
to
deploy
this
H
a
app
and
we
have
one
copy
or
one
deployment
already
deployed
to
the
fixed
pool,
and
now
we
want
to
deploy
the
deploy,
the
the
other
one
passive,
one
strand
by
one
to
the
preemptable
node
pool.
C
So
the
way
you
can
do,
that
is
by
using
a
a
node
affinity
and
the
type
of
node
affinity
that
you
would
use
is
something
called
the
required
during
scheduling,
ignored
during
exception.
Basically,
what
it
says
is
deploy
this
app
only
to
the
preemptable
node
pool
and
not
the
fixed
node
pool
and
YC
versa.
So
if
there's
another
app
that
I
would
like
to
run
on
my
preemptable
node
pool,
but
I'm
okay,
if
my
preemptable
node
pool,
is
full
I
would
use
the
preferred
during
scheduling,
ignoring
during
exception
type
for
the
node
affinity.
C
So
what
I
do
is
I
have
my
application
like
the
way
you
saw
it.
I
have
to
deployment
specs
the
fixed
deployment
spec
and
the
preemptable
deployment
flex.
It's
just
going
to
deploy
the
nginx
server
and
the
main
difference
that
each
of
this
pack
have
is
that
one
is
node
selector
to
the
fixed
pool
and
the
preemptable
one
is
not
selected
to
the
printable
pool.
I
just
have
an
init
container
there,
which
adds
this
echo
statement
to
the
index.html,
which
tells
us
which
part
is
going
to
be
replying.
C
That's
for
us
to
figure
out
in
the
demo.
There
is
a
service,
that's
going
to
Frank
both
of
this,
so
that
is
one
service,
but
two
deployments.
There
are
two
nginx
deployments,
one
on
preemptable
one
on
fixed,
but
that
is
just
one
service
that
friends
all
of
this.
So
that's
how
you
can
make
use
of
the
service,
but
not
worry
about
where
it's
running
I
also
have
a
small
busy
box
that
generates
load
from
where
I
can
generate
load
or
curl.
So,
let's
quickly
run
into
deploy
this
so.
C
C
B
C
C
C
So
you
can
see
that
the
it
takes
a
bunch
of
time
for
the
service
to
reconfigure
for
parts
going
down,
but
then
you
have
the
part
on
the
fixed
instance
running
and
responding
and
I
think
live
demo,
but
yeah.
So
as
soon
as
the
Prima
table
instances
come
back
up,
we
will
start
getting
responses
from
the
preemptable
pool
as
well.
I
think
I
might
have
deployed
the
curler
on
the
preemptable
pool
as
well.
That
might
be
the
reason.
I
might
have
lost
this.
That's
fine!
So
that's
that's
the
demo.
C
Basically,
you
use
note
selector
and
affinity.
Note
affinity
to
deploy
apps
in
the
right
place,
we'll
quickly
go
back.
I
had
a
interesting
experiment
that
we
ran
just
had
a
two
node
cluster
one.
Basically,
a
split
50-50
percent,
one
on
preemptive
and
one
on
fixed,
ran
on
gke
for
12
days,
no
act
overloads
and
one
in
observation
that
we
saw
was
the
preemptable.
Node
goes
away
somewhere
around
24
hours
in
the
median
time,
almost
sometimes
it's
a
little
more
than
24
hours.
C
Otherwise,
it's
normally
around
24
hours
and
the
most
important
thing
was
the
reason
why
you're
here
is
the
costs.
So
if
you
look
at
the
total
cost
or
the
bill
that
I
got
for
the
12
days,
for
the
two
instances
is
$16
and
if
you
replace
this
preemptable
custom
in
instance
score
with
a
standard
instance,
the
total
would
be
around
$24,
so
cost
saving
is
about
$8
for
12
days,
just
for
two
nodes
and
no
workloads.
So
if
you
just
do
a
mental
experiment
and
scale
it
up,
the
cost.
C
Saving
somewhat
looks
like
around
$13,000
for
a
year
for
50
nodes
on
fixed
and
15
nodes
on
preemptable,
so
that
that's
the
interesting
figure
that
we
are
seeing
and
it
will
definitely
increase
as
you
increase
the
number
of
nodes
or
reduce
your
fixed,
fixed
node
prices.
That's
about
it
that
I
had
so,
hopefully
one
key
takeaway.
That
I
think
you
should
you
could
take
away
from
this
is
using
spot
instances
is
beneficial.
C
It
would
reduce
your
costs,
but
there
are
two
things
that
you
need
to
take
care
of,
one
is
to
architect
the
cluster,
and
the
second
is
to
architect
your
app
and
doing
this.
Both
of
this,
a
good
in
a
good
way,
can
get
you
quite
a
bit
of
savings
in
terms
of
bill
and
communities
is
the
best
for
this
approach,
and
that
was
it
for.
B
D
It's
a
great
presentation.
Thank
you.
Definitely
in
introduction
into
it.
I
agree
with
you,
I
think
kubernetes.
It
really
gives
us
a
chance
to
take
care
of
these
spot
and
interrupt
abou
instances.
It
gets
really
complicated
on
AWS
and
things
keep
changing
so
like
they
just
recently
changed
their
pricing
structure.
They
even
went
from
our
two
per
second
and
every
time
we
have
a
strategy
put
together.
It
seems
like
it
changes
dynamically
right.
D
So
that's
actually
what
motivated
me
to
try
to
encapsulate
this
into
a
service
so
that
people
that
don't
have
a
team
of
12
people
to
go
off
and
do
that
can
still
leverage
and
get
benefits
from
these.
But
the
key
points
is
to
make
sure
your
application
can
survive,
and
one
other
point
I
think
you
missed
is
that
even
though
pods
recover,
you
still
don't
want
them
going
down
a
lot
so
at
least
for
the
spot
instances,
you
can
actually
detect
that
and
tell
them
to
start
draining
and
try
to
move
things
off
there.