Learn how to migrate an x86 application to multi-architecture with Arm-based on Google Axion Processor on GKE
Introduction
Build and deploy a multi-arch application on GKE
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

Learn how to migrate an x86 application to multi-architecture with Arm-based on Google Axion Processor on GKE

About this Learning Path

Skill level:  Advanced
Reading time:  30 min
Last updated:  14 Sep 2026
Skill level:
  Advanced
Reading time:
  30 min
Last updated:
  14 Sep 2026
Author:Pranay Bakre, Arm
Arm IP:Neoverse
Tags: Containers and Virtualization Google Axion Linux Kubernetes Runbook
Author:
  • Pranay Bakre, Arm
Arm IP:
Neoverse
Tags:
Containers and Virtualization Google Axion Linux Kubernetes Runbook

Who is this for?

This is an advanced topic for software developers who are looking to migrate their existing x86 containerized applications to Arm

What will you learn?

After completing this Learning Path, you'll be able to perform the following tasks:

  • Add Arm-based nodes powered by Google Axion to an existing x86-based Google Kubernetes Engine (GKE) cluster.
  • Rebuild an x86-based application to make it multi-arch and run on Arm.
  • Add taints and tolerations to GKE clusters to schedule application pods on architecture specific nodes.
  • Run a multi-arch application across multiple architectures on a single GKE cluster.

Prerequisites

Before starting, you'll need the following prerequisites:

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll extend an existing x86 GKE cluster with Arm capacity using Google Axion-based C4A nodes. First, you’ll rebuild the application image for multiple architectures and configure taints and tolerations for scheduling. Then, you’ll deploy workloads either to selected nodes or both architectures and verify that the multi-architecture image runs across the hybrid cluster.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
Which GKE machine type should I use for the Arm-based nodes?
Use the C4A family of virtual machines. C4A is based on Google Axion with Armv9 Neoverse V2 CPUs.
How do I know my cluster now has both x86 and Arm nodes?
Use kubectl to inspect the node list and verify that C4A nodes are present alongside the existing x86 nodes. Check node details to confirm the architecture of each node.
When should I apply taints and tolerations?
Apply taints to architecture-specific nodes when you need to control where pods schedule. Add matching tolerations to pod specs so that workloads can target Arm or x86 nodes as intended.
Which image does each architecture-specific overlay deploy?
Apply the x86 overlay with the x86-hello:v0.0.1 image or the Arm overlay with arm-hello:v0.0.1. Check the pod output to verify the reported CPU platform.
What should I check if pods don't schedule on the Arm nodes?
Verify that Arm-based C4A nodes are part of the cluster. Ensure taints and tolerations match, and confirm the image includes an Arm build. Resolve any mismatch before redeploying.
Next