diff --git a/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/_index.md b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/_index.md new file mode 100644 index 0000000000..67a2bc5e16 --- /dev/null +++ b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/_index.md @@ -0,0 +1,60 @@ +--- +title: Deploy Helm on Google Cloud C4A (Arm-based Axion VMs) + +minutes_to_complete: 30 + +who_is_this_for: This learning path is intended for software developers deploying and optimizing Helm on Linux/Arm64 environments, specifically using Google Cloud C4A virtual machines powered by Axion processors. + +learning_objectives: + - Provision an Arm-based SUSE SLES virtual machine on Google Cloud (C4A with Axion processors) + - Install Helm and kubectl on a SUSE Arm64 (C4A) instance + - Create and validate a local Kubernetes cluster (KinD) on Arm64 + - Verify Helm functionality by performing install, upgrade, and uninstall workflows + - Benchmark Helm concurrency behavior using parallel Helm CLI operations on Arm64 + +prerequisites: + - A [Google Cloud Platform (GCP)](https://cloud.google.com/free) account with billing enabled + - Basic familiarity with [Kubernetes concepts](https://kubernetes.io/docs/concepts/) + - Basic understanding of [Helm](https://helm.sh/docs/topics/architecture/) and Kubernetes manifests + +author: Pareena Verma + +##### Tags +skilllevels: Introductory +subjects: Containers and Virtualization +cloud_service_providers: Google Cloud + +armips: + - Neoverse + +tools_software_languages: + - Helm + - Kubernetes + - KinD + +operatingsystems: + - Linux + +# ================================================================================ +# FIXED, DO NOT MODIFY +# ================================================================================ +further_reading: + - resource: + title: Google Cloud documentation + link: https://cloud.google.com/docs + type: documentation + + - resource: + title: Helm documentation + link: https://helm.sh/docs/ + type: documentation + + - resource: + title: Kubernetes documentation + link: https://kubernetes.io/docs/ + type: documentation + +weight: 1 +layout: "learningpathall" +learning_path_main_page: "yes" +--- diff --git a/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/_next-steps.md b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/_next-steps.md new file mode 100644 index 0000000000..c3db0de5a2 --- /dev/null +++ b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/_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. +--- diff --git a/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/background.md b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/background.md new file mode 100644 index 0000000000..92424cf680 --- /dev/null +++ b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/background.md @@ -0,0 +1,27 @@ +--- +title: Getting started with Helm on Google Axion C4A (Arm Neoverse-V2) + +weight: 2 + +layout: "learningpathall" +--- + +## Google Axion C4A Arm instances in Google Cloud + +Google Axion C4A is a family of Arm-based virtual machines built on Google’s custom Axion CPU, which is based on Arm Neoverse-V2 cores. Designed for high-performance and energy-efficient computing, these virtual machines offer strong performance for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications. + +The C4A series provides a cost-effective alternative to x86 virtual machines while leveraging the scalability and performance benefits of the Arm architecture in Google Cloud. + +To learn more about Google Axion, refer to the [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) blog. + +## Helm + +Helm is the package manager for Kubernetes that simplifies application deployment, upgrades, rollbacks, and lifecycle management using reusable **charts**. + +It allows teams to deploy applications consistently across environments and automate Kubernetes workflows. + +Helm runs as a lightweight CLI and integrates directly with the Kubernetes API, making it well-suited for Arm-based platforms such as Google Axion C4A. + +It works efficiently on both x86 and Arm64 architectures and is widely used in production Kubernetes environments. + +Learn more at the official [Helm website](https://helm.sh/). diff --git a/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/baseline.md b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/baseline.md new file mode 100644 index 0000000000..ec04fd7453 --- /dev/null +++ b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/baseline.md @@ -0,0 +1,119 @@ +--- +title: Helm Baseline Testing on Google Axion C4A Arm Virtual Machine +weight: 5 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Helm Baseline Testing on GCP SUSE VMs +This guide walks you through baseline testing to confirm that Helm works correctly on an Arm64-based Kubernetes cluster by validating core workflows such as install, upgrade, and uninstall. + +### Add Helm Repository +Add the Bitnami Helm chart repository and update the local index: + +```console +helm repo add bitnami https://charts.bitnami.com/bitnami +helm repo update +``` + +You should see an output similar to: +```output +"bitnami" has been added to your repositories +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "bitnami" chart repository +Update Complete. ⎈Happy Helming!⎈ +``` + +### Install a Sample Application +Install a sample NGINX application using a Helm chart: + +```console +helm install nginx bitnami/nginx +``` +Deploy a simple test app to validate that Helm can create releases on the cluster. + +You should see an output similar to: +```output +NAME: nginx +LAST DEPLOYED: Wed Dec 3 07:34:04 2025 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +TEST SUITE: None +NOTES: +CHART NAME: nginx +CHART VERSION: 22.3.3 +APP VERSION: 1.29.3 +``` + + +### Validate Deployment +Verify that the Helm release is created: + +```console +helm list +``` + +Confirm Helm recorded the release and that the deployment exists. + +You should see an output similar to: +```output +NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION +nginx default 1 2025-12-03 08:02:21.533232677 +0000 UTC deployed nginx-22.3.3 1.29.3 +nginx-1 default 1 2025-12-03 05:20:12.871824822 +0000 UTC deployed nginx-22.3.3 1.29.3 +nginx-2 default 1 2025-12-03 05:20:12.844759384 +0000 UTC deployed nginx-22.3.3 1.29.3 +nginx-3 default 1 2025-12-03 05:20:13.154627899 +0000 UTC deployed nginx-22.3.3 1.29.3 +nginx-4 default 1 2025-12-03 05:20:12.874546176 +0000 UTC deployed nginx-22.3.3 1.29.3 +nginx-5 default 1 2025-12-03 05:20:12.875725062 +0000 UTC deployed nginx-22.3.3 1.29.3 +nginx-bench default 1 2025-12-02 08:45:50.190893813 +0000 UTC deployed nginx-22.3.3 1.29.3 +``` + +Check Kubernetes resources: + +```console +kubectl get pods +kubectl get svc +``` +You should see an output similar to: +```output +NAME READY STATUS RESTARTS AGE +nginx-1-c89c47fc6-vqww4 1/1 Running 0 163m +nginx-2-54f57f5bb9-wf4r7 1/1 Running 0 163m +nginx-3-bfd4cf4f8-q57qq 1/1 Running 0 163m +nginx-4-6c5d9989c5-ld9mk 1/1 Running 0 163m +nginx-5-74b7ccf97b-cfgr7 1/1 Running 0 163m +nginx-7b9564dc4b-92rnd 1/1 Running 0 75s +nginx-bench-c4f66c79c-bhlgl 1/1 Running 1 (3h37m ago) 23h +``` +All pods should be in the **Running** state. + + +### Validate Helm Lifecycle +This step confirms that Helm supports the full application lifecycle on Arm64. + +#### Upgrade the Release + +```console +helm upgrade nginx bitnami/nginx +``` +Test Helm's ability to update an existing release to a new revision. + +You should see an output similar to: +```output +Release "nginx" has been upgraded. Happy Helming! +``` + +#### Uninstall the Release +Ensure Helm can cleanly remove the release and associated resources. + +```console +helm uninstall nginx +``` + +You should see an output similar to: +```output +release "nginx" uninstalled +``` +This confirms the successful execution of **install**, **upgrade**, and **delete** workflows using Helm on Arm64. +Helm is fully functional on the Arm64 Kubernetes cluster and ready for further experimentation or benchmarking. diff --git a/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/benchmarking.md b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/benchmarking.md new file mode 100644 index 0000000000..6aeb64ee1f --- /dev/null +++ b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/benchmarking.md @@ -0,0 +1,173 @@ +--- +title: Helm Benchmarking +weight: 6 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + + +## Helm Benchmark on GCP SUSE Arm64 VM +This guide explains **how to benchmark Helm on an Arm64-based GCP SUSE VM** using only the **Helm CLI**. +Since Helm does not provide built-in performance metrics, we measure **concurrency behavior** by running multiple Helm commands in parallel and recording the total execution time. + +### Prerequisites +Before starting the benchmark, ensure Helm is installed and the Kubernetes cluster is accessible. + +```console +helm version +kubectl get nodes +``` + +All nodes should be in `Ready` state. + + +### Add Helm Repository +Helm installs applications using “charts.” +This step tells Helm where to download those charts from and updates its local chart list. + +```console +helm repo add bitnami https://charts.bitnami.com/bitnami +helm repo update +``` + +### Create Benchmark Namespace +Isolate benchmark workloads from other cluster resources. + +```console +kubectl create namespace helm-bench +``` + +### Warm-Up Run (Recommended) +This step prepares the cluster by pulling container images and initializing caches. + +```console +helm install warmup bitnami/nginx \ + -n helm-bench \ + --set service.type=ClusterIP \ + --timeout 10m +``` +The first install is usually slower because of following reasons: + +- Images must be downloaded. +- Kubernetes initializes internal objects. + +This warm-up ensures the real benchmark measures Helm performance, not setup overhead. + +**After validation, remove the warm-up deployment:** + +```console +helm uninstall warmup -n helm-bench +``` + +{{% notice Note %}} +Helm does not provide native concurrency or throughput metrics. Concurrency benchmarking is performed by executing multiple Helm CLI operations in parallel and measuring overall completion time. +{{% /notice %}} + +### Concurrent Helm Install Benchmark (No Wait) +Run multiple Helm installs in parallel using background jobs. + +```console +time ( +for i in {1..5}; do + helm install nginx-$i bitnami/nginx \ + -n helm-bench \ + --set service.type=ClusterIP \ + --timeout 10m & +done +wait +) +``` +This step simulates multiple teams deploying applications at the same time. +Helm submits all requests without waiting for pods to fully start. + +What this measures: + +* Helm concurrency handling +* Kubernetes API responsiveness +* Arm64 client-side performance + +You should see an output similar to: +```output +real 0m4.109s +user 0m12.178s +sys 0m0.470s +``` + +### Verify Deployments + +This confirms: + +- Helm reports that all components were installed successfully +- Kubernetes actually created and started the applications + +```console +helm list -n helm-bench +kubectl get pods -n helm-bench +``` + +Expected: + +* All releases in `deployed` state +* Pods in `Running` status + +### Concurrent Helm Install Benchmark (With `--wait`) +This benchmark includes workload readiness time. + +```console +time ( +for i in {1..3}; do + helm install nginx-wait-$i bitnami/nginx \ + -n helm-bench \ + --set service.type=ClusterIP \ + --wait \ + --timeout 15m & +done +wait +) +``` + +What this measures: + +* Helm concurrency plus scheduler and image-pull contention +* End-to-end readiness impact + +You should see an output similar to: +```output +WARNING: There are "resources" sections in the chart not set. Using "resourcesPreset" is not recommended for production. +For production installations, please set the following values according to your workload needs: - cloneStaticSiteFromGit.gitSync.resources - resources +info https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ +real 0m12.758s +user 0m7.360s +sys 0m0.227s +``` + +### Metrics to Record + +- **Total elapsed time**: Overall time taken to complete all installs. +- **Number of parallel installs**: Number of Helm installs run at the same time. +- **Failures**: Any Helm failures or Kubernetes API errors. +- **Pod readiness delay**: Time pods take to become Ready (resource pressure) + +### Benchmark summary on x86_64 +To compare the benchmark results, the following results were collected by running the same benchmark on an `x86 - c4-standard-4` (4 vCPUs, 15 GB Memory) x86_64 VM in GCP, running SUSE: + +| Test Case | Parallel Installs | `--wait` Used | Timeout | Total Time (real) | +| ---------------------------- | ----------------- | ------------- | ------- | ----------------- | +| Parallel Install (No Wait) | 5 | No | 10m | **6.06 s** | +| Parallel Install (With Wait) | 3 | Yes | 15m | **14.41 s** | + + +### Benchmark summary on Arm64 +Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE): + +| Test Case | Parallel Installs | `--wait` Used | Timeout | Total Time (real) | +| ---------------------------- | ----------------- | ------------- | ------- | ----------------- | +| Parallel Install (No Wait) | 5 | No | 10m | **4.11 s** | +| Parallel Install (With Wait) | 3 | Yes | 15m | **12.76 s** | + +### Helm Benchmark comparison insights + +- **Arm64 shows faster Helm execution** for both warm and ready states, indicating efficient CLI and Kubernetes API handling on Arm-based GCP instances. +- **The `--wait` flag significantly increases total execution time** because Helm waits for pods and services to reach a Ready state, revealing scheduler latency and image-pull delays rather than Helm CLI overhead. +- **Parallel Helm installs scale well on Arm64**, with minimal contention observed even at higher concurrency levels. +- **End-to-end workload readiness dominates benchmark results**, showing that cluster resource availability and container image pulls diff --git a/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/images/gcp-vm.png b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/images/gcp-vm.png new file mode 100644 index 0000000000..0d1072e20d Binary files /dev/null and b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/images/gcp-vm.png differ diff --git a/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/installtion.md b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/installtion.md new file mode 100644 index 0000000000..2de515dd3c --- /dev/null +++ b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/installtion.md @@ -0,0 +1,93 @@ +--- +title: Install Helm +weight: 4 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Install Helm on GCP VM +This section covers preparing a SUSE Arm64 system and installing the required tools to work with Helm using a local Kubernetes cluster created with KinD. + +### System Preparation +Update the system and install basic dependencies: + +```console +sudo zypper refresh +sudo zypper update -y +sudo zypper install -y curl git tar gzip +``` +### Install kubectl +This step installs kubectl, the command-line tool used to interact with Kubernetes clusters, compiled for the Arm64 architecture. + +```console +curl -LO https://dl.k8s.io/release/v1.30.1/bin/linux/arm64/kubectl +chmod +x kubectl +sudo mv kubectl /usr/local/bin/ +``` + +### Verify Installation + +This step confirms that `kubectl` is installed correctly and accessible from the command line. + +```console +kubectl version --client +``` + +You should see an output similar to: +```output +Client Version: v1.30.1 +Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 +``` + +### Install Helm +This step installs Helm using the official Helm installation script, ensuring you get a verified and up-to-date release. + +```console +curl -sSfL https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | console +``` + +### Verify Installation +This step confirms that Helm is installed correctly and ready to be used. + +```console +helm version +``` + +You should see an output similar to: +```output +version.BuildInfo{Version:"v3.19.2", GitCommit:"8766e718a0119851f10ddbe4577593a45fadf544", GitTreeState:"clean", GoVersion:"go1.24.9"} +``` + +### Create a Local Kubernetes Cluster (KinD) +This step installs KinD (Kubernetes-in-Docker), which allows you to run a lightweight Kubernetes cluster locally on your Arm64 VM. + +```console +curl -Lo kind https://kind.sigs.k8s.io/dl/v0.30.0/kind-linux-arm64 +chmod +x kind +sudo mv kind /usr/local/bin/ +``` + +**Create a local Kubernetes cluster:** + +This step creates a local Kubernetes cluster named helm-lab that will be used to deploy Helm charts. + +```console +kind create cluster --name helm-lab +``` + +### Verify Cluster Status +This step verifies that the Kubernetes cluster is operating correctly and is fully prepared to run workloads. + +```console +kubectl get nodes +``` + +You should see an output similar to: +```output +NAME STATUS ROLES AGE VERSION +helm-lab-control-plane Ready control-plane 23h v1.34.0 +``` +The node should be in the **Ready** state. + +You now have a fully working local Kubernetes environment on Arm64, ready for deploying applications using Helm. diff --git a/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/instance.md b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/instance.md new file mode 100644 index 0000000000..2b93bc950d --- /dev/null +++ b/content/learning-paths/servers-and-cloud-computing/helm-on-gcp/instance.md @@ -0,0 +1,31 @@ +--- +title: Create a Google Axion C4A Arm virtual machine on GCP +weight: 3 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Overview + +In this section, you will learn how to provision a Google Axion C4A Arm virtual machine on Google Cloud Platform (GCP) using the `c4a-standard-4` (4 vCPUs, 16 GB memory) machine type in the Google Cloud Console. + +{{% notice Note %}} +For support on GCP setup, see the Learning Path [Getting started with Google Cloud Platform](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/google/). +{{% /notice %}} + +## Provision a Google Axion C4A Arm VM in Google Cloud Console + +To create a virtual machine based on the C4A instance type: +- Navigate to the [Google Cloud Console](https://console.cloud.google.com/). +- Go to **Compute Engine > VM Instances** and select **Create Instance**. +- Under **Machine configuration**: + - Populate fields such as **Instance name**, **Region**, and **Zone**. + - Set **Series** to `C4A`. + - Select `c4a-standard-4` for machine type. + + ![Create a Google Axion C4A Arm virtual machine in the Google Cloud Console with c4a-standard-4 selected alt-text#center](images/gcp-vm.png "Creating a Google Axion C4A Arm virtual machine in Google Cloud Console") + +- Under **OS and Storage**, select **Change**, then choose an Arm64-based OS image. For this Learning Path, use **SUSE Linux Enterprise Server**. Pick the preferred version for your Operating System. Ensure you select the **Arm image** variant. Click **Select**. +- Under **Networking**, enable **Allow HTTP traffic**. +- Click **Create** to launch the instance.