[MUSIC PLAYING]
ANTHONY BUSHONG: GKE provides built-in functionality
to help you optimize your Kubernetes clusters.
So let's dive right into it.
We'll take a look at these features
through the eyes of two GKE clusters, one standard and one
Autopilot.
Let's start by visiting the Cost Optimization
tab from our Clusters page in the Console.
In this tab, we can see a time series visualization
for our GKE clusters, which will get detailed information
about resources across clusters in a project,
in this case starting with CPU across all standard clusters.
For any given time over a customizable time window,
in this case, one month, we can see the total allocated CPU
across all of our standard clusters,
the amount of CPU actually requested
by pods running in those clusters,
and the amount of CPU actually used by these pods.
We can also see bar charts below to show us
what usage, requests, and allocatable resources
looked like over that defined time window.
Now this information can definitely
help us understand how efficiently we
bin pack our workloads onto nodes in our cluster.
But what it can also do is give us insight
into scaled-down efficiency.
For example, we can use the time filter
to take a look at a specific window in which we
had a scale-up event.
So let's take a look at this one.
Now we can see that while we added nodes
during the scale-up of pod requests,
we could have gotten better cluster
utilization by prioritizing scale-down
after usage had stabilized.
Information like this can help us
make optimization-centric decisions
like implementing the optimized utilization profile for Cluster
Autoscaler, which was not enabled in our cluster
during this time window.
A change like that will not only help Cluster Autoscaler spin
down under-utilized nodes better but it'll also
give preference to scheduling pods on nodes with more usage
to improve cluster bin packing.
We can also get the same visualization
from memory across our standard clusters as well.
In this case we can see that our clusters still have
a bunch of unallocated memory.
With this data, we can think about optimization decisions
like choosing machine types with less memory in our clusters.
The time series visualization also supports GKE Autopilot
clusters.
One of the core differences between GKE Standard mode
and GKE Autopilot mode is the fact
that Google manages your underlying node infrastructure
in Autopilot, thus it handles the amount
of allocated resources for you in the cluster.
So in this model you don't pay for infrastructure
used or idle, but rather you pay for your pod requests.
Thus our optimization efforts focus on whether or not
pods are using the resources that they request.
As you can see across both memory and CPU,
there is opportunity to perform workload rightsizing.
That is adjusting pod requests to reduce resource waste
while still requesting what the pod needs to function.
Not only does this Cost Optimization tab
show us data on resource utilization across clusters
but it also links us directly to its financial implications,
as each cluster I've shown you here
has GKE cost allocation enabled, which is
integrated with Cloud billing.
When we click on View Billing Reports
we're navigated to Cloud billing with information
about the cost of our clusters.
However, in many cases, clusters house many workloads
across multiple teams.
What if we want to understand costs at a more granular level
that can help us identify areas to optimize?
With GKE cost allocation we can filter billing data
down to the cost of pod requests by name space or labels
across our clusters, in this case some filtering based
on name spaces.
This is yet another reason to double check
that you're using name spaces and labels to logically
organize and identify teams and services in your clusters.
Another helpful bit here is that we can also
see the cost of unallocated resources in our cluster.
This Cloud billing data can also be exported to BigQuery.
And it includes all GCP resources, not just GKE.
This means you can do things like write SQL queries
to parse not only what a team's workloads are costing in GKE
but also backing and stateful services those workloads might
consume outside of GKE, like Cloud Memorystore, Cloud
SQL, et cetera.
A sensible next step once we reviewed
some of this information at the macro level
is to get more granular.
So let's navigate to the Cost Optimization tab
in the Workload section of the GKE Console.
For simplicity's sake, let's filter this view down
to our standard cluster.
This tab gives us helpful cost optimization data per workload
in which we can see similar time series and bar graph
visualizations to understand how workload usage relates
to their requests and limits over a defined time window.
So let's review each, one by one.
We'll start with our alpha workload.
Our alpha workload uses about 50% of its requested resources
but only about a quarter of its memory-requested resources.
It's an opportunity to perhaps reduce
requests across both but especially memory.
Our beta workload is also around 50% of its CPU requests.
But this time it's memory usage well exceeds its requests.
This is noted here by our yellow bar graph.
This is an opportunity to not only set requests higher,
but as you can see, we don't have any limit set for memory.
But we should.
Without limits, this workload can consume too much memory
on the node that could create out
of memory problems for other workloads on that node.
Our delta workload is, unfortunately,
representative of a common problem, workloads
without requests or limit set.
This creates the same noisy neighbor
problem of workloads consuming too much of a node's resources.
But it also does not help us at all
when it comes to cluster bin packing.
After all, the cluster can bin pack as good
as our requests are when they are set.
Finally we see the gamma workload
in which we have an opportunity to increase the CPU resource
request amount.
But we also see in its memory usage what the bar graph looks
like when we have limits appropriately set,
as our limit here is defined by the gray.
This data can help us implement cost optimization
as part of a cultural shift in which cluster admins work
with service owners to adjust these requests, not only
to course correct, but also to implement best practices
and standards moving forward around requests and limits.
As teams work together, GKE bubbles up
easily accessible information that can help them
in workload rightsizing.
So let's take a look at our beta workload in which we
can see some of Vertical Pod Autoscaler recommendations
directly in the Console.
VPA's recommendations are based on the workload's
historical and current usage.
We can start by taking a look at the Actions menu,
navigating to Scale, and selecting Edit Resource
requests.
Here, with the green lines denoted by the star icon,
we can see recommended values to set for CPU and memory
requests.
If you remember, our beta workload's memory usage
well exceeds its requests.
So we can see that reflected in the recommendation
to increase our memory requests.
Let's now take a look at the alpha workload.
For workloads with HPA, based on a usage threshold
of CPU like the alpha workload here,
changing CPU requests in isolation
can have unintended effects.
Thus no recommendation is provided.
However we do still get a recommended value
to set for memory requests.
This data can help teams work in tandem to workload right size
in order to yield better cluster optimization at large.
Now this functionality covered up to this point
is great for teams already running GKE clusters.
But what about for those who are looking
to get started with GKE on the right foot,
with cost optimisation top of mind?
If you're creating your first GKE cluster
and want to be set up for success and optimization,
we have a couple of ways in the Console to help.
The first is our setup guide for a cost-optimized GKE
standard cluster, in which we have
a wizard that you can use to create your cluster using
a template in the UI.
This template includes a lot of the things
we talked about today, cluster autoscaling
with the optimized utilization profile, Vertical Pod
Autoscaling, GKE cost allocation.
But, of course, the wizard also allows
you to make certain changes you need for your cluster.
if you prefer to use the Console and configure your cluster
bit by bit, we'll also provide estimations
into what your cluster might cost as you build it out.
If you plan on auto scaling your cluster,
we provide a slider that will give you
an idea of the range of the cost of your cluster
as it changes due to demand.
As we conclude, I'd like to reiterate that optimization
is a team effort between cluster admins, workload
owners, and even billing managers,
an effort that must continuously happen as new workloads onboard
and existing workloads change.
As we saw on this tour, GKE provides
many pieces of built-in features to help you in your journey
to optimize your GKE clusters.
To learn more, check out the links in the description below.
My name is Anthony Bushong and thank you for your time.
[MUSIC PLAYING]