Update chapter 1: Add ConfigMap, fix nodeSelector/container name, update outputs, add service selector explanation

Author: geremyCohen

content/learning-paths/servers-and-cloud-computing/multiarch_nginx_on_aks/1-deploy-intel.md

@@ -8,17 +8,16 @@ layout: learningpathall
 
 ## Deployment and service
 
-In this section, you'll add a new namespace, deployment, and service for nginx on Intel.  The end result will be a K8s cluster running nginx accessible via the Internet through a load balancer. 
+In this section, you'll add a new namespace, deployment, and service for nginx on Intel. The end result will be a K8s cluster running nginx accessible via the Internet through a load balancer. 
 
 To better understand the individual components, the configuration is split into two files:
 
-1. Applying the namespace.yaml creates a new namespace called `nginx`, which contains all your K8s nginx objects. 
+1. **namespace.yaml** - Creates a new namespace called `nginx`, which contains all your K8s nginx objects
 
-2. Applying the intel_nginx.yaml creates the following K8s objects:
-
-2. 1. A K8s deployment called `nginx-intel-deployment`. This deployment pulls a multi-architecture [nginx image](https://hub.docker.com/_/nginx) from DockerHub, and launches a pod for it on the x86 node. 
-
-2. 2. A K8s load balancer service `nginx-intel-svc`, targeting any pod with the `arch: intel` label (the Intel deployment will create this pod).
+2. **intel_nginx.yaml** - Creates the following K8s objects:
+   - **ConfigMap** (`nginx-intel-config`) - Contains performance-optimized nginx configuration
+   - **Deployment** (`nginx-intel-deployment`) - Pulls a multi-architecture [nginx image](https://hub.docker.com/_/nginx) from DockerHub, launches a pod on the Intel node, and mounts the ConfigMap as `/etc/nginx/nginx.conf`
+   - **Service** (`nginx-intel-svc`) - Load balancer targeting pods with both `app: nginx-multiarch` and `arch: intel` labels
 
 
 The following commands download, create, and apply the namespace and Intel nginx deployment and service configuration:
@@ -32,33 +31,24 @@ kubectl apply -f intel_nginx.yaml
 
 ```
 
-When pasted into your terminal, you will see output similar to the following for each command:
-
 You will see output similar to:
 
 ```output
-curl -o intel_nginx.yaml https://raw.githubusercontent.com/geremyCohen/nginxOnAKS/refs/heads/main/intel_nginx.yaml
-kubectl apply -f intel_nginx.yaml
-  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
-                                 Dload  Upload   Total   Spent    Left  Speed
-100    55  100    55    0     0   1242      0 --:--:-- --:--:-- --:--:--  1250
-namespace/nginx unchanged
-  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
-                                 Dload  Upload   Total   Spent    Left  Speed
-100   751  100   751    0     0  16192      0 --:--:-- --:--:-- --:--:-- 16326
-deployment.apps/nginx-intel-deployment unchanged
-service/nginx-intel-svc unchanged```
+namespace/nginx created
+configmap/nginx-intel-config created
+deployment.apps/nginx-intel-deployment created
+service/nginx-intel-svc created
 ```
 
 ### Examining the deployment configuration
 Taking a closer look at the `intel_nginx.yaml` deployment file, you'll see some settings that ensure the deployment runs as we expect on the Intel node:
 
-* The `nodeSelector` `agentpool`, with the value of `intel`. This ensures that the deployment only runs on Intel nodes, utilizing the amd64 version of the nginx container image.
+* The `nodeSelector` `kubernetes.io/arch: amd64`. This ensures that the deployment only runs on x86_64 nodes, utilizing the amd64 version of the nginx container image.
 
 ```yaml
     spec:
       nodeSelector:
-        agentpool: intel
+        kubernetes.io/arch: amd64
 ```
 
 * The A `sessionAffinity` tag, which removes sticky connections to the target pods. This removes persistent connections to the same pod on each request.
@@ -68,11 +58,20 @@ spec:
   sessionAffinity: None
 ```
 
+* The service selector uses both `app: nginx-multiarch` and `arch: intel` labels to target only Intel pods. This dual-label approach allows for both architecture-specific and multi-architecture service routing.
+
+```yaml
+  selector:
+    app: nginx-multiarch
+    arch: intel
+```
+
 * Since the final goal is running nginx on multiple architectures, the deployment uses the standard nginx image from DockerHub. This image supports multiple architectures, including amd64 (Intel), arm64 (ARM), and others.
 
 ```yaml
-    - image: nginx:latest
-    name: nginx-multiarch
+      containers:
+      - image: nginx:latest
+        name: nginx
 ```
 {{% notice Note %}}
 Optionally, you can set the `default Namespace` to `nginx` to simplify future commands by removing the need to specify the `-nnginx` flag each time:
@@ -90,19 +89,29 @@ You've deployed the objects, so now it's time to verify everything is running as
 kubectl get nodes,pods,svc -nnginx 
 ```
 
-Your output should be similar to the following, showing three nodes, one pod, and one service:
+Your output should be similar to the following, showing two nodes, one pod, and one service:
 
 ```output
-NAME                                STATUS   ROLES    AGE   VERSION
-node/aks-amd-10099357-vmss000000    Ready    <none>   10m   v1.32.7
-node/aks-arm-49028967-vmss000000    Ready    <none>   12m   v1.32.7
-node/aks-intel-34846084-vmss000000  Ready    <none>   15m   v1.32.7
+NAME                                 STATUS   ROLES    AGE   VERSION
+node/aks-arm-56500727-vmss000000     Ready    <none>   50m   v1.32.7
+node/aks-intel-31372303-vmss000000   Ready    <none>   55m   v1.32.7
+
+NAME                                          READY   STATUS    RESTARTS   AGE
+pod/nginx-intel-deployment-78bb8885fd-mw24f   1/1     Running   0          38s
+
+NAME                      TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
+service/nginx-intel-svc   LoadBalancer   10.0.226.250   20.80.128.191   80:30080/TCP   39s
+```
 
-NAME                                        READY   STATUS    RESTARTS   AGE
-pod/nginx-intel-deployment-7d4c8f9b-xyz12  1/1     Running   0          2m
+You can also verify the ConfigMap was created:
 
-NAME                      TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE
-service/nginx-intel-svc   LoadBalancer   10.0.45.123   20.1.2.3        80:30080/TCP   2m
+```bash
+kubectl get configmap -nnginx
+```
+
+```output
+NAME                 DATA   AGE
+nginx-intel-config   1      51s
 ```
 
 With the pods in a `Ready` state and the service showing a valid `External IP`, you're now ready to test the nginx Intel service.