GKE Feature Guide: 5 Ways to Optimize Your Kubernetes Clusters

1575
Of your peers have already read this article.
7:00 Minutes
The most insightful time you'll spend today!
In this post, we’ll be discussing 5 features in GKE you can use to optimize your clusters today. To get started with testing these in GKE, check out our interactive tutorials for getting started with standard and autopilot clusters.
If you find value from running workloads on Kubernetes clusters in your organization, chances are your footprint will grow – be it through larger clusters or more clusters.
Whichever your approach, one thing is certain: you’ll have more resources that you pay for. And you know what they say – more resources, more problems. The more resources you have across clusters, the more critical it becomes to make sure you’re using them efficiently.
Google Kubernetes Engine has numerous features built-in that you as a cluster admin can use to navigate this continuous journey of optimizing your use of resources in GKE.
Let’s review five of them you can get started with today.
#1 – Cluster view cost optimization in the console
If you don’t know where to start with optimizing your clusters, the best place to start is looking for a big problem that stands out. That’s probably most visible by looking at a view that spans all of your clusters.
In GKE, we have a cluster-level cost optimization tab built into the console, rich with information that may be cumbersome to gather on your own otherwise.
You can find this as seen in the following image:

Fig. 1 – Navigating to the cost optimization tab in the cloud console
Once you navigate to this tab, you’re greeted with a time series visualization.
For GKE standard clusters, this visualization is a time series representation that shows three key dimensions for CPU and Memory across all of your clusters in a project:
Total CPU/Memory allocatable– # of CPU or GB of memory that can be allocated to user workloadsTotal CPU/Memory request– # of CPU or GB of memory that has been requested by user workloadsTotal CPU/Memory usage– actual usage by # of CPU or GB of memory by user workloads

Fig. 2 – Allocatable, requested, and usage time series data across CPU or memory in all standard GKE clusters over a specified window
Analyzing these in relationship to one another can help identify answers to important optimization questions such as:
- Do we have too much allocatable CPU and memory idle across our GKE standard clusters? If so, can we do things like re-evaluate the machine types we use in node pools? This can help us bin pack the cluster, by having a higher percentage of allocatable resources allocated to Pod requests.
- Are workloads running in our GKE standard clusters requesting too much CPU and memory that goes unused? If so, can we do things like work with workload owners to adjust requests? This can help us workload right-size, by setting requests to more closely reflect expected usage.
If we’re using GKE Autopilot, this time series visualization will look slightly different, as seen in the following image:

Fig. 3 – Requested and usage time series data across CPU or memory in all GKE Autopilot clusters
In the case of GKE Autopilot clusters, we’re only able to view the Total CPU/Memory request and the Total CPU/Memory usage data. But nothing here is actually missing!
In Autopilot clusters, you only pay per Pod based on its requests; Autopilot automatically handles provisioning the infrastructure that gives us our allocatable resources based on whatever you set Pod requests to. When we trade in that ownership of node provisioning, we also trade in the control to optimize at that layer.
For a cluster administrator, this information can be a spark to spur actions such as diving into individual clusters or meeting with workload teams to work through their requests and limits that they set for workloads. In our research, this is perhaps the most impactful area many teams optimize. We’ll dive into how GKE can enable this exercise a bit further in this blog.
When going down those paths, it helps to have financial data to quantify the impact of the optimization to the business. Gathering this info on your own can require a bit of work (for some, a lot of spreadsheets as well!), but luckily GKE has another native feature to help make this easily accessible to you.
#2 – GKE cost allocation
GKE cost allocation is a native GKE feature that integrates workload usage with Cloud Billing and its reports, allowing you to see and alert on billing not only on a per-cluster level, but on a per-Kubernetes namespace or per-Kubernetes label level.
It must be enabled on your cluster in order for it to function, so if you’re working with an existing GKE cluster and want to enable it, use the following gcloud command once you have set your appropriate zone or region:
$ gcloud beta container clusters create $CLUSTER_NAME \
--enable-cost-allocation
Without GKE cost allocation, the financial impact of a cluster and all of the different workloads it might run were a bit obfuscated. With the cluster as the deepest level of detail in billing, finding areas to optimize or even performing showback and chargeback was a challenge.
With Namespaces and Labels bubbling up into billing reports, you can now understand the cost of the CPU/Memory requests that workloads define in Kubernetes. A caveat – this works best when you are using Namespaces and Labels to logically define and organize teams and their workloads.
This integration also gives the bigger picture of optimization – in that GKE does not typically live on an island! In theory, workloads in a team’s namespace could be using external backing services like Cloud Memorystore that are also a key part of its usage.
Because Cloud Billing data has all GCP services, we can now filter and query across namespaces and their corresponding backing services.
# 3 – Workload view cost optimization in the console
Once you have teams identified that you may want to work with, GKE provides a cost optimization tab at the workload level, where you can then begin to drill down and identify specific workloads that could be optimized through an exercise called “workload right-sizing”. This is the act of making sure that Pod requests more closely reflect their expected usage.

