SPEAKER: In GKE, application owners
can define the minimum and maximum amount
of CPU and memory that their workloads require.
This is done in the form of per container requests and limits
in a Kubernetes pod.
This process isn't perfect though.
Workload requirements may need to change over
time for many reasons, from incoming demand
on the applications to improper initial configuration.
App right-sizing is a practice of fine tuning workload
requests over time to ensure that their requests accurately
reflect what the workloads will utilize.
In order to make GKE cost optimization a discipline,
it's important to provide a monitoring
system that can help teams practice app right-sizing.
[MUSIC PLAYING]
Previously, we discussed how it is
important to monitor cluster bin packing,
or how efficiently resources are distributed at a cluster
and node pool level.
Signals of poor utilization at these aggregated levels
can be indicative of applications being
over or under provisioned.
Monitoring at the application level
can empower application owners to have
the right data to right-size their apps
and put GKE cost optimization into practice.
To monitor this effectively, we want
to ensure that clusters utilize name
spaces in a logical fashion.
For many reasons, we do not want to have a single namespace
running all pods.
These include overly permissive role-based access control,
inability ability to set quotas for team, the list goes on.
But from a monitoring perspective,
we want to be able to utilize namespaces
to understand app right-sizing patterns across groups
of applications.
A common example of how this could be useful
would be for namespaces to be aligned to each team.
This easily allows us to then chart and monitor
how each team is doing.
For example, when a team is consistently
overprovisioned on a specific resource across multiple apps,
we can make that information available to them.
This builds a culture around empowering teams
to right-size their apps.
The way we can detect how well they're doing,
is by utilizing platform-specific
recommendations.
For example, the vertical pod autoscaler.
This means that we'll get recommended values
for CPU and memory requests, which
we can chart against the actual resources
that pods are requesting in that given namespace.
Once we have a team to work with on right-sizing apps,
we can then dig into monitoring for their overprovisioned apps.
The data we've already collected for the aggregate namespace
view will be utilized here as well, this time on a per work
load basis.
Here, we can see that the front end and back end
workloads for team A are well over provisioned.
So what can we do now?
We can start with auto generated recommendations
from vertical pod autoscaler.
This may give us quick, easy guidance
to right-size overprovisioned apps by reducing CPU and memory
requests.
We should also create per application dashboards
where we graph out data, including
what resources the pods are utilizing,
what the sum of requests and limits for those pods are,
and how their utilization compares
to their target utilization defined by a horizontal pod
autoscaler.
Note that in this example, we have the horizontal pod
autoscaler's target utilization for a set of pods
well above actual utilization.
This introduces an opportunity for cost optimization
by app right-sizing.
When we have average utilization well below the target
utilization defined in the horizontal pod autoscaler,
we can consider lowering the number of minimum replicas.
By reducing this count, we get to reduce
the cost of running this application,
all while maintaining flexibility to still scale up
to handle varying load.
While we have mainly focused on cost optimization
with the goal of reducing cluster costs,
it's a good time to remind ourselves
that cost optimization and practicing
FinOps is the discipline of balancing
cost with other critical areas.
With this same data, we can also monitor
for under provisioned apps as well,
which are opportunities for right-sizing apps for the sake
of performance and stability.
Over time, you'll find that cluster bin packing and app
right-sizing are intertwined exercises
due to events such as the onboarding of entirely new apps
into a cluster.
Configuring a monitoring system around the topics discussed
here can be complex, so be sure to check out the guide we
published on how to set one up.
With a system set up for cluster bin packing and app
right-sizing, you can ensure that your team will
be able to continuously practice cost optimization for your GKE
clusters.