A Look into Google Axion Processors: Google’s New ARM-Based CPUs

Google released its Axion instances powered by custom ARM chips today. These instances were first introduced in April 2024, and they are now generally available following the announcement by Amin Vahdat, VP/GM ML, Systems & Cloud AI, at the Google Cloud App Dev & Infrastructure Summit.

Cloudfleet is an ARM-first company, a principle that starts with our developers using Apple Silicon laptops. We chose to deploy our product only on ARM servers across various cloud providers and on-premises environments. Our build pipelines, control plane, and even the Cloudfleet Kubernetes Engine (CFKE) product itself all run on ARM servers. This means that if you’re a Cloudfleet customer using CFKE, your Kubernetes control plane is also running on ARM. ARM’s unbeatable price-performance enables us to offer extremely competitive options, including free Kubernetes control planes.

Naturally, Axion was exciting news for us from its initial announcement. During its private preview, we partnered with Google to test Axion instances for our internal workloads, primarily in build pipelines and data analytics, to evaluate the benefits they offer. In this blog, we will discuss the advantages of ARM CPUs, how we’ve used them in our internal workloads, and how Cloudfleet customers can now migrate their applications to Axion.

Why ARM?

ARM processors offer several benefits that make them a popular choice for a wide range of applications. Their energy-efficient architecture delivers high performance while consuming less power, making them ideal for mobile devices, embedded systems, and energy-conscious data centers. The reduced instruction set computing (RISC) design of ARM enables faster task execution and lower latency, contributing to improved system responsiveness. Their scalability - from low-power microcontrollers to high-performance computing - further enhances their versatility across different markets.

The migration path

When Google invited us to test drive the Axion instances, migration was not an issue: the preview took place in only a few regions, but fortunately, we were operating in one of them.

Our internal software is written in Go, Java, and TypeScript. As a Kubernetes company, it’s no surprise that all our software runs in containers. We cross-compile every container we have for both x86 and ARM simultaneously. This ensures that wherever we deploy our Kubernetes clusters, Kubernetes selects the correct architecture within the same container image and runs the appropriate binary. As mentioned above, our infrastructure exclusively runs on ARM instances, previously deployed on Google’s Ampere-based ARM instances (T2A).

To migrate to Axion, we simply had to switch the instance type of our Kubernetes nodes from T2A to C4A (the codename for Axion instances), and we didn’t need to adjust anything else!

If we had been migrating from x86, we would have needed to modify our build process to cross-compile our software for ARM. Docker provides an excellent blog post on the necessary changes and includes an example for Go. We can confirm that cross-compiling software in Go, Java, and Node is very straightforward, and we highly recommend doing it now.

Axion performance

The CFKE control plane consists of numerous components abstracted from our customers. These components handle tasks ranging from scheduling workloads to inspecting every request to the Kubernetes API Server to enforce guardrails, making CFKE a secure Kubernetes service. Almost all of these components use large Kubernetes Go libraries, which are notoriously time-consuming to compile.

Since our build pipeline for the CFKE control plane is one of our most CPU-intensive tasks, we put Axion into action to test how it improves build times.

We want to share the build times for three control plane components: Node Scheduler, which is responsible for finding and launching the right compute node for pending Pods; Authentication Webhook, which inspects every request to the Kubernetes API Server and enforces guardrails; and Metadata Server, which CFKE nodes connect to in order to collect authentication tokens and other useful information.

Understanding why some components showed greater performance improvements than others is a topic for further investigation, but even the smallest increase was a significant win for us!

Our tests are still ongoing to evaluate the runtime performance of these components, but we are confident that we will want to transition our customer Control Planes from Ampere to Axion in CFKE regions hosted on Google Cloud.

Use Axion today with CFKE

With today’s General Availability announcement from Google, we are also pleased to announce that Axion-powered instances are available in all CFKE clusters. As usual, if the CFKE algorithm determines that Axion instances are the most cost-effective option meeting your workload’s criteria, the CFKE scheduler will select an Axion instance to launch your node. However, by using nodeSelector or affinity rules, you can force CFKE to launch a specific type of instance.

For example, you can use the following nodeSelector block to schedule your Pod on a c4a-standard-8 instance, which has 8 Axion cores and 32 GB of RAM:

nodeSelector:
  cfke.io/provider-instance-type: c4a-standard-8

Of course, you need to ensure that your container supports ARM architecture.

Conclusion

We are extremely excited to see the rapid adoption of ARM technology with the latest releases from cloud providers, and our early access testing of Google Cloud’s Axion instances demonstrated significant performance gains.

We built Cloudfleet because we believe customers deserve flexibility as new infrastructure options come to market. Migration costs should be a thing of the past. With Cloudfleet Kubernetes Engine, upgrading to the latest and most advanced hardware is simply a matter of changing a few lines of code. By supporting Axion instances from day one, we are pleased to offer our customers a new hardware option and hope they will be as happy with Axion as we are.