Merge pull request #2798 from DougAnsonAustinTX/helm-tech-review-2

Helm LP Review 2

Author: jasonrandrews

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

@@ -4,7 +4,7 @@ title: Install and validate Helm on Google Cloud C4A Arm-based VMs
 draft: true
 cascade:
     draft: true
-
+    
 minutes_to_complete: 60
 
 who_is_this_for: This is an introductory topic intended for developers who want to get hands-on experience using Helm on Linux Arm64 systems, specifically Google Cloud C4A virtual machines powered by Axion processors.

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

@@ -33,18 +33,18 @@ helm install nginx bitnami/nginx
 ```
 Deploy a simple test app to validate that Helm can create releases on the cluster.
 
-The output is similar to the following (warnings can be safely ignored as they don't affect functionality):
+The output is similar to:
 ```output
 NAME: nginx
-LAST DEPLOYED: Wed Dec  3 07:34:04 2025
+LAST DEPLOYED: Thu Jan 15 20:13:37 2026
 NAMESPACE: default
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None
 NOTES:
 CHART NAME: nginx
-CHART VERSION: 22.3.3
-APP VERSION: 1.29.3
+CHART VERSION: 22.4.3
+APP VERSION: 1.29.4
 ```
 
 
@@ -60,7 +60,7 @@ Confirm Helm recorded the release and that the deployment exists.
 The output is similar to:
 ```output
 NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
-nginx   default         1               2025-12-09 21:04:15.944165326 +0000 UTC deployed        nginx-22.3.3    1.29.3 
+nginx   default         1               2026-01-15 20:13:37.325530458 +0000 UTC deployed        nginx-22.4.3    1.29.4     
 ```
 
 Check Kubernetes resources:
@@ -72,13 +72,13 @@ kubectl get svc
 The output is similar to:
 ```output
 NAME                     READY   STATUS    RESTARTS   AGE
-nginx-7b9564dc4b-2ghkw   1/1     Running   0          3m5s
+nginx-6d597599b8-hrn7t   1/1     Running   0          116s
 
-NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
-kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP                      4m28s
-nginx        LoadBalancer   10.96.216.137   <pending>     80:32708/TCP,443:31052/TCP   3m6s
+NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
+kubernetes   ClusterIP      10.96.0.1      <none>        443/TCP                      3m33s
+nginx        LoadBalancer   10.96.88.148   <pending>     80:30166/TCP,443:32128/TCP   117s
 ```
-All pods should be in the **Running** state. If pods are in **Pending** state, wait 30-60 seconds for container images to download, then retry the commands above. 
+All pods should be in the **Running** state. If pods are in **Pending** state, wait 30 to 60 seconds for container images to download, then retry the commands above. 
 
 
 ## Validate Helm lifecycle

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

@@ -13,7 +13,9 @@ Since Helm does not provide built-in performance metrics, concurrency behavior i
 
 ### Prerequisites
 
-{{% notice Note %}} Ensure the local Kubernetes cluster created earlier is running and has sufficient resources to deploy multiple NGINX replicas.{{% /notice %}}
+{{% notice Note %}}
+Ensure the local Kubernetes cluster created earlier is running and has sufficient resources to deploy multiple NGINX replicas.
+{{% /notice %}}
 
 Before starting the benchmark, ensure Helm is installed and the Kubernetes cluster is accessible.
 
@@ -89,11 +91,7 @@ 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
-* Helm CLI client-side execution behavior on Arm64
+This measures Helm concurrency handling, Kubernetes API responsiveness, and Helm CLI client-side execution behavior on Arm64.
 
 You should see an output similar to:
 ```output
@@ -111,10 +109,7 @@ helm list -n helm-bench
 kubectl get pods -n helm-bench
 ```
 
-Expected:
-
-* All releases in `deployed` state
-* Pods in `Running` status
+All releases should be in `deployed` state and pods should be in `Running` status.
 
 ### Concurrent Helm install benchmark (with --wait)
 Run a benchmark that includes workload readiness time.
@@ -143,10 +138,7 @@ sys     0m0.312s
 
 ### 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)
+Record the following metrics: total elapsed time (overall time taken to complete all installs), number of parallel installs, any failures or Kubernetes API errors, and pod readiness delay (time pods take to become Ready under resource pressure).
 
 ### Benchmark summary
 Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE):

content/learning-paths/servers-and-cloud-computing/helm-on-gcp/gke-cluster-for-helm.md

@@ -18,14 +18,7 @@ This setup differs from the earlier KinD-based local cluster, which was intended
 
 ## Prerequisites
 
-Before starting, ensure the following are already completed:
-
-- Docker installed
-- kubectl installed
-- Helm installed
-- Google Cloud account available
-
-If Helm and kubectl are not installed, complete the **Install Helm** section first.
+Before starting, ensure that Docker, kubectl, and Helm are installed, and that you have a Google Cloud account available. If Helm and kubectl aren't installed, complete the **Install Helm** section first.
 
 ### Verify kubectl Installation
 Confirm that kubectl is available:
@@ -35,8 +28,17 @@ kubectl version --client
 ```
 You should see an output similar to:
 ```output
-Client Version: version.Info{Major:"1", Minor:"26+", GitVersion:"v1.26.15-dispatcher", GitCommit:"5490d28d307425a9b05773554bd5c037dbf3d492", GitTreeState:"clean", BuildDate:"2024-04-18T22:39:37Z", GoVersion:"go1.21.9", Compiler:"gc", Platform:"linux/arm64"}
-Kustomize Version: v4.5.7
+Client Version: v1.30.1
+Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
+```
+
+### Install Python 3.11 
+
+Install python3.11:
+
+```bash
+sudo zypper install -y python311
+which python3.11
 ```
 
 ### Install Google Cloud SDK (gcloud)