As you can see here, we’re given bar charts to represent the relationship of usage, requests, and limits to one another.
- Dark green: CPU/Memory usage
- Light green: CPU/Memory requests
- Grey: CPU/Memory Limits
- Yellow: Scenarios in which CPU/Memory usage exceeds requests
You can also hover over each individual workload bar chart to reveal a small on-screen report of this data. Similar to the cluster view cost optimization tab, you can filter down to a custom time window; we recommend viewing this data in a window greater than an hour (IE a day, week, month) to potentially uncover diurnal or weekly patterns that would otherwise be obfuscated.
In the preceding screenshot of these charts, we can call out a few patterns that might stand out to you:
- If we have too much light green stacked above dark green in a bar, we may have workloads that are over provisioned.
- If we have a yellow bar, we have a workload where requests are not set high enough, which can be a stability/reliability risk – consuming additional resources on its node and potentially being throttled or OOMKilled if it hits its limits.
- If we have a bar that is all dark green, this means that we don’t have requests set for a workload – which is not best practice! Set those requests.
With this information, it becomes easier to quickly identify workloads that need requests and limits tuned for either cost optimization or stability and reliability.
# 4 – Recommendations for adjusting workload requests
In scenarios where we need to increase or reduce CPU/Memory requests, it is easier to know that it needs to be done than to know how it needs to be done. What should we set the requests to?

GKE integrates recommendations from the Kubernetes Vertical Pod Autoscaler (VPA) directly into its workload console, currently for all deployments in your clusters. You can find this by navigating to the Actions > Scale > Scale compute resources menu when viewing the page for a specific workload.
It’s important to remember that these recommendations are just that – recommendations. They’re based on historical usage data, so when viewing these values, it’s important to work with workload owners to see if these suggestions make sense to incorporate into their respective Kubernetes manifests.
# 5 – Cost estimation and cluster creation setup guides
Finally, if you’re just getting started with GKE and you want to get started on the right, optimized foot, we have tooling incorporated into the GKE cluster creation page.

First, we have a setup guide that will help you create an opinionated GKE standard cluster with some things we discussed here already enabled, such as GKE cost allocation and Vertical Pod Autoscaler.
Second, we also have a cost estimation panel that, depending on the configuration of your GKE standard cluster, will show you an estimated monthly cost. This even helps you get a range of potential costs if you expect your cluster to scale up and down!
Now what?
Optimization across a set of GKE clusters can include a handful of areas to think about – and isn’t a one time task! Instead, it’s a continuous journey that cluster administrators, workload owners, and even billing managers all take part in. GKE provides the tooling to make this journey and process easier, with the right data and insights at your fingertips.
To familiarize yourself with these features in GKE, check out our interactive tutorials for getting started with standard and autopilot clusters.
You can also watch a demo showing most of these features in the following video:
A special thanks to Laurie White, Fernando Rubbo, and Bobby Allen for their review on this blog post.
3445
Of your peers have already watched this video.
51:50 Minutes
The most insightful time you'll spend today!
API Design Best Practices and Common Pitfalls
The job of an API is to make the application developer as successful as possible. When crafting APIs, the primary design principle should be to maximize application developer productivity and promote adoption.
API designers and developers generally understand the importance of adhering to design principles while implementing an interface. No one wants to design or implement a bad API! Even so, it’s sometimes tempting to look for shortcuts to reach those aggressive sprint timelines, get to the finish line, and deploy an API. The result? Not so desirable!
So what are the API design principles that help optimize developer productivity?
Watch Martin Nally explore the problems and solutions of quality API design. In this webcast , Nally shares insights on topics like designing quality APIs within the limitations of legacy software and recommendations on the technology choices that best satisfy the varying goals.
Nally is a Senior Software Engineer, Apigee for Google Cloud and has almost 40 years of experience as a software developer and architect and is an expert in web APIs. He currently designs and implements systems using APIs at Google.
Google Extends Support for Windows Server Containers on Anthos for Faster App Modernization and Consistent Dev Experience

