Merge pull request #2385 from madeline-underwood/kedify

Kedify_JA to review

Author: jasonrandrews

content/learning-paths/servers-and-cloud-computing/kedify-http-autoscaling/_index.md

@@ -1,23 +1,19 @@
 ---
-title: Autoscaling HTTP applications on Kubernetes
+title: Autoscale HTTP applications on Kubernetes with KEDA and Kedify
 
-draft: true
-cascade:
-    draft: true
-    
 minutes_to_complete: 45
 
-who_is_this_for: This is an introductory topic for developers running HTTP-based workloads on Kubernetes who want to enable event-driven autoscaling.
+who_is_this_for: This is an introductory topic for developers running HTTP workloads on Kubernetes who want to enable event-driven autoscaling with KEDA and Kedify.
 
 learning_objectives:
-  - Install Kedify (KEDA build, HTTP Scaler, and Kedify Agent) via Helm
-  - Verify that the components are running in your cluster
+  - Install Kedify (KEDA build, HTTP Scaler, and Kedify Agent) with Helm
+  - Verify that Kedify and KEDA components are running in the cluster
   - Deploy a sample HTTP application and test autoscaling behavior
 
 prerequisites:
   - A running Kubernetes cluster (local or cloud)
-  - kubectl and helm installed locally
-  - Access to the Kedify Service dashboard (https://dashboard.kedify.io/) to obtain Organization ID and API Key. You can log in or create an account if you don’t have one
+  - Kubectl and Helm installed 
+  - Access to the Kedify Service dashboard to obtain your Organization ID and API key (sign up at [Kedify dashboard](https://dashboard.kedify.io/))
 
 author: Zbynek Roubalik
 

content/learning-paths/servers-and-cloud-computing/kedify-http-autoscaling/http-scaling.md

@@ -1,31 +1,36 @@
 ---
-title: "HTTP Scaling for Ingress-Based Applications"
+title: "Autoscale HTTP applications with Kedify and Kubernetes Ingress"
 weight: 4
 layout: "learningpathall"
 ---
+## Overview
 
-In this section, you’ll gain hands-on experience with Kedify HTTP autoscaling. You will deploy a small web service, expose it through a standard Kubernetes Ingress, and rely on Kedify’s autowiring to route traffic via its proxy so requests are measured and drive scaling.
+In this section, you’ll gain hands-on experience with Kedify HTTP autoscaling. You will deploy a small web service, expose it through a standard Kubernetes Ingress, and rely on Kedify’s autowiring to route traffic through its proxy so that requests are measured and drive scaling.
 
-You will scale a real HTTP app exposed through Kubernetes Ingress using Kedify’s [kedify-http](https://docs.kedify.io/scalers/http-scaler/) scaler. You will deploy a simple application, enable autoscaling with a [ScaledObject](https://keda.sh/docs/latest/concepts/scaling-deployments/), generate load, and observe the system scale out and back in (including scale-to-zero when idle).
+You will scale a real HTTP app exposed through Kubernetes Ingress using [Kedify’s HTTP Scaler](https://docs.kedify.io/scalers/http-scaler/), and then move on to deploy a simple application, enable autoscaling with a scaled object, generate load, and observe the system scale out and back in (including scale-to-zero when idle). 
+
+For more information, see [Scaling Deployments, StatefulSets & Custom Resources](https://keda.sh/docs/latest/concepts/scaling-deployments/) on the KEDA website.  
 
 ## How it works
 
-With ingress autowiring enabled, Kedify automatically routes traffic through its proxy before it reaches your Service/Deployment:
+With ingress autowiring enabled, Kedify automatically routes traffic through its proxy before it reaches your service and deployment:
 
 ```output
 Ingress → kedify-proxy → Service → Deployment
 ```
 
-The [Kedify Proxy](https://docs.kedify.io/scalers/http-scaler/#kedify-proxy) gathers request metrics used by the scaler to make decisions.
+The [Kedify proxy](https://docs.kedify.io/scalers/http-scaler/#kedify-proxy) gathers request metrics used by the scaler to make decisions.
+
+## Deployment overview
 
-## Deployment Overview
-  * Deployment & Service: An HTTP server with a small response delay to simulate work
-  * Ingress: Public entry point configured using host `application.keda`
-  * ScaledObject: A Kedify HTTP scaler using `trafficAutowire: ingress`
+There are three main components involved in the process:
+* For the application deployment and service, there is an HTTP server with a small response delay to simulate work.
+* For ingress, there is a public entry point that is configured using the `application.keda` host.
+* For the ScaledObject, there is a Kedify HTTP scaler using `trafficAutowire: ingress`.
 
-## Step 1 — Configure the Ingress IP environment variable
+## Configure the Ingress IP environment variable
 
-Before testing the application, make sure the INGRESS_IP environment variable is set to your ingress controller’s external IP address or hostname.
+Before testing the application, make sure the `INGRESS_IP` environment variable is set to your ingress controller’s external IP address or hostname.
 
 If you followed the [Install Ingress Controller](../install-ingress/) guide, you should already have this set. If not, or if you're using an existing ingress controller, run this command:
 
@@ -39,11 +44,9 @@ This will store the correct IP or hostname in the $INGRESS_IP environment variab
 If your ingress controller service uses a different name or namespace, update the command accordingly. For example, some installations use `nginx-ingress-controller` or place it in a different namespace.
 {{% /notice %}}
 
-## Step 2 — Deploy the application and configure Ingress
-
-Now  you will deploy a simple HTTP server and expose it using an Ingress resource. The source code for this application is available on [GitHub](https://github.com/kedify/examples/tree/main/samples/http-server).
+## Deploy the application and configure Ingress
 
-#### Deploy the application
+Now you will deploy a simple HTTP server and expose it using an Ingress resource. The source code for this application is available on the [Kedify GitHub repository](https://github.com/kedify/examples/tree/main/samples/http-server).
 
 Run the following command to deploy your application:
 
@@ -116,25 +119,29 @@ spec:
 EOF
 ```
 
-Notes:
-- `RESPONSE_DELAY` adds ~300ms latency per request, making scaling effects easier to see.
-- The Ingress uses host `application.keda`. To access this app we will use your ingress controller’s IP with a `Host:` header (shown below).
+## Key settings explained
 
-#### Verify the application is running correctly
+The manifest includes a few key options that affect scaling behavior:
 
-You will now check if you have 1 replica of the application deployed and ready:
+- `RESPONSE_DELAY` is set in the Deployment manifest above and adds approximately 300 ms latency per request; this slower response time increases the number of concurrent requests, making scaling effects easier to observe.
+- The ingress uses the host `application.keda`. To access this app, use your Ingress controller’s IP with a `Host:` header.
+
+## Verify the application is running
+
+Run the following command to check that 1 replica is ready:
 
 ```bash
 kubectl get deployment application
 ```
 
-In the output you should see 1 replica ready:
+Expected output includes 1 available replica:
 ```output
 NAME          READY   UP-TO-DATE   AVAILABLE   AGE
 application   1/1     1            1           3m44s
 ```
 
-#### Test the application
+## Test the application
+
 Once the application and Ingress are deployed, verify that everything is working correctly by sending a request to the exposed endpoint. Run the following command:
 
 ```bash
@@ -150,13 +157,14 @@ Content-Length: 301
 Connection: keep-alive
 ```
 
-## Step 3 — Enable autoscaling with Kedify
+## Enable autoscaling with Kedify
 
-The application is now running. Next,  you will enable autoscaling so that it can scale dynamically between 0 and 10 replicas. Kedify ensures that no requests are dropped during scaling. Apply the `ScaledObject` by running the following command:
+The application is now running. Next, you will enable autoscaling so that it can scale dynamically between 0 and 10 replicas. Kedify ensures that no requests are dropped during scaling. Apply the `ScaledObject` by running the following command:
 
 ```bash
 cat <<'EOF' | kubectl apply -f -
 apiVersion: keda.sh/v1alpha1
+
 kind: ScaledObject
 metadata:
   name: application
@@ -192,50 +200,52 @@ spec:
 EOF
 ```
 
-Key Fields explained:
-- `type: kedify-http` — Specifies that Kedify’s HTTP scaler should be used.
-- `hosts`, `pathPrefixes` — Define which requests are monitored for scaling decisions.
-- `service`, `port` — TIdentify the Kubernetes Service and port that will receive the traffic.
-- `scalingMetric: requestRate` and `targetValue: 10` — Scale out when request rate exceeds the target threshold (e.g., 1000 req/s per window, depending on configuration granularity).
-- `minReplicaCount: 0` — Enables scale-to-zero when there is no traffic.
-- `trafficAutowire: ingress` — Automatically wires your Ingress to the Kedify proxy for seamless traffic management.
+## Key fields explained
+
+Use the following field descriptions to understand how the `ScaledObject` controls HTTP-driven autoscaling and how each setting affects traffic routing and scale decisions:
+
+- `type: kedify-http` - Uses Kedify’s HTTP scaler.
+- `hosts`, `pathPrefixes` - Define which requests are monitored for scaling decisions.
+- `service`, `port` - Identify the Kubernetes Service and port that receive traffic.
+- `scalingMetric: requestRate`, `granularity: 1s`, `window: 10s`, `targetValue: "10"` - Scales out when the average request rate exceeds ~10 requests/second (rps) per replica over the last 10 seconds.
+- `minReplicaCount: 0` - Enables scale to zero when there is no traffic.
+- `trafficAutowire: ingress` - Automatically wires your Ingress to the Kedify proxy for seamless traffic management.
 
 After applying, the `ScaledObject` will appear in the Kedify dashboard (https://dashboard.kedify.io/).
 
-![Kedify Dashboard With ScaledObject](images/scaledobject.png)
+![Kedify dashboard showing the ScaledObject alt-text#center](images/scaledobject.png "Kedify dashboard: ScaledObject")
 
-## Step 4 — Send traffic and observe scaling
+## Send traffic and observe scaling
 
 Since no traffic is currently being sent to the application, it will eventually scale down to zero replicas.
 
-#### Verify scale to zero
+## Verify scale to zero
 
 To confirm that the application has scaled down, run the following command and watch until the number of replicas reaches 0:
 
 ```bash
 watch kubectl get deployment application -n default
 ```
 
-You should see similar output:
-```bash
+You should see output similar to:
+```output
 Every 2,0s: kubectl get deployment application -n default
 
 NAME          READY   UP-TO-DATE   AVAILABLE   AGE
 application   0/0     0            0           110s
 ```
 This continuously monitors the deployment status in the default namespace. Once traffic stops and the idle window has passed, you should see the application deployment report 0/0 replicas, indicating that it has successfully scaled to zero.
 
-#### Verify the app can scale from zero
+## Verify the app can scale from zero
 
-Next, test that the application can scale back up from zero when traffic arrives. Send a request to the app:
+Send a request to trigger scale-up:
 
 ```bash
 curl -I -H "Host: application.keda" http://$INGRESS_IP
 ```
-The application should scale from 0 → 1 replica automatically.
 You should receive an HTTP 200 OK response, confirming that the service is reachable again.
 
-#### Test higher load
+The application scales from 0 → 1 replica automatically, and you should receive an HTTP `200 OK` response.
 
 Now, generate a heavier, sustained load against the application. You can use `hey` (or a similar benchmarking tool):
 
@@ -264,7 +274,7 @@ Expected behavior:
 
 You can also monitor traffic and scaling in the Kedify dashboard:
 
-![Kedify Dashboard ScaledObject Detail](images/load.png)
+![Kedify dashboard showing request load and scaling over time alt-text#center](images/load.png "Kedify dashboard: request load and scaling over time")
 
 ## Clean up
 
@@ -280,4 +290,4 @@ This will delete the `ScaledObject`, Ingress, Service, and Deployment associated
 
 ## Next steps
 
-To go futher, you can explore the Kedify [How-to guides](https://docs.kedify.io/how-to/) for more configurations such as Gateway API, Istio VirtualService, or OpenShift Routes.
+To go further, you can explore the [Kedify How-To Guides](https://docs.kedify.io/how-to/) for more configurations such as Gateway API, Istio VirtualService, or OpenShift Routes.

content/learning-paths/servers-and-cloud-computing/kedify-http-autoscaling/install-ingress.md

@@ -1,92 +1,73 @@
 ---
-title: "Install Ingress Controller"
+title: "Install an ingress controller"
 weight: 3
 layout: "learningpathall"
 ---
 
-Before deploying HTTP applications with Kedify autoscaling, you need an Ingress Controller to handle incoming traffic. Most managed Kubernetes services offered by major cloud providers (AWS EKS, Google GKE, Azure AKS) do not include an Ingress Controller by default.
+## Install an ingress controller for HTTP autoscaling on Kubernetes
+
+Before deploying HTTP applications with Kedify autoscaling, you need an ingress controller to handle incoming traffic. Most managed Kubernetes services (AWS EKS, Google GKE, Azure AKS) do not include an ingress controller by default. In this Learning Path, you install the NGINX Ingress Controller with Helm and target arm64 nodes.
 
 {{% notice Note %}}
-If your cluster already has an Ingress Controller installed and configured, you can skip this step and proceed directly to the [HTTP Scaling guide](../http-scaling/).
+If your cluster already has an ingress controller installed and configured, you can skip this step and proceed to the [Autoscale HTTP applications with Kedify and Kubernetes Ingress section](../http-scaling/).
 {{% /notice %}}
 
-## Install NGINX Ingress Controller via Helm
+## Install the NGINX Ingress Controller with Helm
 
 Add the NGINX Ingress Controller Helm repository:
-
 ```bash
 helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
 helm repo update
 ```
 
-Install the NGINX Ingress Controller:
-
+Install the NGINX Ingress Controller (with `nodeSelector` and `tolerations` for arm64):
 ```bash
-helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
-  --namespace ingress-nginx \
-  --create-namespace \
-  \
-  --set "controller.nodeSelector.kubernetes\.io/arch=arm64" \
-  --set "controller.tolerations[0].key=kubernetes.io/arch" \
-  --set "controller.tolerations[0].operator=Equal" \
-  --set "controller.tolerations[0].value=arm64" \
-  --set "controller.tolerations[0].effect=NoSchedule" \
-  \
-  --set "controller.admissionWebhooks.patch.nodeSelector.kubernetes\.io/arch=arm64" \
-  --set "controller.admissionWebhooks.patch.tolerations[0].key=kubernetes.io/arch" \
-  --set "controller.admissionWebhooks.patch.tolerations[0].operator=Equal" \
-  --set "controller.admissionWebhooks.patch.tolerations[0].value=arm64" \
-  --set "controller.admissionWebhooks.patch.tolerations[0].effect=NoSchedule"
+helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx   --namespace ingress-nginx   --create-namespace   --set "controller.nodeSelector.kubernetes\.io/arch=arm64"   --set "controller.tolerations[0].key=kubernetes.io/arch"   --set "controller.tolerations[0].operator=Equal"   --set "controller.tolerations[0].value=arm64"   --set "controller.tolerations[0].effect=NoSchedule"   --set "controller.admissionWebhooks.patch.nodeSelector.kubernetes\.io/arch=arm64"   --set "controller.admissionWebhooks.patch.tolerations[0].key=kubernetes.io/arch"   --set "controller.admissionWebhooks.patch.tolerations[0].operator=Equal"   --set "controller.admissionWebhooks.patch.tolerations[0].value=arm64"   --set "controller.admissionWebhooks.patch.tolerations[0].effect=NoSchedule"
 ```
 
-Wait for the LoadBalancer to be ready:
-
+Wait for the load balancer to be ready:
 ```bash
-kubectl wait --namespace ingress-nginx \
-  --for=condition=ready pod \
-  --selector=app.kubernetes.io/component=controller \
-  --timeout=300s
+kubectl wait --namespace ingress-nginx   --for=condition=ready pod   --selector=app.kubernetes.io/component=controller   --timeout=300s
 ```
 
-## Get the External Endpoint
+Managed clouds may take a few minutes to allocate a public IP address or hostname.
 
-Get the external IP address or hostname for your ingress controller and save it as an environment variable:
+## Get the external endpoint
 
+Retrieve the external IP address or hostname and store it in an environment variable:
 ```bash
-export INGRESS_IP=$(kubectl get service ingress-nginx-controller --namespace=ingress-nginx -o jsonpath='{.status.loadBalancer.ingress[0].ip}{.status.loadBalancer.ingress[0].hostname}')
+export INGRESS_IP=$(kubectl get service ingress-nginx-controller   --namespace=ingress-nginx   -o jsonpath='{.status.loadBalancer.ingress[0].ip}{.status.loadBalancer.ingress[0].hostname}')
 echo "Ingress IP/Hostname: $INGRESS_IP"
 ```
 
-This will save the external IP or hostname in the `INGRESS_IP` environment variable and display it. If the command doesn't print any value, please repeat it after some time. Please note the value:
-- **AWS EKS**: You'll see an AWS LoadBalancer hostname (e.g., `a1234567890abcdef-123456789.us-west-2.elb.amazonaws.com`)
-- **Google GKE**: You'll see an IP address (e.g., `34.102.136.180`)
-- **Azure AKS**: You'll see an IP address (e.g., `20.62.196.123`)
+Typical values by provider:
+- **AWS EKS**: Load balancer hostname (for example, `a1234567890abcdef-123456789.us-west-2.elb.amazonaws.com`)
+- **Google GKE**: IP address (for example, `34.102.136.180`)
+- **Azure AKS**: IP address (for example, `20.62.196.123`)
 
-## Configure Access
+If no value is printed, wait briefly and re-run the command.
 
-To configure access to the ingress controller, you have two options:
+## Configure access
 
-### Option 1: DNS Setup (Recommended for production)
-Point `application.keda` to your ingress controller's external IP/hostname using your DNS provider.
+You have two options:
 
-### Option 2: Host Header (Quick setup)
-Use the external IP/hostname directly with a `Host:` header in your requests. When testing, you will use:
+- Option 1: DNS (recommended for production):
+  create a DNS record pointing `application.keda` to the external IP address or hostname of your ingress controller.
 
-```bash
-curl -H "Host: application.keda" http://$INGRESS_IP
-```
-
-The `$INGRESS_IP` environment variable contains the actual external IP or hostname from your ingress controller service.
+- Option 2: host header (quick test):  
+  use the external IP address or hostname directly with a `Host:` header:
+  ```bash
+  curl -H "Host: application.keda" http://$INGRESS_IP
+  ```
+  Here, `$INGRESS_IP` expands to the external IP address or hostname of the ingress controller.
 
-## Verification
-
-Verify that the ingress controller is working by checking its readiness:
+## Verify the installation
 
+List the controller pods and confirm they are running:
 ```bash
 kubectl get pods --namespace ingress-nginx
 ```
 
 You should see the `ingress-nginx-controller` pod in `Running` status.
 
-
-Now that you have an Ingress Controller installed and configured, proceed to the next section to deploy an application and configure Kedify autoscaling.
+Now that you have an ingress controller installed and configured, proceed to the next section to deploy an application and configure Kedify autoscaling.