MARK MIRCHANDANI: There's more to Google Kubernetes Engine
cost optimization than your applications.
There's also your machines.
The underlying virtual machines are a fundamental part
of GKE costs.
And choosing the right VMs to run and fit your apps
is critical for balancing cost and performance.
Today, we'll go over some tips and best practices
for choosing and customizing your machine types.
Let's go beyond your GKE bill.
[MUSIC PLAYING]
Kubernetes does a lot of the work to abstract the underlying
infrastructure.
But it's still there.
And how you choose to set it up can make a big difference
in how your apps run and how much they cost.
In the last video, we went over the differences
between understanding the resources
that your applications actually use
and what they've been allocated.
With that in mind, you can also adapt the resources
to best fit your applications while still
optimizing for costs.
I'll start with a review of the different machine types
available to GKE and how to optimize shape
and size, along with binpacking.
After that, I'll go over preemptible VMs
and finish up with some suggestions
for cost optimization.
Let's start with some general machine types.
The N-series machines were the default
for most general workloads on Google Cloud.
And they were a great combination
of powerful and flexible.
Not too long ago, the E-series or E2
came out as an updated general purpose machine type.
It's a bit less flexible than the N-series,
but it's also a bit cheaper.
One example is that the N-series and E2
series have different sets of processors that are available.
Here's a table of the current differences,
but it's a lot of information.
These differences might be important for your apps,
but they might not be.
E2s have similar performance to N1s,
but they're optimized for cost.
See if they'll work for your apps and save some money.
Of course, it's all about understanding
the details of your app when making a decision.
There's also a few other types like compute optimized
and memory optimized.
These are, well, optimized to help run workloads that
need that extra CPU or memory.
So maybe instead of spreading your deployments
across a bunch of general machines,
you could stack them onto fewer optimized machines.
That's where the shape of your machines come in.
If your apps have specific requirements,
you can make sure that the machines
are shaped to fit your apps.
You're not just limited to the predefined configurations.
In fact, all of this is known as binpacking.
It's all about making sure that you find the most efficient way
to run apps on your machines and to minimize wasted space.
Kubernetes will try to find a node to schedule your pods.
And if it can't find one, it'll add more nodes
according to your node pool configuration.
Let's take a look at an example.
Here we have two machines, the E2-standard-16 with 16 vCPUS
and 64 gigs of memory and a custom E2 with the same vCPUs
but only 16 gigs of memory.
We also have two applications with different sizes,
and app A has two replicas.
So what happens if Kubernetes needs to schedule
two more replicas of app B?
The standard has enough memory but not enough vCPU.
On the custom, there is enough vCPU for one but not
enough memory for any.
That means Kubernetes needs to make more nodes.
And since two replicas of app B couldn't
fit on a new standard, that means
two more nodes and even more wasted space.
To help optimize usage, think about the size of our pods.
They're not all going to be the same size,
but when we have a general sense of each application,
we can optimize nodes around that.
In fact, one strategy is to use the 2
to the power of n rule, which involves shaping pods
into vCPU buckets of one, two, four, eight, 16, and so on.
Now we can have a pretty predictable idea of how
these will fit on the machines.
And we can use larger machines to better binpack.
This E2-standard-32 can hold all of our pods.
And it's much cheaper than the four previous machines.
There's still some wasted memory,
but we could use a custom size to help with that.
Ultimately, you know your apps.
And the more details you have, the better decisions
you can make on machine types.
Plus, you can always try out different test environments
and see what happens.
Of course, this is still a lot to think about when
looking at cost optimization.
The good news is that GKE offers node auto provisioning, which
automatically figures out optimal machine sizes
and then dynamically adds and removes node pools for you.
We'll go over this in much more detail in the next two videos.
All right, that's enough about shapes and sizes.
If you want to read through the full details,
check out the link in the description.
Let's jump to another potential way to save major costs,
preemptible VMs.
Typically when creating a machine,
you can specify if you want to make it preemptible or not.
And you can pass it along as you're creating nodes and node
pools in GKE.
So preemptible means the machines cost a lot less, even
up to 80% less.
But there's a lot to consider when using preemptibles.
First of all, any instance can last a maximum
of 24 hours and sometimes less.
They can go away with really short notice.
So you need to ask yourselves are my apps fault-tolerant?
That is to say, what would happen if a machine goes poof?
On top of that, what happens when multiple machines go poof?
If there's no spare room to reschedule your app,
it might take some time before Kubernetes
can bring up enough machines to run your apps again.
Definitely keep in mind how your apps handle things
like state, potential unavailability, and less
than graceful terminations.
There's a great guide in the description
that goes over how to architect with these things in mind.
So if you want to use preemptibles,
make sure that you can consider how your cluster can
work with your apps.
The cluster autoscaler, which we'll
talk about the next video, will actually prefer preemptibles
because it optimizes for cost.
But you'll probably want a backup node
pool that isn't just using preemptibles for safety.
Just like the type and shape of your machines,
you need to know how the full details of your applications
work in order to optimize around them.
Now let's flip this and talk about
super predictable workloads.
If you're planning on keeping clusters running for years,
you should consider my favorite committed use discounts.
These are basically contracts where you sign up
for a one or three year commitment
on a certain number of resources, like CPU or memory.
You're committed to paying for them regardless
of if you actually end up using them,
but you get a huge discount in return.
I've got a whole other video in the description
that goes into more details about how they work.
For GKE, think about your resource usage
and how spiky it is.
If it goes up and down a lot or it
needs to handle really large spikes
but there's a minimum amount that's
being used no matter what, you could make a committed use
discount to make that baseline much cheaper.
Here's a good example where some usage is covered,
but there's more room to save money.
And you can even consider preemptibles
to handle spiky demand in a cost-efficient way,
as long as your app can tolerate it.
For example, if you're a retail website,
you may need to handle large spikes for sales or holidays.
On other days, you can get an idea of what's
required to serve your website.
So there's a pretty easy baseline
to figure out right there.
Of course, let's not forget about where
these different resources actually exist.
Regions have different prices and they'll
offer different latencies for your users,
based on where they are.
If your application isn't latency-sensitive,
you can pick a cheaper region.
But keep in mind that moving data between separate regions
does have a cost associated with it.
That also affects your clusters.
So a single-zone cluster probably makes more sense
for a dev environment.
And a regional cluster might make more sense
for a production environment.
You can always run different workloads in different regions,
based on the unique requirements of your business.
Inter-pod affinity and anti-affinity
are Kubernetes configurations that you
can use to help control where your pods will be scheduled.
You have the flexibility to really customize
your clusters and machines.
But once again, it comes down to understanding
your applications.
On the next video, we'll dive into auto scaling.
Remember to check out the link in the description
for the full guide on GKE cost optimization.