5609
Of your peers have already read this article.
3:00 Minutes
The most insightful time you'll spend today!
Today, many applications in organizations’ data centers run on Windows Server. Modernizing these traditional Windows apps onto Kubernetes promises a host of benefits: a consistent platform across environments, better portability, scalability, availability, simplified management and speed of deployment, just to name a few. But how? Rewriting traditional .NET applications to run on Linux with .NET Core can be challenging and time-consuming. There is, however, a lower-toil, more developer friendly option.
Last year, we announced support for Windows Server containers running on Google Kubernetes Engine (GKE), our cloud-based managed Kubernetes service, which lets you take the advantage of containers without porting your apps to .NET core or rewriting them for Linux. Today, we’re going a step further with support for Windows Server containers on Anthos clusters on VMware in your on-premises environment. Now available in preview, you can consolidate all your Windows operations across on-prem and Google Cloud.
Bringing Windows Server support to our family of Kubernetes-based services—GKE running on Google Cloud, and Anthos everywhere—with the same experience, lets you modernize apps faster and achieve a consistent development and deployment experience across hybrid and cloud environments. Further, by running Windows and Linux workloads side by side, you get operational consistency and efficiency—no need to have multiple teams specializing in different tooling or platforms to manage different workloads. The single-pane-of-glass view and the ability to manage policies from a central control plane simplifies the management experience, while bin packing multiple Windows applications drives better resource utilization, leading to infrastructure and license savings.

With all these benefits, it’s no surprise that customers such as Thales, a French multinational firm specializing in aerospace and security services, have been able to reap significant benefits by moving Windows applications to GKE.
“We moved our Windows applications from VMs to Windows containers on GKE and now have a unified mechanism for Linux and Windows-based application management, scaling, logging, and monitoring. Earlier, setting up these applications in VMs and configuring them for high availability used to take up to a week, and the applications were not easily scalable,” said Najam Siddiqui, Solutions Architect at Thales. “Now with GKE, the setup takes only a few minutes. GKE’s automatic scaling and built-in resiliency features make scaling and high-availability setup seamless. Also, manually maintaining the VMs and applying security patches used to be tedious, which is now handled by GKE.”
Let’s take a deeper look at the architecture that lets you run your Windows container-based workloads on-prem.
Windows Server running on-prem with Anthos
The diagram below illustrates the high-level architecture of running Windows container-based workloads in an on-prem GKE cluster with Anthos. Windows server node-pools can be added to an existing or new Anthos cluster. Kubelet and Kube-proxy run natively on Windows nodes, allowing you to run mixed Windows and Linux containers in the same cluster. The admin cluster and the user cluster control plane continue to be Linux-based, providing you a consistent orchestration experience and management ease across Windows and Linux workloads.

Get started today
When considering modernizing your on-prem Windows estate, we recommend running Windows Server containers on Anthos in your own data center. If you are new to Anthos, the Anthos getting started page and the Coursera course on Architecting Hybrid Cloud with Anthos are good places to start. You can also find detailed documentation on our website, and our partners are eager to help you with any questions related to the published solutions, as is the GCP sales team. And as always, please don’t hesitate to reach out to us at anthos-onprem-windows@google.com if you have any feedback or need help unblocking your use case.
5054
Of your peers have already watched this video.
21:00 Minutes
The most insightful time you'll spend today!
Uber’s Story of Scaling Their App with Millions of Concurrent Requests
Uber has millions of concurrent customers who use the platform to book rides and place food delivery orders, generating billions of database transactions per day. In just a click of a button, Uber captures users’ intent which bases their fulfillment model to meet the customers’ demand, and match it to active providers that address their demand with supply.
Uber’s fulfillment platform capability is the lifeline powering every line of business and also allows rapid scaling of new verticals. Hundreds of microservices at Uber depend on this fulfillment platform as a source of truth for all their active booking, delivery or order session. The events generated by this platform are used by hundreds of offline data sets to power business decisions. Additionally over hundreds of developers at Uber extend the platform with APIs, events and codes to build 120+ unique fulfillment flows!
Watch the video to learn about Uber’s decision to move from on-prem to Google Cloud’s Cloud Spanner while still taking live orders at scale and meeting customers’ expectations.
Google Cloud Helped Digitec Galaxus Personalize Over 2 Million Newsletters in a Week

