Deploy Helm on Google Cloud C4A (Arm-based Axion VMs)

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"
+---

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.
+---

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/).

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.

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