Skip to content

Commit d99059d

Browse files
odidevodidev
committed
Deploy Helm on Google Cloud C4A (Arm-based Axion VMs)
Signed-off-by: odidev <[email protected]>
1 parent 438cbab commit d99059d

File tree

8 files changed

+511
-0
lines changed

8 files changed

+511
-0
lines changed

‎content/learning-paths/servers-and-cloud-computing/helm-on-gcp/_index.md‎

Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
---
2+
title: Deploy Helm on Google Cloud C4A (Arm-based Axion VMs)
3+
4+
minutes_to_complete: 30
5+
6+
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.
7+
8+
learning_objectives:
9+
- Provision an Arm-based SUSE SLES virtual machine on Google Cloud (C4A with Axion processors)
10+
- Install Helm and kubectl on a SUSE Arm64 (C4A) instance
11+
- Create and validate a local Kubernetes cluster (KinD) on Arm64
12+
- Verify Helm functionality by performing install, upgrade, and uninstall workflows
13+
- Benchmark Helm concurrency behavior using parallel Helm CLI operations on Arm64
14+
15+
prerequisites:
16+
- A [Google Cloud Platform (GCP)](https://cloud.google.com/free) account with billing enabled
17+
- Basic familiarity with [Kubernetes concepts](https://kubernetes.io/docs/concepts/)
18+
- Basic understanding of [Helm](https://helm.sh/docs/topics/architecture/) and Kubernetes manifests
19+
20+
author: Pareena Verma
21+
22+
##### Tags
23+
skilllevels: Introductory
24+
subjects: Containers and Virtualization
25+
cloud_service_providers: Google Cloud
26+
27+
armips:
28+
- Neoverse
29+
30+
tools_software_languages:
31+
- Helm
32+
- Kubernetes
33+
- KinD
34+
35+
operatingsystems:
36+
- Linux
37+
38+
# ================================================================================
39+
# FIXED, DO NOT MODIFY
40+
# ================================================================================
41+
further_reading:
42+
- resource:
43+
title: Google Cloud documentation
44+
link: https://cloud.google.com/docs
45+
type: documentation
46+
47+
- resource:
48+
title: Helm documentation
49+
link: https://helm.sh/docs/
50+
type: documentation
51+
52+
- resource:
53+
title: Kubernetes documentation
54+
link: https://kubernetes.io/docs/
55+
type: documentation
56+
57+
weight: 1
58+
layout: "learningpathall"
59+
learning_path_main_page: "yes"
60+
---

‎content/learning-paths/servers-and-cloud-computing/helm-on-gcp/_next-steps.md‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
---
2+
# ================================================================================
3+
# FIXED, DO NOT MODIFY THIS FILE
4+
# ================================================================================
5+
weight: 21 # Set to always be larger than the content in this path to be at the end of the navigation.
6+
title: "Next Steps" # Always the same, html page title.
7+
layout: "learningpathall" # All files under learning paths have this same wrapper for Hugo processing.
8+
---

‎content/learning-paths/servers-and-cloud-computing/helm-on-gcp/background.md‎

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
---
2+
title: Getting started with Helm on Google Axion C4A (Arm Neoverse-V2)
3+
4+
weight: 2
5+
6+
layout: "learningpathall"
7+
---
8+
9+
## Google Axion C4A Arm instances in Google Cloud
10+
11+
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.
12+
13+
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.
14+
15+
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.
16+
17+
## Helm
18+
19+
Helm is the package manager for Kubernetes that simplifies application deployment, upgrades, rollbacks, and lifecycle management using reusable **charts**.
20+
21+
It allows teams to deploy applications consistently across environments and automate Kubernetes workflows.
22+
23+
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.
24+
25+
It works efficiently on both x86 and Arm64 architectures and is widely used in production Kubernetes environments.
26+
27+
Learn more at the official [Helm website](https://helm.sh/).

‎content/learning-paths/servers-and-cloud-computing/helm-on-gcp/baseline.md‎

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
---
2+
title: Helm Baseline Testing on Google Axion C4A Arm Virtual Machine
3+
weight: 5
4+
5+
### FIXED, DO NOT MODIFY
6+
layout: learningpathall
7+
---
8+
9+
## Helm Baseline Testing on GCP SUSE VMs
10+
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.
11+
12+
### Add Helm Repository
13+
Add the Bitnami Helm chart repository and update the local index:
14+
15+
```console
16+
helm repo add bitnami https://charts.bitnami.com/bitnami
17+
helm repo update
18+
```
19+
20+
You should see an output similar to:
21+
```output
22+
"bitnami" has been added to your repositories
23+
Hang tight while we grab the latest from your chart repositories...
24+
...Successfully got an update from the "bitnami" chart repository
25+
Update Complete. ⎈Happy Helming!⎈
26+
```
27+
28+
### Install a Sample Application
29+
Install a sample NGINX application using a Helm chart:
30+
31+
```console
32+
helm install nginx bitnami/nginx
33+
```
34+
Deploy a simple test app to validate that Helm can create releases on the cluster.
35+
36+
You should see an output similar to:
37+
```output
38+
NAME: nginx
39+
LAST DEPLOYED: Wed Dec 3 07:34:04 2025
40+
NAMESPACE: default
41+
STATUS: deployed
42+
REVISION: 1
43+
TEST SUITE: None
44+
NOTES:
45+
CHART NAME: nginx
46+
CHART VERSION: 22.3.3
47+
APP VERSION: 1.29.3
48+
```
49+
50+
51+
### Validate Deployment
52+
Verify that the Helm release is created:
53+
54+
```console
55+
helm list
56+
```
57+
58+
Confirm Helm recorded the release and that the deployment exists.
59+
60+
You should see an output similar to:
61+
```output
62+
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
63+
nginx default 1 2025-12-03 08:02:21.533232677 +0000 UTC deployed nginx-22.3.3 1.29.3
64+
nginx-1 default 1 2025-12-03 05:20:12.871824822 +0000 UTC deployed nginx-22.3.3 1.29.3
65+
nginx-2 default 1 2025-12-03 05:20:12.844759384 +0000 UTC deployed nginx-22.3.3 1.29.3
66+
nginx-3 default 1 2025-12-03 05:20:13.154627899 +0000 UTC deployed nginx-22.3.3 1.29.3
67+
nginx-4 default 1 2025-12-03 05:20:12.874546176 +0000 UTC deployed nginx-22.3.3 1.29.3
68+
nginx-5 default 1 2025-12-03 05:20:12.875725062 +0000 UTC deployed nginx-22.3.3 1.29.3
69+
nginx-bench default 1 2025-12-02 08:45:50.190893813 +0000 UTC deployed nginx-22.3.3 1.29.3
70+
```
71+
72+
Check Kubernetes resources:
73+
74+
```console
75+
kubectl get pods
76+
kubectl get svc
77+
```
78+
You should see an output similar to:
79+
```output
80+
NAME READY STATUS RESTARTS AGE
81+
nginx-1-c89c47fc6-vqww4 1/1 Running 0 163m
82+
nginx-2-54f57f5bb9-wf4r7 1/1 Running 0 163m
83+
nginx-3-bfd4cf4f8-q57qq 1/1 Running 0 163m
84+
nginx-4-6c5d9989c5-ld9mk 1/1 Running 0 163m
85+
nginx-5-74b7ccf97b-cfgr7 1/1 Running 0 163m
86+
nginx-7b9564dc4b-92rnd 1/1 Running 0 75s
87+
nginx-bench-c4f66c79c-bhlgl 1/1 Running 1 (3h37m ago) 23h
88+
```
89+
All pods should be in the **Running** state.
90+
91+
92+
### Validate Helm Lifecycle
93+
This step confirms that Helm supports the full application lifecycle on Arm64.
94+
95+
#### Upgrade the Release
96+
97+
```console
98+
helm upgrade nginx bitnami/nginx
99+
```
100+
Test Helm's ability to update an existing release to a new revision.
101+
102+
You should see an output similar to:
103+
```output
104+
Release "nginx" has been upgraded. Happy Helming!
105+
```
106+
107+
#### Uninstall the Release
108+
Ensure Helm can cleanly remove the release and associated resources.
109+
110+
```console
111+
helm uninstall nginx
112+
```
113+
114+
You should see an output similar to:
115+
```output
116+
release "nginx" uninstalled
117+
```
118+
This confirms the successful execution of **install**, **upgrade**, and **delete** workflows using Helm on Arm64.
119+
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‎

Lines changed: 173 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,173 @@
1+
---
2+
title: Helm Benchmarking
3+
weight: 6
4+
5+
### FIXED, DO NOT MODIFY
6+
layout: learningpathall
7+
---
8+
9+
10+
## Helm Benchmark on GCP SUSE Arm64 VM
11+
This guide explains **how to benchmark Helm on an Arm64-based GCP SUSE VM** using only the **Helm CLI**.
12+
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.
13+
14+
### Prerequisites
15+
Before starting the benchmark, ensure Helm is installed and the Kubernetes cluster is accessible.
16+
17+
```console
18+
helm version
19+
kubectl get nodes
20+
```
21+
22+
All nodes should be in `Ready` state.
23+
24+
25+
### Add Helm Repository
26+
Helm installs applications using “charts.”
27+
This step tells Helm where to download those charts from and updates its local chart list.
28+
29+
```console
30+
helm repo add bitnami https://charts.bitnami.com/bitnami
31+
helm repo update
32+
```
33+
34+
### Create Benchmark Namespace
35+
Isolate benchmark workloads from other cluster resources.
36+
37+
```console
38+
kubectl create namespace helm-bench
39+
```
40+
41+
### Warm-Up Run (Recommended)
42+
This step prepares the cluster by pulling container images and initializing caches.
43+
44+
```console
45+
helm install warmup bitnami/nginx \
46+
-n helm-bench \
47+
--set service.type=ClusterIP \
48+
--timeout 10m
49+
```
50+
The first install is usually slower because of following reasons:
51+
52+
- Images must be downloaded.
53+
- Kubernetes initializes internal objects.
54+
55+
This warm-up ensures the real benchmark measures Helm performance, not setup overhead.
56+
57+
**After validation, remove the warm-up deployment:**
58+
59+
```console
60+
helm uninstall warmup -n helm-bench
61+
```
62+
63+
{{% notice Note %}}
64+
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.
65+
{{% /notice %}}
66+
67+
### Concurrent Helm Install Benchmark (No Wait)
68+
Run multiple Helm installs in parallel using background jobs.
69+
70+
```console
71+
time (
72+
for i in {1..5}; do
73+
helm install nginx-$i bitnami/nginx \
74+
-n helm-bench \
75+
--set service.type=ClusterIP \
76+
--timeout 10m &
77+
done
78+
wait
79+
)
80+
```
81+
This step simulates multiple teams deploying applications at the same time.
82+
Helm submits all requests without waiting for pods to fully start.
83+
84+
What this measures:
85+
86+
* Helm concurrency handling
87+
* Kubernetes API responsiveness
88+
* Arm64 client-side performance
89+
90+
You should see an output similar to:
91+
```output
92+
real 0m4.109s
93+
user 0m12.178s
94+
sys 0m0.470s
95+
```
96+
97+
### Verify Deployments
98+
99+
This confirms:
100+
101+
- Helm reports that all components were installed successfully
102+
- Kubernetes actually created and started the applications
103+
104+
```console
105+
helm list -n helm-bench
106+
kubectl get pods -n helm-bench
107+
```
108+
109+
Expected:
110+
111+
* All releases in `deployed` state
112+
* Pods in `Running` status
113+
114+
### Concurrent Helm Install Benchmark (With `--wait`)
115+
This benchmark includes workload readiness time.
116+
117+
```console
118+
time (
119+
for i in {1..3}; do
120+
helm install nginx-wait-$i bitnami/nginx \
121+
-n helm-bench \
122+
--set service.type=ClusterIP \
123+
--wait \
124+
--timeout 15m &
125+
done
126+
wait
127+
)
128+
```
129+
130+
What this measures:
131+
132+
* Helm concurrency plus scheduler and image-pull contention
133+
* End-to-end readiness impact
134+
135+
You should see an output similar to:
136+
```output
137+
WARNING: There are "resources" sections in the chart not set. Using "resourcesPreset" is not recommended for production.
138+
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/
139+
real 0m12.758s
140+
user 0m7.360s
141+
sys 0m0.227s
142+
```
143+
144+
### Metrics to Record
145+
146+
- **Total elapsed time**: Overall time taken to complete all installs.
147+
- **Number of parallel installs**: Number of Helm installs run at the same time.
148+
- **Failures**: Any Helm failures or Kubernetes API errors.
149+
- **Pod readiness delay**: Time pods take to become Ready (resource pressure)
150+
151+
### Benchmark summary on x86_64
152+
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:
153+
154+
| Test Case | Parallel Installs | `--wait` Used | Timeout | Total Time (real) |
155+
| ---------------------------- | ----------------- | ------------- | ------- | ----------------- |
156+
| Parallel Install (No Wait) | 5 | No | 10m | **6.06 s** |
157+
| Parallel Install (With Wait) | 3 | Yes | 15m | **14.41 s** |
158+
159+
160+
### Benchmark summary on Arm64
161+
Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE):
162+
163+
| Test Case | Parallel Installs | `--wait` Used | Timeout | Total Time (real) |
164+
| ---------------------------- | ----------------- | ------------- | ------- | ----------------- |
165+
| Parallel Install (No Wait) | 5 | No | 10m | **4.11 s** |
166+
| Parallel Install (With Wait) | 3 | Yes | 15m | **12.76 s** |
167+
168+
### Helm Benchmark comparison insights
169+
170+
- **Arm64 shows faster Helm execution** for both warm and ready states, indicating efficient CLI and Kubernetes API handling on Arm-based GCP instances.
171+
- **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.
172+
- **Parallel Helm installs scale well on Arm64**, with minimal contention observed even at higher concurrency levels.
173+
- **End-to-end workload readiness dominates benchmark results**, showing that cluster resource availability and container image pulls

‎content/learning-paths/servers-and-cloud-computing/helm-on-gcp/images/gcp-vm.png‎

261 KB
Loading

0 commit comments

Comments
 (0)