@@ -54,28 +56,48 @@ tar -xvf google-cloud-sdk-460.0.0-linux-arm.tar.gz
 ```console
 ./google-cloud-sdk/install.sh
 ```
-Restart the shell or reload the environment if prompted.
+
+The shell will exit. Bring up a new SSH Shell:
+```console
+exit
+```
 
 ### Initialize gcloud
 Authenticate and configure the Google Cloud CLI:
 
 ```console
-./google-cloud-sdk/bin/gcloud init
+gcloud init
 ```
 
-During initialization:
+During initialization, select **Login with a new account**. You'll be prompted to use your browser to authenticate to Google and receive an auth code to copy back. Select the project you want to use and choose default settings when unsure.
 
-- Log in using a Google account
-- Select the correct project
-- Choose default settings when unsure
+### Get the list of Google project IDs
+Retrieve the list of project IDs:
 
+```console
+gcloud projects list
+```
+
+The output is similar to:
+
+```output
+PROJECT_ID              NAME             PROJECT_NUMBER
+arm-lp-test             arm-lp-test      834184475014
+```
+
+Note the **PROJECT_ID** for the project you want to set as active for use in the next step. 
 ### Set the Active Project
 Ensure the correct GCP project is selected:
 
 ```console
 gcloud config set project YOUR_PROJECT_ID
 ```
 
+### Install the auth plugin for gcloud
+```console
+gcloud components install gke-gcloud-auth-plugin
+```
+
 ### Enable Kubernetes API
 Enable the required API for GKE:
 
@@ -84,18 +106,17 @@ gcloud services enable container.googleapis.com
 ```
 
 ### Create a GKE Cluster
-Create a Kubernetes cluster that will host Helm deployments.
+Create a Kubernetes cluster to host Helm deployments. Replace `YOUR_PROJECT_ID` with the project ID you set previously.
 
 ```console
 gcloud container clusters create helm-arm64-cluster \
   --zone us-central1-a \
   --machine-type c4a-standard-4 \
-  --num-nodes 2
+  --num-nodes 2 \
+  --no-enable-ip-alias
 ```
 
-- This creates a standard GKE cluster
-- Node count and machine type can be adjusted later
-- Arm64 compatibility depends on available node types in the region
+This creates a standard GKE cluster. You can adjust the node count and machine type later as needed.
 
 ### Configure kubectl Access to GKE
 Fetch cluster credentials:
@@ -119,16 +140,11 @@ gke-helm-arm64-cluster-default-pool-f4ab8a2d-5h6f   Ready    <none>   5h54m   v1
 gke-helm-arm64-cluster-default-pool-f4ab8a2d-5ldp   Ready    <none>   5h54m   v1.33.5-gke.1308000
 ```
 
-- Nodes in Ready state
-- Kubernetes control plane accessible
+All nodes should be in **Ready** state and the Kubernetes control plane should be accessible.
 
-### Outcome
-At this point:
+## What you've accomplished and what's next
 
-- Google Cloud SDK is installed and configured
-- GKE cluster is running
-- kubectl is connected to the cloud cluster
-- Helm is ready to deploy applications on GKE
+You've successfully prepared your GKE environment by installing and configuring the Google Cloud SDK, creating a GKE cluster, connecting kubectl to the cluster, and verifying cluster access. Your environment is now ready to deploy applications using Helm charts.
 
-The environment is now prepared to deploy Helm charts.
+Next, you'll deploy PostgreSQL on your GKE cluster using a custom Helm chart with persistent storage and secure credentials.
 

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

@@ -93,7 +93,7 @@ helm version
 
 You should see an output similar to:
 ```output
-version.BuildInfo{Version:"v3.19.2", GitCommit:"8766e718a0119851f10ddbe4577593a45fadf544", GitTreeState:"clean", GoVersion:"go1.24.9"}
+version.BuildInfo{Version:"v3.19.4", GitCommit:"7cfb6e486dac026202556836bb910c37d847793e", GitTreeState:"clean", GoVersion:"go1.24.11"}
 ```
 
 ## Install KinD

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

