From b72bdd8131358896b9e198da31c739a8ff143579 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Mon, 10 Nov 2025 15:11:23 +0000 Subject: [PATCH 1/6] Update GKE multi-arch Axion learning path content and structure - Revise titles and weights for clarity and organization - Enhance descriptions for target audience and learning objectives - Add new background section detailing migration process and benefits --- .../gke-multi-arch-axion/_index.md | 20 ++++---- .../gke-multi-arch-axion/background.md | 48 +++++++++++++++++++ .../gke-multi-arch-axion/cloud-build.md | 2 +- .../gke-multi-arch-axion/gke-build-push.md | 2 +- .../gke-multi-arch-axion/gke-deploy.md | 2 +- .../gke-multi-arch-axion/multi-arch-images.md | 2 +- .../gke-multi-arch-axion/project-setup.md | 2 +- 7 files changed, 61 insertions(+), 17 deletions(-) create mode 100644 content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/_index.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/_index.md index 1b1e96f4b..dbfdb6c76 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/_index.md @@ -1,24 +1,20 @@ --- -title: From x86 to Arm on GKE - Build, Deploy, and Migrate with Google Axion - -draft: true -cascade: - draft: true +title: Migrate x86 workloads to Arm on GKE with Google Axion minutes_to_complete: 90 -who_is_this_for: This is an advanced topic for cloud, platform, and site reliability engineers operating Kubernetes on Google Cloud who need a prescriptive path to build multi-architecture images and migrate services from x86 to Arm using Google Axion processors. +who_is_this_for: This is an advanced topic for cloud, platform, and site reliability engineers who operate Kubernetes on Google Cloud and need to build multi-architecture images and migrate services from x86 to Arm using Google Axion processors. learning_objectives: - Prepare Dockerfiles for multi-architecture builds by adding arm64 support - - Create a dual-architecture GKE standard cluster with two node pools, amd64 and arm64 - - Build and publish multi-architecture images to Artifact Registry using Docker Buildx without using QEMU to emulate Arm instructions - - Deploy a Kubernetes application amd64 first, then migrate to arm64 using Kustomize overlays and progressive rollout - - Optionally automate builds and rollouts with Cloud Build and Skaffold + - Create a dual-architecture GKE standard cluster with amd64 and arm64 node pools + - Build and publish multi-architecture images to Artifact Registry using Docker Buildx + - Deploy a Kubernetes application on amd64, then migrate to arm64 using Kustomize overlays + - Automate builds and rollouts with Cloud Build and Skaffold prerequisites: - A [Google Cloud account](https://console.cloud.google.com/) with billing enabled - - A local Linux or macOS computer or Cloud Shell access with Docker, Kubernetes CLI (kubectl), Google Cloud CLI (gcloud), and Git installed + - A local Linux or macOS computer with Docker, Kubernetes CLI (kubectl), Google Cloud CLI (gcloud), and Git installed, or access to Google Cloud Shell - Basic familiarity with Docker, Kubernetes, and gcloud author: @@ -44,7 +40,7 @@ further_reading: link: https://cloud.google.com/kubernetes-engine/docs type: documentation - resource: - title: Create Arm-based clusters and node pools + 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 diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md new file mode 100644 index 000000000..6d5018618 --- /dev/null +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md @@ -0,0 +1,48 @@ +--- +# User change +title: "Overview and Environment Setup" + +weight: 2 # 1 is first, 2 is second, etc. + +# Do not modify these elements +layout: "learningpathall" +--- + +This Learning Path demonstrates how to migrate a real microservices application from x86 to Arm (amd64 to arm64) on GKE using multi-architecture container images. The sample application is Google's Online Boutique, a polyglot microservices system that mirrors production architectures and ships with Dockerfiles. It's a realistic, real-world scenario, and the migration can be done with no major code changes. + +## Why Google Axion processors for GKE? + +Google Axion processors bring modern Arm-based compute to GKE, delivering strong price-performance and energy efficiency for cloud-native, scale-out services. With multi-architecture images and mixed node pools, services can migrate from x86 to Arm gradually, with no major code changes. + +### What is Google Axion? + +[Google Axion](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) is Google Cloud's Arm-based CPU family built on Arm Neoverse, designed for general-purpose, cloud-native services and CPU-based AI. Typical workloads include web apps and web servers, containerized microservices, open-source databases, in-memory caches, data analytics, media processing, and CPU-based AI inference and data processing. On GKE, Axion powers the C4A and N4A VM families and is paired with Google's Titanium offloads to free CPU cycles for application work. + +### Why migrate to Arm on GKE? + +There are three factors motivating the move to Google Axion processors: + +- **Price-performance:** run more workload per dollar for scale-out services +- **Energy efficiency:** reduce power usage for always-on microservices +- **Compatibility:** containerized apps typically migrate with build/deploy changes, and don't require code rewrites + +### About the Online Boutique sample application + +[Online Boutique](https://github.com/GoogleCloudPlatform/microservices-demo) is a polyglot microservices storefront, complete with shopping cart, checkout, catalog, ads, and recommendations. It's implemented in Go, Java, Python, .NET, and Node.js, with ready-to-use Dockerfiles and Kubernetes manifests. It's a realistic example for demonstrating an x86 to Arm migration with minimal code changes. + +### Multi-architecture on GKE (pragmatic path) + +This Learning Path presents a pragmatic migration approach that builds both amd64 and arm64 images using Docker Buildx with a Kubernetes driver, where builds run natively inside BuildKit pods on your GKE node pools without requiring QEMU emulation. You'll add an Arm node pool alongside existing x86 nodes, then use node selectors and affinity rules to control placement and migrate safely, service by service. + +### How this Learning Path demonstrates the migration + +You'll migrate the Online Boutique application from x86 to Arm using a practical, low-risk approach that leverages multi-architecture container images and mixed node pools. This allows you to validate each service on Arm before fully committing to the migration, ensuring compatibility and performance meet your requirements. + +The steps below outline the migration process: + +1. Open Google Cloud Shell and set the environment variables. +2. Enable required APIs, create an Artifact Registry repository, and authenticate Docker. +3. Create a GKE Standard cluster with an amd64 node pool and add an arm64 (Axion-based C4A) node pool. +4. Create a Buildx (Kubernetes driver) builder that targets both pools, then build and push multi-architecture images (amd64 and arm64) natively via BuildKit pods. +5. Deploy to amd64 first (Kustomize overlay), validate, then migrate to arm64 (overlay) and verify. +6. Automate builds and rollouts with Cloud Build and Skaffold. \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/cloud-build.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/cloud-build.md index 711646d61..bfa39c9cb 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/cloud-build.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/cloud-build.md @@ -1,6 +1,6 @@ --- title: Automate builds and rollout with Cloud Build and Skaffold -weight: 6 +weight: 7 ### FIXED, DO NOT MODIFY layout: learningpathall diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-build-push.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-build-push.md index f9ba2e79f..1fcf00b8c 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-build-push.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-build-push.md @@ -1,6 +1,6 @@ --- title: Provision a dual-architecture GKE cluster and publish images -weight: 4 +weight: 5 ### FIXED, DO NOT MODIFY layout: learningpathall diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md index 6dc0e4b53..542c37bf5 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md @@ -1,6 +1,6 @@ --- title: Prepare manifests and deploy on GKE -weight: 5 +weight: 6 ### FIXED, DO NOT MODIFY layout: learningpathall diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/multi-arch-images.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/multi-arch-images.md index c1e6a3dd0..2d41283cf 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/multi-arch-images.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/multi-arch-images.md @@ -1,6 +1,6 @@ --- title: Create build-ready Dockerfiles for both architectures -weight: 3 +weight: 4 ### FIXED, DO NOT MODIFY layout: learningpathall diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md index 635930445..c35a00f31 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md @@ -2,7 +2,7 @@ # User change title: "Overview and Environment Setup" -weight: 2 # 1 is first, 2 is second, etc. +weight: 3 # 1 is first, 2 is second, etc. # Do not modify these elements layout: "learningpathall" From 818bd5454019ca42cee5550402f5ffe1d20daeba Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Mon, 10 Nov 2025 15:13:37 +0000 Subject: [PATCH 2/6] Update titles in background and project setup documentation --- .../gke-multi-arch-axion/background.md | 2 +- .../gke-multi-arch-axion/project-setup.md | 43 +------------------ 2 files changed, 3 insertions(+), 42 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md index 6d5018618..b440c1063 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md @@ -1,6 +1,6 @@ --- # User change -title: "Overview and Environment Setup" +title: "Overview" weight: 2 # 1 is first, 2 is second, etc. diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md index c35a00f31..a25872375 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md @@ -1,6 +1,6 @@ --- # User change -title: "Overview and Environment Setup" +title: "Set up your environment" weight: 3 # 1 is first, 2 is second, etc. @@ -8,45 +8,6 @@ weight: 3 # 1 is first, 2 is second, etc. layout: "learningpathall" --- -This Learning Path demonstrates how to migrate a real microservices application from x86 to Arm (amd64 to arm64) on GKE using multi-architecture container images. The sample application is Google's Online Boutique, a polyglot microservices system that mirrors production architectures and ships with Dockerfiles. It's a realistic, real-world scenario, and the migration can be done with no major code changes. - -## Why Google Axion processors for GKE? - -Google Axion processors bring modern Arm-based compute to GKE, delivering strong price-performance and energy efficiency for cloud-native, scale-out services. With multi-architecture images and mixed node pools, services can migrate from x86 to Arm gradually, with no major code changes. - -### What is Google Axion? - -[Google Axion](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) is Google Cloud's Arm-based CPU family built on Arm Neoverse, designed for general-purpose, cloud-native services and CPU-based AI. Typical workloads include web apps and web servers, containerized microservices, open-source databases, in-memory caches, data analytics, media processing, and CPU-based AI inference and data processing. On GKE, Axion powers the C4A and N4A VM families and is paired with Google's Titanium offloads to free CPU cycles for application work. - -### Why migrate to Arm on GKE? - -There are three factors motivating the move to Google Axion processors: - -- **Price-performance:** run more workload per dollar for scale-out services -- **Energy efficiency:** reduce power usage for always-on microservices -- **Compatibility:** containerized apps typically migrate with build/deploy changes, and don't require code rewrites - -### About the Online Boutique sample application - -[Online Boutique](https://github.com/GoogleCloudPlatform/microservices-demo) is a polyglot microservices storefront, complete with shopping cart, checkout, catalog, ads, and recommendations. It's implemented in Go, Java, Python, .NET, and Node.js, with ready-to-use Dockerfiles and Kubernetes manifests. It's a realistic example for demonstrating an x86 to Arm migration with minimal code changes. - -### Multi-architecture on GKE (pragmatic path) - -This Learning Path presents a pragmatic migration approach that builds both amd64 and arm64 images using Docker Buildx with a Kubernetes driver, where builds run natively inside BuildKit pods on your GKE node pools without requiring QEMU emulation. You'll add an Arm node pool alongside existing x86 nodes, then use node selectors and affinity rules to control placement and migrate safely, service by service. - -### How this Learning Path demonstrates the migration - -You'll migrate the Online Boutique application from x86 to Arm using a practical, low-risk approach that leverages multi-architecture container images and mixed node pools. This allows you to validate each service on Arm before fully committing to the migration, ensuring compatibility and performance meet your requirements. - -The steps below outline the migration process: - -1. Open Google Cloud Shell and set the environment variables. -2. Enable required APIs, create an Artifact Registry repository, and authenticate Docker. -3. Create a GKE Standard cluster with an amd64 node pool and add an arm64 (Axion-based C4A) node pool. -4. Create a Buildx (Kubernetes driver) builder that targets both pools, then build and push multi-architecture images (amd64 and arm64) natively via BuildKit pods. -5. Deploy to amd64 first (Kustomize overlay), validate, then migrate to arm64 (overlay) and verify. -6. Automate builds and rollouts with Cloud Build and Skaffold. - ## Get started in Cloud Shell Use [Cloud Shell](https://cloud.google.com/shell/docs/using-cloud-shell) to set variables, enable APIs, create Artifact Registry, authenticate Docker, and clone the sample microservices demo. @@ -57,7 +18,7 @@ Make sure `kubectl`, `gcloud`, `docker`, and `git` commands are installed. You can use your local macOS or Linux computer instead of Cloud Shell. Make sure the required software is installed. {{% /notice %}} -### Set environment variables +## Set environment variables Run the following commands in your terminal to set the project, region/zone, cluster, and Artifact Registry variables: From d0c1f05862b15e8acba5e333b22e9abbdb88d053 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Mon, 10 Nov 2025 16:42:30 +0000 Subject: [PATCH 3/6] Refine content and structure in GKE multi-arch Axion learning path documentation --- .../gke-multi-arch-axion/background.md | 42 +++++++++---------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md index b440c1063..b46d0d44e 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md @@ -2,47 +2,47 @@ # User change title: "Overview" -weight: 2 # 1 is first, 2 is second, etc. +weight: 2 # Do not modify these elements layout: "learningpathall" --- -This Learning Path demonstrates how to migrate a real microservices application from x86 to Arm (amd64 to arm64) on GKE using multi-architecture container images. The sample application is Google's Online Boutique, a polyglot microservices system that mirrors production architectures and ships with Dockerfiles. It's a realistic, real-world scenario, and the migration can be done with no major code changes. +This Learning Path shows you how to migrate a real microservices application from x86 to Arm on GKE using multi-architecture container images. You'll work with Google's Online Boutique, a sample application built with multiple programming languages that represents real production architectures. The migration requires no major code changes, making it a practical example of moving to Arm-based Google Axion processors. -## Why Google Axion processors for GKE? +## Why use Google Axion processors for GKE? -Google Axion processors bring modern Arm-based compute to GKE, delivering strong price-performance and energy efficiency for cloud-native, scale-out services. With multi-architecture images and mixed node pools, services can migrate from x86 to Arm gradually, with no major code changes. +Google Axion processors bring modern Arm-based compute to GKE, delivering strong price-performance and energy efficiency for cloud-native, scale-out services. With multi-architecture images and mixed node pools, you can migrate services from x86 to Arm gradually, with no major code changes. ### What is Google Axion? -[Google Axion](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) is Google Cloud's Arm-based CPU family built on Arm Neoverse, designed for general-purpose, cloud-native services and CPU-based AI. Typical workloads include web apps and web servers, containerized microservices, open-source databases, in-memory caches, data analytics, media processing, and CPU-based AI inference and data processing. On GKE, Axion powers the C4A and N4A VM families and is paired with Google's Titanium offloads to free CPU cycles for application work. +[Google Axion](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) is Google Cloud's Arm-based CPU family built on Arm Neoverse, for general-purpose, cloud-native services and CPU-based AI. Deploy it for workloads like web apps and web servers, containerized microservices, open-source databases, in-memory caches, data analytics, media processing, and CPU-based AI inference and data processing. On GKE, leverage Axion through the C4A and N4A VM families, paired with Google's Titanium offloads to free CPU cycles for application work. ### Why migrate to Arm on GKE? -There are three factors motivating the move to Google Axion processors: +Consider three factors when evaluating Google Axion processors: -- **Price-performance:** run more workload per dollar for scale-out services -- **Energy efficiency:** reduce power usage for always-on microservices -- **Compatibility:** containerized apps typically migrate with build/deploy changes, and don't require code rewrites +- Price-performance: you can run more workload per unit of cost for scale-out services +- Energy efficiency: you can reduce power usage for always-on microservices +- Compatibility: migrate containerized apps with build and deploy changes only—no code rewrites required -### About the Online Boutique sample application +## Learn about the Online Boutique sample application [Online Boutique](https://github.com/GoogleCloudPlatform/microservices-demo) is a polyglot microservices storefront, complete with shopping cart, checkout, catalog, ads, and recommendations. It's implemented in Go, Java, Python, .NET, and Node.js, with ready-to-use Dockerfiles and Kubernetes manifests. It's a realistic example for demonstrating an x86 to Arm migration with minimal code changes. -### Multi-architecture on GKE (pragmatic path) +## Multi-architecture on GKE (pragmatic path) -This Learning Path presents a pragmatic migration approach that builds both amd64 and arm64 images using Docker Buildx with a Kubernetes driver, where builds run natively inside BuildKit pods on your GKE node pools without requiring QEMU emulation. You'll add an Arm node pool alongside existing x86 nodes, then use node selectors and affinity rules to control placement and migrate safely, service by service. +This Learning Path demonstrates a practical migration approach using Docker Buildx with a Kubernetes driver. Your builds run natively inside BuildKit pods on GKE node pools—no QEMU emulation needed. You'll add an Arm node pool alongside your existing x86 nodes, then use node selectors and affinity rules to control where services run. This lets you migrate safely, one service at a time. -### How this Learning Path demonstrates the migration +## How this Learning Path demonstrates migration -You'll migrate the Online Boutique application from x86 to Arm using a practical, low-risk approach that leverages multi-architecture container images and mixed node pools. This allows you to validate each service on Arm before fully committing to the migration, ensuring compatibility and performance meet your requirements. +You'll migrate the Online Boutique application from x86 to Arm step by step. You'll build multi-architecture container images and use mixed node pools, so you can test each service on Arm before you fully commit to the migration. -The steps below outline the migration process: +The migration process involves these steps: -1. Open Google Cloud Shell and set the environment variables. -2. Enable required APIs, create an Artifact Registry repository, and authenticate Docker. -3. Create a GKE Standard cluster with an amd64 node pool and add an arm64 (Axion-based C4A) node pool. -4. Create a Buildx (Kubernetes driver) builder that targets both pools, then build and push multi-architecture images (amd64 and arm64) natively via BuildKit pods. -5. Deploy to amd64 first (Kustomize overlay), validate, then migrate to arm64 (overlay) and verify. -6. Automate builds and rollouts with Cloud Build and Skaffold. \ No newline at end of file +- Open Google Cloud Shell and set the environment variables. +- Enable required APIs, create an Artifact Registry repository, and authenticate Docker. +- Create a GKE Standard cluster with an amd64 node pool and add an arm64 (Axion-based C4A) node pool. +- Create a Buildx (Kubernetes driver) builder that targets both pools, then build and push multi-architecture images (amd64 and arm64) natively using BuildKit pods. +- Deploy to amd64 first (Kustomize overlay), validate, then migrate to arm64 (overlay) and verify. +- Automate builds and rollouts with Cloud Build and Skaffold. \ No newline at end of file From d2ad4ff4ff245eccd96b33eebee29a31a769ff6a Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Mon, 10 Nov 2025 18:10:29 +0000 Subject: [PATCH 4/6] Updates to GKE Multi-Arch Axion Background --- .../gke-multi-arch-axion/background.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md index b46d0d44e..61fb772d4 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md @@ -1,6 +1,6 @@ --- # User change -title: "Overview" +title: "Explore the benefits of migrating microservices to Arm on GKE" weight: 2 @@ -8,7 +8,10 @@ weight: 2 layout: "learningpathall" --- -This Learning Path shows you how to migrate a real microservices application from x86 to Arm on GKE using multi-architecture container images. You'll work with Google's Online Boutique, a sample application built with multiple programming languages that represents real production architectures. The migration requires no major code changes, making it a practical example of moving to Arm-based Google Axion processors. +## Overview + +This Learning Path shows you how to migrate a microservices application from x86 to Arm on GKE using multi-architecture container images. You'll work with Google's Online Boutique, a sample application built with multiple programming languages. The migration requires no code changes, making it a straightforward example of moving to Arm-based Google Axion processors. + ## Why use Google Axion processors for GKE? @@ -16,15 +19,15 @@ Google Axion processors bring modern Arm-based compute to GKE, delivering strong ### What is Google Axion? -[Google Axion](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) is Google Cloud's Arm-based CPU family built on Arm Neoverse, for general-purpose, cloud-native services and CPU-based AI. Deploy it for workloads like web apps and web servers, containerized microservices, open-source databases, in-memory caches, data analytics, media processing, and CPU-based AI inference and data processing. On GKE, leverage Axion through the C4A and N4A VM families, paired with Google's Titanium offloads to free CPU cycles for application work. +[Google Axion](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) is Google Cloud's Arm-based CPU family built on Arm Neoverse, for general-purpose, cloud-native services and CPU-based AI. You can deploy it for workloads like web apps and web servers, containerized microservices, open-source databases, in-memory caches, data analytics, media processing, and CPU-based AI inference and data processing. On GKE, you can leverage Axion through the C4A and N4A VM families, paired with Google's Titanium offloads to free CPU cycles for application work. ### Why migrate to Arm on GKE? +There are three clear benefits to consider when considerring migrating to Arm on GKE: -Consider three factors when evaluating Google Axion processors: -- Price-performance: you can run more workload per unit of cost for scale-out services -- Energy efficiency: you can reduce power usage for always-on microservices -- Compatibility: migrate containerized apps with build and deploy changes only—no code rewrites required +- Price-performance: you can run more workload per unit of cost, which is particularly valuable for scale-out services that need to handle increasing traffic efficiently. +- Energy efficiency: you reduce power usage for always-on microservices, lowering both operational costs and environmental impact. +- Compatibility: you can migrate containerized applications with build and deploy changes only—no code rewrites are required, making the transition straightforward. ## Learn about the Online Boutique sample application From 145ed0a01b14eb83f2547546150a2ca7b32c4ff9 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Mon, 10 Nov 2025 19:19:44 +0000 Subject: [PATCH 5/6] Update title and enhance overview in GKE multi-arch Axion documentation --- .../gke-multi-arch-axion/gke-deploy.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md index 542c37bf5..7859b72e8 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md @@ -12,7 +12,7 @@ You'll now configure the application manifests to use your Artifact Registry ima Replace sample image references with your Artifact Registry path and tag, then create Kustomize overlays to select nodes by architecture. -### Point base manifests at your images +## Point base manifests at your images Replace the image references with your references: @@ -29,7 +29,10 @@ find kustomize/base -name "*.yaml" -type f -exec \ grep -r "${GAR}" kustomize/base/ || true ``` -### Create node-selector overlays +You’ve updated your deployment manifests to reference your own Artifact Registry images. This ensures your application uses the multi-architecture containers you built for Arm and x86. + + +## Create node-selector overlays Create node-selector overlays for targeting specific architectures. @@ -79,7 +82,7 @@ cat << 'EOF' > kustomize/overlays/arm64/node-selector.yaml EOF ``` -You now have updated manifests that reference your container images and Kustomize overlays that target specific CPU architectures. +You’ve updated your deployment manifests to reference your own Artifact Registry images. This ensures your application uses the multi-architecture containers you built for Arm and x86. ## Deploy to the x86 (amd64) pool @@ -101,6 +104,8 @@ kubectl get pods -o=custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATU Pods should be scheduled on nodes labeled `kubernetes.io/arch=amd64`. +You’ve deployed your application to the x86 node pool and verified pod placement. This confirms your manifests and overlays work as expected before migrating to Arm. + ## Migrate to the Arm (arm64) pool Apply the arm64 overlay to move workloads: @@ -117,6 +122,8 @@ kubectl get pods -o wide You should see pods now running on nodes where `kubernetes.io/arch=arm64`. +You’ve migrated your workloads to the Arm node pool. Pods now run on Arm-based nodes, demonstrating a successful architecture transition. + ## Verify external access Get the LoadBalancer IP and open the storefront: @@ -138,5 +145,5 @@ Copy the EXTERNAL-IP value and open it in a new browser tab: http:// ``` -The microservices storefront loads, confirming that your application is accessible and functional on the arm64 node pool. +The microservices storefront loads, confirming that your application is accessible and functional on the arm64 node pool. You’re now running a production-ready microservices storefront on Arm-powered GKE infrastructure. From 45d9ebd3d93626b9f38e5b05dfba0e64e8531207 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Mon, 10 Nov 2025 21:40:22 +0000 Subject: [PATCH 6/6] Update GKE multi-arch Axion documentation for clarity and accuracy --- .../gke-multi-arch-axion/_index.md | 4 +- .../gke-multi-arch-axion/background.md | 11 ++-- .../gke-multi-arch-axion/cloud-build.md | 41 ++++++++++-- .../gke-multi-arch-axion/gke-build-push.md | 6 +- .../gke-multi-arch-axion/gke-deploy.md | 8 +-- .../gke-multi-arch-axion/multi-arch-images.md | 64 +++++++++---------- .../gke-multi-arch-axion/project-setup.md | 12 ++-- 7 files changed, 88 insertions(+), 58 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/_index.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/_index.md index dbfdb6c76..9daf5ab6e 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/_index.md @@ -1,5 +1,5 @@ --- -title: Migrate x86 workloads to Arm on GKE with Google Axion +title: Migrate x86 workloads to Arm on Google Kubernetes Engine with Axion processors minutes_to_complete: 90 @@ -36,7 +36,7 @@ tools_software_languages: further_reading: - resource: - title: GKE documentation + title: Google Kubernetes Engine documentation link: https://cloud.google.com/kubernetes-engine/docs type: documentation - resource: diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md index 61fb772d4..0a789888c 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/background.md @@ -10,21 +10,20 @@ layout: "learningpathall" ## Overview -This Learning Path shows you how to migrate a microservices application from x86 to Arm on GKE using multi-architecture container images. You'll work with Google's Online Boutique, a sample application built with multiple programming languages. The migration requires no code changes, making it a straightforward example of moving to Arm-based Google Axion processors. +This Learning Path shows you how to migrate a microservices application from x86 to Arm on Google Kubernetes Engine (GKE) using multi-architecture container images. You'll work with Google's Online Boutique, a sample application built with multiple programming languages. The migration requires no code changes, making it a straightforward example of moving to Arm-based Google Axion processors. ## Why use Google Axion processors for GKE? -Google Axion processors bring modern Arm-based compute to GKE, delivering strong price-performance and energy efficiency for cloud-native, scale-out services. With multi-architecture images and mixed node pools, you can migrate services from x86 to Arm gradually, with no major code changes. +Google Axion processors bring modern Arm-based compute to GKE. You get strong price-performance and energy efficiency for cloud-native, scale-out services. With multi-architecture images and mixed node pools, you can migrate services from x86 to Arm gradually, with no major code changes. -### What is Google Axion? +## What is Google Axion? [Google Axion](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) is Google Cloud's Arm-based CPU family built on Arm Neoverse, for general-purpose, cloud-native services and CPU-based AI. You can deploy it for workloads like web apps and web servers, containerized microservices, open-source databases, in-memory caches, data analytics, media processing, and CPU-based AI inference and data processing. On GKE, you can leverage Axion through the C4A and N4A VM families, paired with Google's Titanium offloads to free CPU cycles for application work. -### Why migrate to Arm on GKE? +## Why migrate to Arm on GKE? There are three clear benefits to consider when considerring migrating to Arm on GKE: - - Price-performance: you can run more workload per unit of cost, which is particularly valuable for scale-out services that need to handle increasing traffic efficiently. - Energy efficiency: you reduce power usage for always-on microservices, lowering both operational costs and environmental impact. - Compatibility: you can migrate containerized applications with build and deploy changes only—no code rewrites are required, making the transition straightforward. @@ -43,7 +42,7 @@ You'll migrate the Online Boutique application from x86 to Arm step by step. You The migration process involves these steps: -- Open Google Cloud Shell and set the environment variables. +- Open Google Cloud Shell and set up the environment variables. - Enable required APIs, create an Artifact Registry repository, and authenticate Docker. - Create a GKE Standard cluster with an amd64 node pool and add an arm64 (Axion-based C4A) node pool. - Create a Buildx (Kubernetes driver) builder that targets both pools, then build and push multi-architecture images (amd64 and arm64) natively using BuildKit pods. diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/cloud-build.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/cloud-build.md index bfa39c9cb..ae4eca35f 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/cloud-build.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/cloud-build.md @@ -6,9 +6,11 @@ weight: 7 layout: learningpathall --- -Google [**Cloud Build**](https://cloud.google.com/build/docs/set-up) is a managed CI/CD service that runs your containerized build and deploy steps in isolated runners. +## Automate the deployment with Cloud Build -In this section, you'll automate the flow you performed manually: build multi-arch images, deploy to GKE on amd64, then migrate to arm64, and print the app's external IP. +Google [Cloud Build](https://cloud.google.com/build/docs/set-up) is a managed CI/CD service that runs your containerized build and deploy steps in isolated runners. + +In this section, you automate the flow you performed manually: build multi-arch images, deploy to GKE on amd64, then migrate to arm64, and print the app's external IP. ## What does this pipeline do? @@ -19,9 +21,8 @@ The pipeline performs the following steps: - Connects to your GKE cluster - Applies the amd64 Kustomize overlay, verifies pods, then applies the arm64 overlay and verifies pods again - Prints the frontend-external LoadBalancer IP at the end - {{% notice Tip %}} -Run this from the microservices-demo repo root in Cloud Shell. Ensure you completed the previous steps. +Run this command from the `microservices-demo` repository root in Cloud Shell. Make sure you've completed the previous steps. {{% /notice %}} ## Grant IAM permission to the Cloud Build service account @@ -110,7 +111,7 @@ YAML This pipeline installs Docker with Buildx in the runner, enables QEMU, builds two services as examples (extend as desired), connects to your cluster, deploys to amd64, verifies, migrates to arm64, verifies, and prints the external IP.  -Run the commands to create the `cloudbuild.yaml` file. +Run the commands to create the `cloudbuild.yaml` file: ```yaml cat > cloudbuild.yaml <<'YAML' @@ -263,3 +264,33 @@ Open http:// in your browser. ``` Open the URL to load the storefront and confirm the full build, deploy, and migrate flow is automated. + +## What you've accomplished + +Congratulations! You've successfully automated the entire build, deploy, and migration workflow using Cloud Build and Skaffold. Your multi-architecture application runs natively on Arm-powered GKE nodes, and you can deploy updates automatically with a single command. + +You've learned how to: + +- Update Dockerfiles to support native builds on both amd64 and arm64 architectures +- Create a dual-architecture GKE cluster with separate node pools for each platform +- Build multi-architecture container images using Docker Buildx with native BuildKit pods +- Deploy applications to amd64 nodes, then migrate them to arm64 nodes using Kustomize overlays +- Automate the entire workflow with Cloud Build and Skaffold for continuous deployment + +## What's next + +Now that you have a working multi-architecture deployment pipeline, you can explore these next steps: + +- Optimize for Arm performance: profile your services on arm64 nodes to identify optimization opportunities. Arm Neoverse processors offer different performance characteristics than x86, so you might discover new ways to improve throughput or reduce latency. + +- Expand your migration: add build steps for the remaining Online Boutique services. You can extend the `cloudbuild.yaml` file to build all services, not just the two examples provided. + +- Implement progressive rollouts: use Skaffold profiles and Cloud Build triggers to set up canary deployments or blue-green deployments across architectures. This lets you test changes on a subset of traffic before rolling out to all users. + +- Monitor architecture-specific metrics: set up monitoring dashboards in Cloud Monitoring to compare performance, resource usage, and cost between amd64 and arm64 deployments. This data helps you make informed decisions about your migration strategy. + +- Explore cost optimization: review your GKE cluster costs and consider rightsizing your node pools. Arm-based C4A instances often provide better price-performance for cloud-native workloads, so you might reduce costs while maintaining or improving performance. + + + + diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-build-push.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-build-push.md index 1fcf00b8c..58336e5d7 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-build-push.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-build-push.md @@ -1,11 +1,13 @@ --- -title: Provision a dual-architecture GKE cluster and publish images +title: Build and deploy multi-architecture images on GKE weight: 5 ### FIXED, DO NOT MODIFY layout: learningpathall --- +## Create a cluster and build the multi-arch images + You are ready to create a GKE cluster with two node pools (amd64 and arm64), then build and push multi-arch images natively on those node pools. Each architecture uses its own BuildKit pod, and no QEMU emulation is required. @@ -40,7 +42,7 @@ This approach prevents users on the default VPC from accidentally setting NETWOR Create a GKE Standard cluster with VPC-native (IP aliasing) enabled and no default node pool. You'll add amd64 and arm64 pools in the next step. -The command below works for both default and custom VPCs. If the NETWORK, SUBNET, and secondary range variables are unset, GKE uses the default VPC and manages ranges automatically. +The command below works for both default and custom VPCs. If the NETWORK, SUBNET, and secondary range variables are unset, GKE uses the default VPC and manages ranges automatically: ```bash # Cluster vars (reuses earlier PROJECT_ID/REGION/ZONE) diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md index 7859b72e8..7ae4235ae 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/gke-deploy.md @@ -5,14 +5,14 @@ weight: 6 ### FIXED, DO NOT MODIFY layout: learningpathall --- +## Prepare deployment manifests -You'll now configure the application manifests to use your Artifact Registry images and create Kustomize overlays for different CPU architectures. This allows you to deploy the same application to both x86 and Arm node pools. +You'll now configure the application manifests to use your Artifact Registry images and create Kustomize overlays for different CPU architectures. This allows you to deploy the same application to both x86 and Arm node pools by replacing sample image references with your Artifact Registry path and tag, then creating overlays to select nodes by architecture. -## Prepare deployment manifests -Replace sample image references with your Artifact Registry path and tag, then create Kustomize overlays to select nodes by architecture. +## Update base manifests to use your images -## Point base manifests at your images +Replace the sample image references in the base manifests with your Artifact Registry path and tag: Replace the image references with your references: diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/multi-arch-images.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/multi-arch-images.md index 2d41283cf..15524a8c2 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/multi-arch-images.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/multi-arch-images.md @@ -6,28 +6,35 @@ weight: 4 layout: learningpathall --- -With your environment set up, you're ready to modify the Online Boutique services to support multi-architecture builds. +## Update Dockerfiles to support multi-architecture builds -You will patch some Dockerfiles so they build cleanly for both architectures. In the next section, you will build and push images using a GKE-native Buildx builder. +Now that your environment set up, you're now ready to modify the Online Boutique services to support multi-architecture builds. + +You will patch some Dockerfiles so they build cleanly for both architectures. ## Services to edit -Most services already build for both architectures. +Most services in Online Boutique already build for both architectures without any changes. -The four listed below need small changes: +Four services need small updates: - emailservice - recommendationservice - loadgenerator - cartservice -These edits don't change application behavior, they only ensure the right compiler headers and runtime libraries are present per architecture. This includes Python native wheels for email/recommendation/loadgen, and system `protoc` for the .NET cartservice. +These edits ensure the correct compiler headers and runtime libraries are present for each architecture. The changes include: + +- Python native wheels for emailservice, recommendationservice, and loadgenerator +- System `protoc` for the .NET cartservice + +These updates don't change application behavior. {{% notice Note %}} Production migrations begin with assessing cross-architecture compatibility for each service (base images, native extensions such as CGO/JNI, platform-specific packages, and CI build targets). This section demonstrates minor Dockerfile edits for four representative services. In the referenced Online Boutique release, the remaining services generally build for both **amd64** and **arm64** without modification. {{% /notice %}} -### Update the emailservice Dockerfile +## Update the emailservice Dockerfile You can review the [emailservice Dockerfile](https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/refs/heads/main/src/emailservice/Dockerfile) before replacing it. @@ -73,21 +80,18 @@ EOF Here is a summary of the changes: -- **BuildKit syntax** unlocks `--mount=type=cache` to speed rebuilds. -- **TARGETPLATFORM** lets Buildx set linux/amd64 vs linux/arm64 explicitly. -- **Dev vs runtime packages:** build stage compiles native wheels; final stage keeps only needed shared libs. -- **`--prefer-binary`** avoids source builds when wheels exist (more reliable across arches). -- **Removed extra `apk update`** since `apk add --no-cache` already avoids stale indexes & caches. +- The updated Dockerfile uses BuildKit syntax to enable cache mounts, which speed up rebuilds. +- The `TARGETPLATFORM` argument allows Buildx to explicitly set the target architecture (either `linux/amd64` or `linux/arm64`). The build follows a two-stage approach: the builder stage compiles native wheels with necessary development packages, while the final runtime stage includes only the required shared libraries. +- The `--prefer-binary` flag helps avoid building from source when pre-built wheels are available, making builds more reliable across architectures. The update also removes the extra `apk update` command because `apk add --no-cache` already handles index updates without creating a cache. -## Apply updates to the other three services +## Apply updates to recommendationservice, loadgenerator, and cartservice Run the following sed commands to automatically patch the remaining Dockerfiles. ### Update the recommendationservice Dockerfile +You can review the [recommendationservice Dockerfile](https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/refs/heads/main/src/recommendationservice/Dockerfile) before modifying it. -You can review the [recommendationservice Dockerfile](https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/refs/heads/main/src/recommendationservice/Dockerfile) before modifying it. - -Paste the command below to your terminal to update the file with the required multi-architecture changes. +Run the following command to update the file with the required multi-architecture changes: ```bash sed -i \ @@ -101,17 +105,13 @@ sed -i \ src/recommendationservice/Dockerfile ``` -Here is a summary of the changes: - -- Make the base image architecture-aware -- Let native wheels build cleanly -- Keep the runtime slim & predictable +The three key changes are to make the base image architecture-aware, let native wheels build cleanly, and keep the runtime slim and predictable. ### Update loadgenerator Dockerfile You can review the [loadgenerator Dockerfile](https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/refs/heads/main/src/loadgenerator/Dockerfile) before modifying it. -Paste the command below to your terminal to run `sed` to update the file with the required multi-architecture changes. +Run the following command to update the file with the required multi-architecture changes: ```bash FILE=src/loadgenerator/Dockerfile @@ -135,17 +135,12 @@ sed -i -E \ "$FILE" ``` -Here is a summary of the changes: - -- Make the base image architecture-aware -- Fix native build/run deps -- Keep runtime lean and no flags/app code changed +The changes focus on three key areas. First, make the base image architecture-aware so it automatically selects the correct variant for your platform. Second, fix native build and runtime dependencies to ensure they match the target architecture. Third, keep the runtime environment lean—you don't need to change any flags or application code. ### Update cartservice Dockerfile You can review the [carkservice Dockerfile](https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/refs/heads/main/src/cartservice/src/Dockerfile) before replacing it. - -Paste the command below to your terminal to update the file with the required multi-architecture changes. +Run the following command to update the file with the required multi-architecture changes: ```bash FILE=src/cartservice/src/Dockerfile @@ -164,14 +159,17 @@ sed -i \ Here is a summary of the changes: -- Install the system `protoc` command -- Force MSBuild to use the supplied `protoc` command -- No behavioral changes +- Install the system `protoc` compiler in the builder image +- Configure MSBuild to use the installed `protoc` instead of downloading one + +These changes don't affect application behavior. {{% notice Note %}} -`ARG TARGETPLATFORM` + `FROM --platform=$TARGETPLATFORM` is not strictly required if you always build with --platform and your base image is multi-arch. Keeping it is good practice and makes intent explicit and does not change runtime behavior. +Using `ARG TARGETPLATFORM` and `FROM --platform=$TARGETPLATFORM` isn't strictly required when you build with `--platform` and your base image supports multiple architectures. However, keeping these declarations makes your build intent explicit and doesn't change runtime behavior. {{% /notice %}} -After making the Dockerfile modification, all services now support multi-architecture builds. +After updating these Dockerfiles, all services support multi-architecture builds. You're ready to build and push images using a GKE-native Buildx builder. Great job! + + diff --git a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md index a25872375..add9c84ef 100644 --- a/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md +++ b/content/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/project-setup.md @@ -10,9 +10,9 @@ layout: "learningpathall" ## Get started in Cloud Shell -Use [Cloud Shell](https://cloud.google.com/shell/docs/using-cloud-shell) to set variables, enable APIs, create Artifact Registry, authenticate Docker, and clone the sample microservices demo. +You can use [Cloud Shell](https://cloud.google.com/shell/docs/using-cloud-shell) to set variables, enable APIs, create Artifact Registry, authenticate Docker, and clone the sample microservices demo. -Make sure `kubectl`, `gcloud`, `docker`, and `git` commands are installed. +Make sure you have the following tools installed: `kubectl`, `gcloud`, `docker`, and `git`. {{% notice Note %}} You can use your local macOS or Linux computer instead of Cloud Shell. Make sure the required software is installed. @@ -41,7 +41,7 @@ gcloud config set compute/zone "${ZONE}" You'll need the environment variables in any shell you use to work on the project. -### Enable required Google Cloud APIs +## Enable the required Google Cloud APIs Enable the required APIs so the project can create GKE clusters, push and pull container images in Artifact Registry, and use Cloud Build for CI/CD: @@ -49,7 +49,7 @@ Enable the required APIs so the project can create GKE clusters, push and pull c gcloud services enable container.googleapis.com artifactregistry.googleapis.com cloudbuild.googleapis.com ``` -### Create an Artifact Registry (Docker) repository +## Create an Artifact Registry (Docker) repository Create a Docker repository in Artifact Registry in this region for pushing and pulling your multi-architecture images: @@ -57,7 +57,7 @@ Create a Docker repository in Artifact Registry in this region for pushing and p gcloud artifacts repositories create "${REPO}" --repository-format=docker --location="${REGION}" --description="Multi-arch images for microservices demo" ``` -### Authenticate Docker to Artifact Registry +## Authenticate Docker to Artifact Registry Authenticate Docker to Artifact Registry so you can push and pull images: @@ -65,7 +65,7 @@ Authenticate Docker to Artifact Registry so you can push and pull images: gcloud auth configure-docker "${REGION}-docker.pkg.dev" ``` -### Clone the Online Boutique sample microservices application +## Clone the Online Boutique sample microservices application Clone the sample application repository: