articles-about-ingress-for-aks

Author: ShawnJackson

articles/application-gateway/ingress-controller-autoscale-pods.md

@@ -1,6 +1,6 @@
 ---
 title: Autoscale AKS pods with Azure Application Gateway metrics
-description: This article provides instructions on how to scale your AKS backend pods using Application Gateway metrics and Azure Kubernetes Metric Adapter
+description: This article provides instructions on how to scale your AKS back-end pods by using Application Gateway metrics and the Azure Kubernetes Metrics Adapter.
 services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
@@ -10,35 +10,31 @@ ms.date: 9/17/2024
 ms.author: greglin
 ---
 
-# Autoscale your AKS pods using Application Gateway Metrics (Beta)
+# Autoscale your AKS pods by using Application Gateway metrics
 
 As incoming traffic increases, it becomes crucial to scale up your applications based on the demand.
 
-In the following tutorial, we explain how you can use Application Gateway's `AvgRequestCountPerHealthyHost` metric to scale up your application. `AvgRequestCountPerHealthyHost` measures average requests sent to a specific backend pool and backend HTTP setting combination.
+This article explains how you can use the `AvgRequestCountPerHealthyHost` metric in Azure Application Gateway to scale up an application. The `AvgRequestCountPerHealthyHost` metric measures average requests sent to a specific combination of a back-end pool and a back-end HTTP setting.
 
-Use following two components:
+Use the following two components:
 
-* [`Azure Kubernetes Metric Adapter`](https://github.com/Azure/azure-k8s-metrics-adapter) - We use the metric adapter to expose Application Gateway metrics through the metric server. The Azure Kubernetes Metric Adapter is an open source project under Azure, similar to the Application Gateway Ingress Controller.
-* [`Horizontal Pod Autoscaler`](/azure/aks/concepts-scale#horizontal-pod-autoscaler) - We use HPA to use Application Gateway metrics and target a deployment for scaling.
+- [Azure Kubernetes Metrics Adapter](https://github.com/Azure/azure-k8s-metrics-adapter): You use this component to expose Application Gateway metrics through the metric server. It's an open-source project under Azure, similar to the Application Gateway Ingress Controller.
+- [Horizontal Pod Autoscaler](/azure/aks/concepts-scale#horizontal-pod-autoscaler): You use this component to apply Application Gateway metrics and target a deployment for scaling.
 
 > [!NOTE]
-> The Azure Kubernetes Metrics Adapter is no longer maintained. Kubernetes Event-driven Autoscaling (KEDA) is an alternative.<br>
-> Also see [Application Gateway for Containers](for-containers/overview.md).
+> The Azure Kubernetes Metrics Adapter is no longer maintained. Kubernetes Event-driven Autoscaling (KEDA) is an alternative.
 
-> [!TIP]
-> Also see [What is Application Gateway for Containers](for-containers/overview.md).
+## Set up the Azure Kubernetes Metrics Adapter
 
-## Setting up Azure Kubernetes Metric Adapter
-
-1. First, create a Microsoft Entra service principal and assign it `Monitoring Reader` access over Application Gateway's resource group.
+1. Create a Microsoft Entra service principal and assign it `Monitoring Reader` access over the Application Gateway instance's resource group:
 
     ```azurecli
     applicationGatewayGroupName="<application-gateway-group-id>"
     applicationGatewayGroupId=$(az group show -g $applicationGatewayGroupName -o tsv --query "id")
     az ad sp create-for-rbac -n "azure-k8s-metric-adapter-sp" --role "Monitoring Reader" --scopes applicationGatewayGroupId
     ```
 
-1. Now, deploy the [`Azure Kubernetes Metric Adapter`](https://github.com/Azure/azure-k8s-metrics-adapter) using the Microsoft Entra service principal created previously.
+1. Deploy the Azure Kubernetes Metrics Adapter by using the Microsoft Entra service principal that you created previously:
 
     ```bash
     kubectl create namespace custom-metrics
@@ -50,7 +46,7 @@ Use following two components:
     kubectl apply -f kubectl apply -f https://raw.githubusercontent.com/Azure/azure-k8s-metrics-adapter/master/deploy/adapter.yaml -n custom-metrics
     ```
 
-1. Create an `ExternalMetric` resource with name `appgw-request-count-metric`. This resource instructs the metric adapter to expose `AvgRequestCountPerHealthyHost` metric for `myApplicationGateway` resource in `myResourceGroup` resource group. You can use the `filter` field to target a specific backend pool and backend HTTP setting in the Application Gateway.
+1. Create an `ExternalMetric` resource with the name `appgw-request-count-metric`. This resource instructs the metric adapter to expose the `AvgRequestCountPerHealthyHost` metric for the `myApplicationGateway` resource in the `myResourceGroup` resource group. You can use the `filter` field to target a specific back-end pool and back-end HTTP setting in the Application Gateway instance.
 
     ```yaml
     apiVersion: azure.com/v1alpha2
@@ -60,8 +56,8 @@ Use following two components:
     spec:
         type: azuremonitor
         azure:
-            resourceGroup: myResourceGroup # replace with your application gateway's resource group name
-            resourceName: myApplicationGateway # replace with your application gateway's name
+            resourceGroup: myResourceGroup # replace with your Application Gateway instance's resource group name
+            resourceName: myApplicationGateway # replace with your Application Gateway instance's name
             resourceProviderNamespace: Microsoft.Network
             resourceType: applicationGateways
         metric:
@@ -70,7 +66,8 @@ Use following two components:
             filter: BackendSettingsPool eq '<backend-pool-name>~<backend-http-setting-name>' # optional
     ```
 
-You can now make a request to the metric server to see if our new metric is getting exposed:
+You can now make a request to the metric server to see if the new metric is being exposed:
+
 ```bash
 kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/default/appgw-request-count-metric"
 # Sample Output
@@ -93,13 +90,14 @@ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/default/appg
 # }
 ```
 
-## Using the new metric to scale up the deployment
+## Use the new metric to scale up the deployment
+
+After you expose `appgw-request-count-metric` through the metric server, you're ready to use the [Horizontal Pod Autoscaler](/azure/aks/concepts-scale#horizontal-pod-autoscaler) to scale up your target deployment.
 
-Once we're able to expose `appgw-request-count-metric` through the metric server, we're ready to use [`Horizontal Pod Autoscaler`](/azure/aks/concepts-scale#horizontal-pod-autoscaler) to scale up our target deployment.
+The following example targets a sample deployment named `aspnet`. You scale up pods when `appgw-request-count-metric` is `200` per pod, up to a maximum of `10` pods.
 
-In following example, we target a sample deployment `aspnet`. We scale up Pods when `appgw-request-count-metric` > 200 per Pod up to a max of `10` Pods.
+Replace your target deployment name and apply the following autoscale configuration:
 
-Replace your target deployment name and apply the following auto scale configuration:
 ```yaml
 apiVersion: autoscaling/v2
 kind: HorizontalPodAutoscaler
@@ -119,10 +117,13 @@ spec:
       targetAverageValue: 200
 ```
 
-Test your setup by using a load test tool like apache bench:
+Test your setup by using a load test tool like ApacheBench:
+
 ```bash
 ab -n10000 http://<applicaiton-gateway-ip-address>/
 ```
 
 ## Next steps
-- [**Troubleshoot Ingress Controller issues**](ingress-controller-troubleshoot.md): Troubleshoot any issues with the Ingress Controller.
+
+- [Troubleshoot Application Gateway Ingress Controller issues](ingress-controller-troubleshoot.md)
+- [What is Application Gateway for Containers?](for-containers/overview.md)

articles/application-gateway/ingress-controller-expose-websocket-server.md

@@ -1,6 +1,6 @@
 ---
 title: Expose a WebSocket server to Application Gateway
-description: This article provides information on how to expose a WebSocket server to Application Gateway with ingress controller for AKS clusters. 
+description: This article provides information on how to expose a WebSocket server to Application Gateway with an ingress controller for AKS clusters. 
 services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
@@ -11,12 +11,12 @@ ms.author: greglin
 
 # Expose a WebSocket server to Application Gateway
 
-As outlined in the Application Gateway v2 documentation - it [provides native support for the WebSocket and HTTP/2 protocols](features.md#websocket-and-http2-traffic). Both Application Gateway and the Kubernetes Ingress don't have a user-configurable setting to selectively enable or disable WebSocket support.
+Azure Application Gateway v2 [provides native support for the WebSocket and HTTP/2 protocols](features.md#websocket-and-http2-traffic). Both Application Gateway and the Kubernetes ingress don't have a user-configurable setting to selectively enable or disable WebSocket support.
 
-> [!TIP]
-> Also see [What is Application Gateway for Containers](for-containers/overview.md).
+## YAML for WebSocket server deployment
+
+The following Kubernetes deployment YAML shows the minimum configuration for deploying a WebSocket server, which is the same as deploying a regular web server:
 
-The following Kubernetes deployment YAML shows the minimum configuration used to deploy a WebSocket server, which is the same as deploying a regular web server:
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -73,9 +73,10 @@ spec:
               servicePort: 80
 ```
 
-Given that all the prerequisites are fulfilled, and you have an Application Gateway controlled by a Kubernetes Ingress in your AKS, the deployment shown previously would result in a WebSockets server exposed on port 80 of your Application Gateway's public IP and the `ws.contoso.com` domain.
+Assuming that all the prerequisites are fulfilled, and you have an Application Gateway instance controlled by a Kubernetes ingress in Azure Kubernetes Service (AKS), the preceding deployment would result in a WebSocket server exposed on port 80 of your Application Gateway instance's public IP address and the `ws.contoso.com` domain.
 
 The following cURL command would test the WebSocket server deployment:
+
 ```shell
 curl -i -N -H "Connection: Upgrade" \
         -H "Upgrade: websocket" \
@@ -86,10 +87,15 @@ curl -i -N -H "Connection: Upgrade" \
         http://1.2.3.4:80/ws
 ```
 
-## WebSocket Health Probes
+## WebSocket health probes
+
+If your deployment doesn't explicitly define health probes, Application Gateway attempts an HTTP `GET` operation on your WebSocket server endpoint.
+Depending on the server implementation (such as [this example](https://github.com/gorilla/websocket/blob/master/examples/chat/main.go)), you might need WebSocket-specific headers (`Sec-Websocket-Version`, for instance).
+
+Because Application Gateway doesn't add WebSocket headers, the Application Gateway health probe response from your WebSocket server is most likely `400 Bad Request`. Application Gateway then marks your pods as unhealthy. This status eventually results in a `502 Bad Gateway` for the consumers of the WebSocket server.
+
+To avoid the `502 Bad Gateway` error, you might need to add an HTTP `GET` handler for a health check to your server. For example, `/health` returns `200 OK`.
+
+## Related content
 
-If your deployment doesn't explicitly define health probes, Application Gateway would attempt an  HTTP GET on your WebSocket server endpoint.
-Depending on the server implementation ([here's one we love](https://github.com/gorilla/websocket/blob/master/examples/chat/main.go)) WebSocket specific headers may be required (`Sec-Websocket-Version` for instance).
-Since Application Gateway doesn't add WebSocket headers, the Application Gateway's health probe response from your WebSocket server is most likely `400 Bad Request`.
-As a result, Application Gateway marks your pods as unhealthy. This status eventually results in a `502 Bad Gateway` for the consumers of the WebSocket server.
-To avoid the bad gateway error, you might need to add an HTTP GET handler for a health check to your server (`/health` for instance, which returns `200 OK`).
+- [What is Application Gateway for Containers?](for-containers/overview.md)