@@ -6,16 +6,9 @@ weight: 9
 layout: learningpathall
 ---
 
-## NGINX Deployment Using Custom Helm Chart
-This document explains how to deploy NGINX as a frontend service on Kubernetes using a custom Helm chart.
+## Deploy NGINX using a custom Helm chart
 
-## Goal
-After completing this guide, the environment will include:
-
-- NGINX deployed using Helm
-- Public access using a LoadBalancer service
-- External IP available for browser access
-- Foundation for connecting backend services (Redis, PostgreSQL)
+This section explains how to deploy NGINX as a frontend service on Kubernetes using a custom Helm chart. After completing this section, you'll have NGINX deployed using Helm with public access through a LoadBalancer service, providing an external IP for browser access and a foundation for connecting backend services like Redis and PostgreSQL.
 
 ### Create Helm Chart
 Generates a Helm chart skeleton that will be customized for NGINX.
@@ -34,13 +27,8 @@ my-nginx/
 ```
 
 ### Configure values.yaml
-Defines configurable parameters such as:
-
-- NGINX image
-- Service type
-- Public port
 
-Replace the contents of `my-nginx/values.yaml` with:
+Replace the contents of `my-nginx/values.yaml` with the following to define configurable parameters including the NGINX image, service type, and public port:
 ```yaml
 image:
   repository: nginx
@@ -51,20 +39,11 @@ service:
   port: 80
 ```
 
-That matters
-
-- Centralizes configuration
-- Allows service exposure without editing templates
-- Simplifies future changes
-
-### Deployment Definition (deployment.yaml)
-Defines how the NGINX container runs inside Kubernetes, including:
+This configuration centralizes settings, allows service exposure without editing templates, and simplifies future changes.
 
-- Container image
-- Pod labels
-- Port exposure
+### Deployment definition (deployment.yaml)
 
-Replace `my-nginx/templates/deployment.yaml` completely:
+Replace the entire contents of `my-nginx/templates/deployment.yaml` with the following to define how the NGINX container runs inside Kubernetes, including the container image, pod labels, and port exposure:
 
 ```yaml
 apiVersion: apps/v1
@@ -91,10 +70,9 @@ spec:
             - containerPort: 80
 ```
 
-### Service Definition (service.yaml)
-Exposes NGINX to external traffic using a Kubernetes LoadBalancer.
+### Service definition (service.yaml)
 
-Replace `my-nginx/templates/service.yaml` with:
+Replace the entire contents of `my-nginx/templates/service.yaml` with the following to expose NGINX to external traffic using a Kubernetes LoadBalancer:
 
 ```yaml
 apiVersion: v1
@@ -109,11 +87,7 @@ spec:
     app: {{ include "my-nginx.name" . }}
 ```
 
-Why LoadBalancer:
-
-- Provides a public IP
-- Required for browser access
-- Common pattern for frontend services
+A LoadBalancer provides a public IP required for browser access and is a common pattern for frontend services.
 
 ### Install & Access
 
@@ -135,14 +109,15 @@ NOTES:
   echo http://$SERVICE_IP:80
 ```
 
-### Access NGINX from Browser
-Get External IP
+### Access NGINX from a browser
+
+Get the external IP by running the following command:
 
 ```console
 kubectl get svc
 ```
 
-Wait until EXTERNAL-IP is assigned.
+Wait until **EXTERNAL-IP** is assigned.
 
 ```output
 NAME                       TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)        AGE
@@ -152,21 +127,19 @@ postgres-app-my-postgres   ClusterIP      34.118.225.2     <none>          5432/
 redis-my-redis             ClusterIP      34.118.234.155   <none>          6379/TCP       6m53s
 ```
 
-**Open in browser:**
+Open the external IP in your browser:
 
 ```bash
-http://<EXTERNAL-IP>    
+http://<EXTERNAL-IP>
 ```
 
-You should see the default NGINX welcome page as shown below:
+You should see the default NGINX welcome page:
+
+![NGINX default welcome page displayed in a web browser showing the welcome message and basic NGINX information#center](images/nginx-browser.png "NGINX welcome page")
 
-![NGINX default welcome page in a web browser on an GCP VM alt-text#center](images/nginx-browser.png)
+## What you've accomplished and what's next
 
-### Outcome
-This deployment achieves the following:
+You've successfully deployed NGINX as a frontend service using a custom Helm chart. The deployment includes public access through a LoadBalancer with an external IP, and the infrastructure is ready to route traffic to backend services.
 
-- NGINX deployed using a custom Helm chart
-- Public access enabled via LoadBalancer
-- External IP available for frontend access
-- Ready to route traffic to backend services
+This completes the helm-on-gcp Learning Path. You've learned how to install and configure Helm on Google Cloud C4A Arm-based virtual machines, create and manage GKE clusters, deploy applications using both official and custom Helm charts, and validate Helm workflows on Arm64-based Kubernetes infrastructure.