>> Hello and welcome to
another video on the Azure Cloud Native Series.
In this session, we'll be covering how you can save costs on
low-priority workloads with AKS and Azure Spot.
The first thing you need to understand is
the notion of node pools in AKS.
A node pool is a set of agent nodes with common characteristics,
typically the VM size and operating system which
under the hood in Azure maps to a virtual machines scale set.
Beauty of node pools is that they enable you
to add different forms of compute to a single cluster,
each of which can be managed and scaled
independently, including with autoscale.
One of the common best practices for running AKS
at scale is to maintain a set of
nodes specifically for the system services
like CoreDNS and Metrics Server.
AKS is now elevated that idea to a first-class concept,
the notion of node pool modes.
The first node pool created in the cluster is labeled as
the system node pool by default
and it is intended for system services,
while later ones are tagged as user node pools
by default and are intended for your applications.
A nice benefit of this model is
that user node pools can be scaled down to
zero nodes and be based on ephemeral compute like Azure Spot.
With that, let's take a look at Azure Spot.
As a hyper-scale Cloud provider,
Azure has computing capacity in over 50 regions around the world.
Within each of those regions,
we offer a number of different types of compute from
general-purpose instances to memory or storage
optimized VMs to GPU-based machines.
At any given time, some portion of that capacity is going unused.
With Azure Spot, you can consume
that unused capacity at a significant discount up to
90 percent as long as you're willing to deal with
lower reliability and no SLA as a result.
This trade-off makes Azure Spot
best-suited to workloads which are not
time-critical and which are
resilient to a short period of interruption.
The price of Azure Spot for a given VM series changes
periodically based on the demand for
that type of compute within the region.
As such, you have the opportunity to set
a maximum price you are willing to pay for that compute.
You can either set a discrete price,
in which case your VM will be evicted if the price rises above
that point or you can set the price to negative one,
which means that you're willing to go all the way up
to the VM pay as you go price,
in which case you will only be evicted if there
is no spot capacity remaining in the region.
Now, let's take a look at how you can consume
Azure Spot in the context of AKS.
I have the suitably named Spark cluster here running in AKS.
I'm just going to go ahead and list out its node pools.
You can see that at the moment it's just one node pool in
the cluster and it's the one that was
implicitly created when the cluster itself
was created and you can see that it's been
tagged as a system node pool.
Now what I want to do is add a new node pool to
the cluster a user node pool that will be based on Azure Spot.
The CLI now has this priority switch
that I can set and there's two options for it,
either regular, which is the default,
or spot, suppose at that spot
and then I have the option to set a max price,
which is what we just discussed.
Now you might be wondering,
how do I get a sense for what price I should set here?
What the current value of this VM type in
this region is and that information is
available from the Azure pricing page.
If I look here at Linux virtual machines in West US 2,
I can see that the D2sv3 series,
which is the default for
AKS if you don't specify the VM size, that's what you'll get.
The pay as you go price is currently listed at roughly
$0.095 an hour but if you look over here at the spot price,
it's currently at about $0.015 an hour,
so pretty dramatic savings available.
Now again, that price does change
periodically based on the demand for
that particular VM family within the region.
You have the ability to set a price that's higher
than that current price if you want to have some amount of
offer for being able to still get
capacity before your VMs get evicted.
In this case, I'm going to go ahead and set
the max price a little bit higher,
say to $0.025 as still dramatic savings on the page,
you go price, but giving me a little bit
of buffer should that price increase.
Now, another common best practice when using
spot node pools is to leverage the cluster autoscaler.
The reason for that is,
if the nodes happen to get evicted as a result of price changes,
the cluster autoscaler can kick in
and attempt to reprovision a new node,
potentially at a slightly higher price.
I'm going to enable the cluster autoscaler here,
and I will set the min and max count for that.
That's going to go ahead and provision on
an additional node pool into my cluster,
that'll take a few minutes.
That provisioning has now completed,
which means that if I re-run this list command,
I should see my two node pools.
Indeed there is the second one
which has been marked as a user node pool.
If I list out of my nodes,
you'll see that there are three that are part of
the system nodes pool as well
as three new ones from the spot node pool.
By default, Kubernetes would consider all of
these nodes as candidates for scheduling workload.
We mark the nodes in a couple of ways to make sure that
only the types of workloads that should land on spot actually do.
You can see those two markings by describing the node.
The first is a label for scale set priority,
which in this case is set to spot.
This allows you to specifically target
spot node pool for a workload that is suited to it.
Second is a taint,
which is designed to keep pods off a node unless they have a
specifically indicated that they are
okay with the implications in this case,
the potential for eviction.
Now let's look at how we can schedule
a workload onto spot instances.
For this demo, we'll use a deployment of folding@home,
a distributed computing project designed to harness
unused computing power from thousands of machines
worldwide to run simulations of
protein dynamics in service of finding cures for diseases.
A community is built out Kubernetes deployment for folding@home,
specifically targeted at COVID-19.
That's what we'll deploy.
Now just as there are two markings on the spot node,
there are two changes that I'll make to the pod spec.
The first is to tolerate the taint that we saw earlier,
meaning that the pod could run on the spot not the spot instance.
In this case, I will also add
a node selector that will match the spot label,
which ensures that the pods will only run on spot instances.
Now go ahead and deploy that and if I query the pods
now I'll see that
indeed my pods are running on those spot instances that I created.
That was a quick look at how you can leverage
Azure free spot node pools to run
low-priority workloads at significant discounts.
To learn more, check out aka.ms/aks/spot.