8321
Of your peers have already read this article.
3:00 Minutes
The most insightful time you'll spend today!
Digitec Galaxus AG is the biggest online retailer in Switzerland, operating two online stores: Digitec, Switzerland’s online market leader for consumer electronics and media products, and Galaxus, the largest Swiss online shop with a steadily growing range of consistently low-priced products for almost all daily needs.
Known for its efficient, personalized shopping experiences, it’s clear that Digitec Galaxus understands what it takes to deliver a platform that is interesting and relevant to customers every time they shop.
The problem: Personalizing decisions for every situation
Digitec Galaxus already had established an engine to help them personalize experiences for shoppers when they reached out to Google Cloud. They had multiple recommendation systems in place and were also extensive early adopters of Recommendations AI, which already enabled them to offer personalized content in places like their homepages, product detail pages, and their newsletter.
But those same systems sometimes made it difficult to understand how best to combine and optimize to create the most personalized experiences for their shoppers. Their requirements were threefold:
- Personalization: They have over 12 recommenders they can display on the app, however they would like to contextualize this and choose different recommenders (which in turn select the items) for different users. Furthermore they would like to exploit existing trends as well as experiment with new ones.
- Latency: They would like to ensure that the solution is architected so that the ranked list of recommenders can be retrieved with sub 50 ms latency.
- End-to-end easy to maintain & generalizable/modular architecture: Digitec wanted the solution to be architected using an easy to maintain, open source stack, complete with all MLops capabilities required to train and use contextual bandits models. It was also important to them that it is built in a modular fashion such that it can be adapted easily to other use cases which have in mind such as recommendations on the homepage, Smartags and more .
To improve, they asked us to help them implement a machine learning (ML) contextual bandit based recommender system on Google Cloud taking all the above factors into consideration to take their personalization to the next level.
Contextual bandits algorithms are a simplified form of reinforcement learning and help aid real-world decision making by factoring in additional information about the visitor (context) to help learn what is most engaging for each individual. They also excel at exploiting trends which work well, as well as exploring new untested trends which can yield potentially even better results. For instance, imagine that you are personalizing a homepage image where you could show a comfy living room couch or pet supplies.
Without a contextual bandit algorithm, one of these images would be shown to someone at random without considering information you may have observed about them during previous visits. Contextual bandits enable businesses to consider outside context, such as previously visited pages or other purchases, and then observe the final outcome (a click on the image) to help determine what works best.
Creating a personalization system with contextual bandits
While Digitec Galaxus heavily personalizes their website homepages, they are very very sensitive and also require more cross-team collaboration to update and make changes.
Together with the Digitec Galaxus team, we decided to narrow the scope and focus on building a contextual bandit personalization system for the newsletter first. The digitec Galaxus team has complete control over newsletter decisions and testing various ML experiments on a newsletter would have less chance of adverse revenue impact than a website homepage.
The main goal was to architect a system that could be easily ported over to the homepage and other services offered by Digitec with minimal adaptations. It would also need to satisfy the functional and non-functional requirements of the homepage as well as other internal use cases.
Below is a diagram of how the newsletter’s personalization recommendation system works:

