Deploy a mixed-placement AI shopping assistant on Google Kubernetes Engine with Axion-based compute
Introduction
Understand mixed placement for a storefront AI assistant
Set up the source tree and cluster access
Deploy and validate the storefront baseline on the Google N4A node pool
Review the shopping assistant implementation
Build and push the assistant image to Artifact Registry
Deploy the assistant on the Google N4A node pool
Observe and benchmark the assistant on the Google N4A node pool
Move the assistant to the Google C4A node pool and compare results
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Advanced
Reading time:  2 hrs
Last updated:  13 Jul 2026
Skill level:
  Advanced
Reading time:
  2 hrs
Last updated:
  13 Jul 2026
Author:Rani Chowdary Mandepudi, Arm
Arm IP:Neoverse-N3 Neoverse-V2
Tags: Containers and Virtualization Google Cloud Linux Kubernetes GKE Docker Kustomize Python Ollama Gemma
Author:
  • Rani Chowdary Mandepudi, Arm
Arm IP:
Neoverse-N3 Neoverse-V2
Tags:
Containers and Virtualization Google Cloud Linux Kubernetes GKE Docker Kustomize Python Ollama Gemma

Who is this for?

This is an advanced topic for cloud developers, platform engineers, and site reliability engineers who run applications on Google Kubernetes Engine (GKE) and want to place application tiers on the Axion-based machine series that fits each workload.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Deploy and validate an Online Boutique storefront on an N4A node pool
  • Build and push a `linux/arm64` container image, then add the AI shopping assistant to the storefront
  • Use Kustomize overlays to run the assistant on N4A first, then move it to C4A
  • Capture and compare benchmark summaries for the same assistant workload on N4A and C4A

Prerequisites

Before starting, you will need the following:

  • A Google Cloud account with billing enabled
  • Access to a GKE Standard cluster with Arm node pools , including N4A and C4A node pools, with the Kubernetes Metrics API enabled
  • Permissions to get cluster credentials, deploy Kubernetes workloads and services, read pod logs and metrics, and create or use an Artifact Registry Docker repository
  • Cloud Shell or a Linux or macOS administrative workstation with Docker Buildx, gcloud, kubectl, git, curl, Python 3.10 or later, and jq
  • Basic familiarity with Docker, Kubernetes, Kustomize, and GKE

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 deploy the Online Boutique storefront on Google Kubernetes Engine using Arm-based Axion nodes, validate a baseline on N4A, and add a gRPC-driven AI shopping assistant. You’ll build and push a single linux/arm64 container image to Artifact Registry, then use Kustomize overlays to run the assistant on N4A before moving only that tier to C4A. After reviewing the assistant’s source code and runtime dependencies, you’ll confirm scheduling on the intended node pool and capture benchmark summaries to compare the same assistant workload across N4A and C4A. You’ll finish with a mixed-placement deployment where the steady storefront remains on N4A and the burstier assistant runs on the selected pool.

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
?
How do I verify the cluster has both N4A and C4A node pools before I start?
Use kubectl to list nodes and confirm that both pools are present. The workflow assumes an arm64 GKE Standard cluster with separate N4A and C4A pools.
What result should I expect after I apply the baseline overlay?
The storefront runs on N4A, and shoppingassistantservice isn’t present. This is intentional because you’ll build and deploy the assistant in later steps.
I've run this path before. What should I remove before I recreate the baseline?
Delete any existing assistant deployment, related service, and service account so the baseline reflects a storefront without the assistant.
Do I need different container images for N4A and C4A when I deploy the assistant?
No. You’ll build one linux/arm64 image targeted for Axion that’ll run in either placement.
How do I confirm the assistant is scheduled on the intended node pool when I switch from N4A to C4A?
Check the node assigned to the assistant pod and verify it matches the target pool after applying the appropriate Kustomize overlay. Inspect pod logs and service reachability to confirm the tier is healthy before capturing benchmarks.
Next