Add GKE Axion storefront AI assistant learning path

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/_index.md

@@ -0,0 +1,80 @@
+---
+title: Build a mixed-placement AI shopping assistant on GKE with Axion
+
+minutes_to_complete: 120
+description: Deploy an AI shopping assistant for an Online Boutique storefront on GKE and compare N4A and C4A placement for the assistant tier.
+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 and want to place application tiers on the Axion-based machine series that fits each workload.
+
+learning_objectives:
+    - Explain why a storefront application and an AI assistant can have different workload profiles
+    - Build and push a `linux/arm64` container image for the shopping assistant service
+    - 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:
+    - A [Google Cloud account](https://console.cloud.google.com/) with billing enabled
+    - Access to a [GKE Standard cluster with Arm node pools](https://cloud.google.com/kubernetes-engine/docs/how-to/create-arm-clusters-nodes), including an N4A node pool and a C4A node pool
+    - Permission to create or use an [Artifact Registry Docker repository](https://cloud.google.com/artifact-registry/docs/docker/store-docker-container-images) in the same project
+    - Access to Google Cloud Shell, or a local Linux or macOS terminal with `gcloud`, `kubectl`, `docker`, `git`, `jq`, and `python3`
+    - Basic familiarity with Docker, Kubernetes, Kustomize, and Google Kubernetes Engine
+
+author:
+   - Rani Chowdary Mandepudi
+
+generate_summary_faq: true
+rerun_summary: false
+rerun_faqs: false
+
+### Tags
+skilllevels: Advanced
+subjects: Containers and Virtualization
+cloud_service_providers:
+  - Google Cloud
+armips:
+    - Neoverse
+operatingsystems:
+    - Linux
+tools_software_languages:
+    - Kubernetes
+    - GKE
+    - Docker
+    - Kustomize
+    - Python
+    - Ollama
+
+further_reading:
+    - resource:
+        title: Google Kubernetes Engine documentation
+        link: https://cloud.google.com/kubernetes-engine/docs
+        type: documentation
+    - resource:
+        title: Create standard clusters and node pools with Arm nodes
+        link: https://cloud.google.com/kubernetes-engine/docs/how-to/create-arm-clusters-nodes
+        type: documentation
+    - resource:
+        title: Google Axion processors
+        link: https://cloud.google.com/products/axion
+        type: documentation
+    - resource:
+        title: Kustomize documentation
+        link: https://kubectl.docs.kubernetes.io/references/kustomize/
+        type: documentation
+    - resource:
+        title: Ollama documentation
+        link: https://ollama.com/
+        type: documentation
+    - resource:
+        title: Migrate x86 workloads to Arm on Google Kubernetes Engine with Axion processors
+        link: /learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/
+        type: website
+
+### FIXED, DO NOT MODIFY
+# ================================================================================
+weight: 1                       # _index.md always has weight of 1 to order correctly
+layout: "learningpathall"       # All files under learning paths have this same wrapper
+learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
+---
+
+Deploy an Online Boutique storefront on Google Kubernetes Engine (GKE), add an AI shopping assistant, and compare the same assistant workload on N4A and C4A node pools powered by Google Axion processors.
+
+You start with the storefront on N4A, build the missing `shoppingassistantservice` image for `linux/arm64`, validate the assistant on N4A, and then move only the assistant tier to C4A. You finish by running the same fixed benchmark in both placements so you can compare request success, latency, and Kubernetes CPU telemetry.

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/_next-steps.md

@@ -0,0 +1,8 @@
+---
+# ================================================================================
+#       FIXED, DO NOT MODIFY THIS FILE
+# ================================================================================
+weight: 21                  # Set to always be larger than the content in this path to be at the end of the navigation.
+title: "Next Steps"         # Always the same, html page title.
+layout: "learningpathall"   # All files under learning paths have this same wrapper for Hugo processing.
+---

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/background.md

@@ -0,0 +1,78 @@
+---
+title: Understand mixed placement for a storefront AI assistant
+description: Learn why the storefront and assistant tiers use different Axion placements before you build and deploy the assistant.
+weight: 2
+layout: "learningpathall"
+---
+
+## How the application is organized
+
+Modern AI applications often contain more than one workload shape. A storefront tier is steady, service-oriented, and always on. An AI assistant tier is burstier and more latency-sensitive because it performs reasoning work only when users ask for help.
+
+This Learning Path uses that split in a live Online Boutique storefront on Google Kubernetes Engine (GKE). The storefront starts on N4A nodes powered by Google Axion processors. You add the missing `shoppingassistantservice`, run it on N4A first, and then move only that assistant tier to C4A.
+
+The goal isn't to prove that one Axion-based machine series replaces the other. You use N4A for the steady storefront tier and evaluate C4A for the AI reasoning tier so you can decide which machine series fits each workload.
+
+![Architecture diagram showing Cloud Shell and Kustomize deploying Online Boutique to GKE on Axion. Storefront microservices run on N4A, and the shopping assistant runs on C4A with access to cart, catalog, and a local Ollama Gemma model.#center](images/mixed-placement-agentic-storefront-on-axion.png "Mixed-placement agentic storefront on Axion")
+
+The diagram shows the final mixed-placement pattern you build toward. The storefront images already run on Arm nodes, and the assistant image you build later is `linux/arm64` because both target node pools are Arm-based.
+
+## How the storefront already runs on Arm
+
+The storefront baseline uses container images that can run on Arm nodes. A common way to publish portable container images is to use a multi-architecture image, which is one image reference that contains variants for more than one CPU architecture, such as `linux/amd64` and `linux/arm64`.
+
+When Kubernetes schedules a pod that uses a multi-architecture image on an Arm node, the container runtime pulls the Arm-compatible variant from the same image reference. That is why the storefront can already run on Axion nodes before you build the assistant image.
+
+This Learning Path starts with Arm-compatible storefront images already available. To learn the full build-and-publish workflow for multi-architecture images on GKE, see [Migrate x86 workloads to Arm on Google Kubernetes Engine with Axion processors](/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/).
+
+Inspect a public multi-architecture image manifest:
+
+```bash
+docker buildx imagetools inspect docker.io/library/python:3.12-slim
+```
+
+The output is similar to:
+
+```output
+Name:      docker.io/library/python:3.12-slim
+MediaType: application/vnd.oci.image.index.v1+json
+
+Manifests:
+  Platform: linux/amd64
+  Platform: linux/arm64/v8
+```
+
+The exact digest values can differ. The important signal is that one image reference can include an Arm-compatible variant. You confirm the storefront image reference from the source tree in the setup step.
+
+## How the assistant works
+
+The `shoppingassistantservice` is the AI layer for the application. It runs as its own Kubernetes service and receives assistant requests from the storefront frontend.
+
+The assistant uses live storefront services as tools:
+
+- `search_catalog` queries `productcatalogservice`.
+- `get_product_details` fetches a specific product from the live catalog.
+- `get_cart` reads the current cart from `cartservice`.
+- `add_to_cart` updates the cart only after user confirmation.
+
+The assistant sends grounded context to a local Ollama sidecar in the same pod. The sidecar runs the `gemma3:1b-it-qat` model for the reasoning step.
+
+This design keeps the comparison focused. You don't add a separate vector database, retrieval pipeline, or hosted large language model API. You move the assistant logic and local reasoning runtime together as one AI tier.
+
+## How requests flow through the storefront
+
+When a shopper uses the assistant, the request follows this path:
+
+1. The browser sends the request to `frontend`.
+2. `frontend` forwards the request to `shoppingassistantservice`.
+3. The assistant calls live services such as `productcatalogservice` and `cartservice`.
+4. The assistant sends grounded context to the local Ollama sidecar.
+5. The assistant returns the response through `frontend`.
+
+The assistant is agentic because it does more than generate text. It uses application tools, keeps short-lived session state, and asks for confirmation before it calls `cartservice` to update the cart.
+
+## What you've learned and what's next
+
+You've learned why the storefront tier and AI assistant tier use different Axion placements. You also saw how Arm-compatible image variants make the existing storefront portable to Axion nodes.
+
+Next, you'll set up environment variables, connect to the GKE cluster, and clone the source tree that contains the assistant implementation.

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/build-assistant-image.md

@@ -0,0 +1,99 @@
+---
+title: Build and push the assistant image
+description: Build the shopping assistant container image for arm64 and push it to Artifact Registry for deployment on Axion.
+weight: 6
+layout: "learningpathall"
+---
+
+## Build one Arm image for both Axion placements
+
+Both the N4A and C4A node pools in this Learning Path use Arm-based Google Axion processors. You only need one `linux/arm64` assistant image, and that image can run in either placement.
+
+{{% notice Note %}}
+This is an Arm-targeted build for Axion, not a full multi-architecture build. A multi-architecture image is useful when the same tag must support non-Arm environments such as `linux/amd64`.
+{{% /notice %}}
+
+If you opened a new terminal, return to the source tree and restore the required variables:
+
+```bash
+cd "${HOME}/n4a-c4a/microservices-demo"
+
+export PROJECT_ID="$(gcloud config get-value project)"
+export ARTIFACT_REGION="us-central1"
+export ARTIFACT_REPO="axion-workshop"
+```
+
+## Define the image name
+
+Create one reusable image path:
+
+```bash
+export ASSISTANT_IMAGE_REPO="${ARTIFACT_REGION}-docker.pkg.dev/${PROJECT_ID}/${ARTIFACT_REPO}/shoppingassistantservice"
+export ASSISTANT_IMAGE_TAG="lab-v1"
+export ASSISTANT_IMAGE="${ASSISTANT_IMAGE_REPO}:${ASSISTANT_IMAGE_TAG}"
+
+echo "${ASSISTANT_IMAGE}"
+```
+
+## Verify Docker and Buildx
+
+Confirm that Docker and Buildx are available:
+
+```bash
+docker version
+docker buildx version
+```
+
+If Docker is not running in your environment, start it before you continue.
+
+## Configure Artifact Registry authentication
+
+Configure Docker authentication for Artifact Registry:
+
+```bash
+gcloud auth configure-docker "${ARTIFACT_REGION}-docker.pkg.dev" --quiet
+```
+
+Cloud Shell might print a warning about existing credential helpers. You can continue if the command finishes successfully.
+
+## Create a Buildx builder
+
+Create or reuse a Buildx builder:
+
+```bash
+if docker buildx inspect axion-builder >/dev/null 2>&1; then
+  docker buildx use axion-builder
+else
+  docker buildx create --name axion-builder --use
+fi
+
+docker buildx inspect --bootstrap
+```
+
+The output should show a working builder. Confirm that the `Platforms` line includes `linux/arm64` before you continue.
+
+## Build and push the assistant image
+
+Build the assistant image for `linux/arm64` and push it to Artifact Registry:
+
+```bash
+docker buildx build --platform linux/arm64 -t "${ASSISTANT_IMAGE}" --push src/shoppingassistantservice
+```
+
+The command packages the Flask assistant service, protobuf stubs, and Python dependencies. The important success signal is that the build finishes and pushes the image to your Artifact Registry path.
+
+## Verify the pushed tag
+
+List the tags for the assistant image:
+
+```bash
+gcloud artifacts docker tags list "${ASSISTANT_IMAGE_REPO}"
+```
+
+The output should include the `lab-v1` tag.
+
+## What you've accomplished
+
+You've built and published an Arm image for the shopping assistant. Kubernetes can now pull this image when you deploy the assistant on N4A.
+
+Next, you'll create the N4A overlay and add the assistant to the running storefront.