- The system is given some context features about the newsletter subscriber such as their purchase history and demographics. Features are sometimes referred to as variables or attributes, and can vary widely depending on what data is being analyzed.
- The contextual bandit model trains recommendations using those context features and 12 available recommenders (potential actions).
- The model then calculates which action is most likely to enhance the chance of reward (a user clicking in the newsletter) and also minimize the problem (an unsubscribe).
Calculating whether a click was a newsletter or an unsubscribe enabled the system to optimize for increasing clicks and avoid showing non-relevant content to the user (click-bait). This enabled Digitec Galaxus to exploit popular trends while also exploring potentially better-performing trends.
How Google Cloud helps
The newsletter context-driven personalization system was built on Google Cloud architecture using the ML recommendation training and prediction solutions available within our ecosystem.
Below is a diagram of the high-level architecture used:
The architecture covers three phases of generating context-driven ML predictions, including:
ML Development: Designing and building the ML models and pipeline
Vertex Notebooks are used as data science environments for experimentation and prototyping. Notebooks are also used to implement model training, scoring components, and pipelines. The source code is version controlled in Github. A continuous integration (CI) pipeline is set up to automatically run unit tests, build pipeline components, and store the container images to Cloud Container Registry.
ML Training: Large-scale training and storing of ML models
The training pipeline is executed on Vertex Pipelines. In essence, the pipeline trains the model using new training data extracted from BigQuery and produces a trained, validated contextual bandit model stored in the model registry. In our system, the model registry is a curated Cloud Storage.
The training pipeline uses Dataflow for large scale data extraction, validation, processing, and model evaluation, and Vertex Training for large-scale distributed training of the model. AI Platform Pipelines also stores artifacts, the output of training models, produced by the various pipeline steps to Cloud Storage. Information about these artifacts are then stored in an ML metadata database in Cloud SQL. To learn more about how to build a Continuous Training Pipeline, read the documentation guide.
ML Serving: Deploying new algorithms and experiments in production
The training pipeline uses batch prediction to generate many predictions at once using AI Platform Pipelines, allowing Digitec Galaxus to score large data sets. Once the predictions are produced, they are stored in Cloud Datastore for consumption. The pipeline uses the most recent contextual bandit model in the model registry to evaluate the inference dataset in BigQuery and give a ranked list of the best newsletters for each user, and persist it in Datastore. A Cloud Function is provided as a REST/HTTP endpoint to retrieve the precomputed predictions from Datastore.
All components of the code and architecture are modular and easy to use, which means they can be adapted and tweaked to several other use cases within the company as well.
Better newsletter predictions for millions
The newsletter prediction system was first deployed in production in February, and Digitec Galaxus has been using it to personalize over 2 million newsletters a week for subscribers. The results have been impressive, 50% higher than our baseline. However, the collaboration is still ongoing to improve the results even more.
“Working at this level in direct exchange with Google’s machine learning experts is a unique opportunity for us. The use of contextual bandits in the targeting of our recommendations enables us to pursue completely new approaches in personalization by also personalizing the delivery of the respective recommender to the user. We have already achieved good results in our newsletter in initial experiments and are now working on extending the approach to the entire newsletter by including more contextual data about the bandits arms. Furthermore, as a next step, we intend to apply the system to our online store as well, in order to provide our users with an even more personalized experience. To build this scalable solution, we are using Google’s open source tools such as TFX and TF Agents, as well as Google Cloud Services such as Compute Engine, Cloud Machine Learning Engine, Kubernetes Engine and Cloud Dataflow.”—Christian Sager, Product Owner, Personalization ( Digitec Galaxus)
Since the existing architecture and system is also dynamic, it will automatically adapt to new behaviours, trends, and users. As a result, Digitec Galaxus plans to re-use the same components and extend the existing system to help them improve the personalization of their homepage and other current use cases they have within the company. Beyond clicks and user engagement, the system’s flexibility also allows for future optimization of other criteria. It’s a very exciting time and we can’t wait to see what they build next!
4175
Of your peers have already watched this video.
1:30 Minutes
The most insightful time you'll spend today!
Video: How Pitney Bowes Leveraged Apigee to Create New Revenue Streams
Headquartered in Stamford, Connecticut, Pitney Bowes helps businesses navigate the complex world of commerce. They enable organizations to send parcels and packages across the globe. Pitney Bowes serves 90 percent of Fortune 500 companies, has 90 plus years of innovation, supports 1.5 million small businesses and has 15,000 employees globally.
The company leveraged the Apigee platform and was able to create a self-service model for both its internal and external customers. The monetization capability of Apigee empowered the organization to create new revenue streams.
“The monetization capability of Apigee has helped us create new revenue streams and business models for Pitney Bowes. Now we have tens and millions of dollars in revenue that we never had in 2016,” says Roger Pilc, Chief Innovation Officer, Pitney Bowes.
Watch the full video to get more insights on how Apigee helped Pitney Bowes boost its business.
More Relevant Stories for Your Company

Reduce Costs, Increase Profits by Modernizing Your Mainframe Applications with Google Cloud
Mainframe powers much of global commerce and for decades—with its proprietary platform and legendary lock-in—was resistant to effective competition. Even years after most organizations began adopting public cloud, migrating off the mainframe remains too complex for many organizations to undertake. Google Cloud brings a unique, automated approach to modernization enabling

MerPay Platform Scales its Reach to Millions of Users using Cloud Spanner
Editor’s note: To launch a new mobile payment platform, Mercari needed a database solution strong on scalability, availability, and performance. Here’s how Cloud Spanner delivered those results. E-commerce companies need to connect customers to their services securely, reliably, with zero downtime. When Mercari, Inc. launched a new mobile payment platform, we chose Cloud

Container Platforms on Google Cloud Maximize Developer Efficiency, Speed-up Time to Market and Eliminate IT Overhead!
Every tech company and growing startup faces pressure to make efficient use of technical talent. Increasingly, this means determining if and how the cloud can help this talent focus on things like product development instead of IT overhead. These challenges are the starting place for our new whitepaper “The future

Why Your Company Needs an Enterprise Gearbox
For most established businesses today, the disruptive start-up has emerged as the biggest and most intimidating competition. A start-up's digital prowess and astounding ability to innovate and scale massively in weeks, for what takes conventional businesses quarters, is daunting. How does one compete with that? To play in today’s digitally-connected






