Merge pull request #287362 from ShawnJackson/articles-about-ingress-for-aks

[AQ] edit pass: Articles about ingress for AKS

Author: ktoliver

articles/application-gateway/ingress-controller-add-health-probes.md

@@ -1,6 +1,6 @@
 ---
 title: Add health probes to your AKS pods
-description: This article provides information on how to add health probes (readiness and/or liveness) to AKS pods with an Application Gateway. 
+description: This article provides information on how to add readiness or liveness health probes to AKS pods by using Application Gateway. 
 services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
@@ -9,14 +9,12 @@ ms.date: 9/17/2024
 ms.author: greglin
 ---
 
-# Add Health Probes to your service
-By default, Ingress controller provisions an HTTP GET probe for the exposed pods.
-The probe properties can be customized by adding a [Readiness or Liveness Probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) to your `deployment`/`pod` spec.
+# Add health probes to your AKS pods
 
-> [!TIP]
-> Also see [What is Application Gateway for Containers](for-containers/overview.md).
+By default, the Application Gateway Ingress Controller (AGIC) provisions an HTTP `GET` probe for exposed Azure Kubernetes Service (AKS) pods. You can customize the probe properties by adding a [readiness or liveness probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) to your deployment or pod specification.
+
+## Code for adding a readiness or liveness probe
 
-## With `readinessProbe` or `livenessProbe`
 ```yaml
 apiVersion: networking.k8s.io/v1
 kind: Deployment
@@ -43,25 +41,31 @@ spec:
           timeoutSeconds: 1
 ```
 
-Kubernetes API Reference:
-* [Container Probes](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#httpgetaction-v1-core)
+For more information, see the [Kubernetes API reference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#httpgetaction-v1-core).
 
 > [!NOTE]
-> * `readinessProbe` and `livenessProbe` are supported when configured with `httpGet`.
-> * Probing on a port other than the one exposed on the pod is currently not supported.
-> * `HttpHeaders`, `InitialDelaySeconds`, `SuccessThreshold` aren't supported.
+> - `readinessProbe` and `livenessProbe` are supported when you configure them with `httpGet`.
+> - Probing on a port other than the one exposed on the pod is currently not supported.
+> - `HttpHeaders`, `InitialDelaySeconds`, and `SuccessThreshold` aren't supported.
+
+If the code doesn't include a readiness or liveness probe, the ingress controller makes an assumption that the service is reachable on either:
+
+- The `Path` value that's specified for `backend-path-prefix` annotation
+- The `path` value that's specified in the `ingress` definition for the service
 
-##  Without `readinessProbe` or `livenessProbe`
-If the above probes aren't provided, then the Ingress Controller makes an assumption that the service is reachable on the `Path` specified for `backend-path-prefix` annotation, or the `path` specified in the `ingress` definition for the service.
+## Default values for the health probe
 
-## Default Values for Health Probe
-For any property that can't be inferred by the readiness/liveness probe, default values are set.
+Any property that the readiness or liveness probe can't infer uses the following default values.
 
-| Application Gateway Probe Property | Default Value |
+| Application Gateway probe property | Default value |
 |-|-|
-| `Path` | / |
-| `Host` | localhost |
-| `Protocol` | HTTP |
-| `Timeout` | 30 |
-| `Interval` | 30 |
-| `UnhealthyThreshold` | 3 |
+| `Path` | `/` |
+| `Host` | `localhost` |
+| `Protocol` | `HTTP` |
+| `Timeout` | `30` |
+| `Interval` | `30` |
+| `UnhealthyThreshold` | `3` |
+
+## Related content
+
+- [What is Application Gateway for Containers?](for-containers/overview.md)

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 Azure Kubernetes Service (AKS) pods for 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-cookie-affinity.md

@@ -1,6 +1,6 @@
 ---
-title: Enable cookie based affinity with Application Gateway
-description: This article provides information on how to enable cookie-based affinity with an Application Gateway. 
+title: Enable cookie-based affinity with Application Gateway
+description: This article provides information on how to enable cookie-based affinity with Application Gateway. 
 services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
@@ -9,13 +9,12 @@ ms.date: 9/17/2024
 ms.author: greglin
 ---
 
-# Enable Cookie based affinity with an Application Gateway
-As outlined in the [Azure Application Gateway Documentation](./application-gateway-components.md#http-settings), Application Gateway supports cookie based affinity, which means it can direct subsequent traffic from a user session to the same server for processing.
+# Enable cookie-based affinity with Application Gateway
 
-> [!TIP]
-> Also see [What is Application Gateway for Containers](for-containers/overview.md).
+As outlined in the [Azure Application Gateway documentation](./application-gateway-components.md#http-settings), Application Gateway supports cookie-based affinity. This support means that the service can direct subsequent traffic from a user session to the same server for processing.
 
 ## Example
+
 ```yaml
 apiVersion: networking.k8s.io/v1
 kind: Ingress
@@ -31,4 +30,8 @@ spec:
       - backend:
           serviceName: frontend
           servicePort: 80
-```
+```
+
+## Related content
+
+- [What is Application Gateway for Containers?](for-containers/overview.md)

articles/application-gateway/ingress-controller-disable-addon.md

@@ -1,6 +1,6 @@
 ---
 title: Disable and re-enable Application Gateway Ingress Controller add-on for Azure Kubernetes Service cluster
-description: This article provides information on how to disable and re-enable the AGIC add-on for your AKS cluster
+description: This article provides information on how to disable and re-enable the AGIC add-on for your AKS cluster.
 services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
@@ -9,34 +9,42 @@ ms.date: 9/17/2024
 ms.author: greglin
 ---
 
-# Disable and re-enable AGIC add-on for your AKS cluster
-Application Gateway Ingress Controller (AGIC) deployed as an AKS add-on allows you to enable and disable the add-on with one line in Azure CLI. The life cycle of the Application Gateway differs when you disable the AGIC add-on, depending on if the Application Gateway was created by the AGIC add-on, or if it was deployed separately from the AGIC add-on. You can run the same command to re-enable the AGIC add-on if you ever disable it, or to enable the AGIC add-on using an existing AKS cluster and Application Gateway.
+# Disable and re-enable the AGIC add-on for your AKS cluster
 
-> [!TIP]
-> Also see [What is Application Gateway for Containers](for-containers/overview.md).
+When you deploy the Application Gateway Ingress Controller (AGIC) as an Azure Kubernetes Service (AKS) add-on, you can enable and disable the add-on with one line in the Azure CLI.
+
+The life cycle of the Azure Application Gateway instance differs when you disable the AGIC add-on, depending on whether you created the Application Gateway instance by using the AGIC add-on or you deployed it separately from the add-on. You can run the same command to re-enable the AGIC add-on if you ever disable it, or to enable the AGIC add-on by using an existing AKS cluster and Application Gateway instance.
+
+## Disable the AGIC add-on with an associated Application Gateway instance
 
-## Disabling AGIC add-on with associated Application Gateway 
-If the AGIC add-on automatically deployed the Application Gateway for you when you first set up everything, then disabling the AGIC add-on will by default delete the Application Gateway based on a couple criteria. There are two criteria that the AGIC add-on looks for to determine if it should delete the associated Application Gateway when you disable it:
-- Is the Application Gateway that the AGIC add-on is associated with deployed in the MC_* node resource group? 
-- Does the Application Gateway that the AGIC add-on is associated with have the tag "created-by: ingress-appgw"? The tag is used by AGIC to determine if the Application Gateway was deployed by the add-on or not. 
+If the AGIC add-on automatically deployed the Application Gateway instance for you when you first set up everything, then disabling the AGIC add-on might delete the Application Gateway instance by default. The AGIC add-on considers two criteria to determine if it should delete the associated Application Gateway instance:
 
-If both criteria are met, then the AGIC add-on will delete the Application Gateway it created when the add-on is disabled; however, it won't delete the public IP or the subnet in which the Application Gateway was deployed with/in. If the first criteria isn't met, then it won't matter if the Application Gateway has the "created-by: ingress-appgw" tag - disabling the add-on won't delete the Application Gateway. Likewise, if the second criteria isn't met, that is. The Application Gateway lacks that tag, then disabling the add-on won't delete the Application Gateway in the MC_* node resource group. 
+- Is the Application Gateway instance deployed in the `MC_*` node resource group?
+- Does the Application Gateway instance have the tag `created-by: ingress-appgw`? AGIC uses the tag to determine whether or not the add-on deployed the Application Gateway instance.
 
-> [!TIP] 
-> If you don't want the Application Gateway to be deleted when disabling the add-on, but it meets both criteria then remove the "created-by: ingress-appgw" tag to prevent the add-on from deleting your Application Gateway. 
+If both criteria are met, the AGIC add-on deletes the Application Gateway instance when you disable the add-on. However, the AGIC add-on doesn't delete the public IP address or the subnet in which it deployed the Application Gateway instance.
+
+If the first criterion isn't met, disabling the add-on doesn't delete the Application Gateway instance, even if the instance has the `created-by: ingress-appgw` tag. Likewise, if the second criterion isn't met (that is, the Application Gateway instance lacks that tag), disabling the add-on doesn't delete the Application Gateway instance in the `MC_*` node resource group.
+
+> [!TIP]
+> If you don't want the add-on to delete your Application Gateway instance when you disable the add-on, but the instance meets both criteria, remove the `created-by: ingress-appgw` tag.
+
+To disable the AGIC add-on, run the following command:
 
-To disable the AGIC add-on, run the following command: 
 ```azurecli-interactive
 az aks disable-addons -n <AKS-cluster-name> -g <AKS-resource-group-name> -a ingress-appgw 
 ```
 
-## Enable AGIC add-on on existing Application Gateway and AKS Cluster
-If you ever disable the AGIC add-on and need to re-enable the add-on, or want to enable the add-on using an existing Application Gateway and AKS cluster, then run the following command:
+## Enable the AGIC add-on on an existing Application Gateway instance and AKS cluster
+
+If you ever disable the AGIC add-on and need to re-enable it, or you want to enable the add-on by using an existing Application Gateway instance and AKS cluster, run the following command:
 
 ```azurecli-interactive
 appgwId=$(az network application-gateway show -n <application-gateway-name> -g <resource-group-name> -o tsv --query "id") 
 az aks enable-addons -n <AKS-cluster-name> -g <AKS-cluster-resource-group> -a ingress-appgw --appgw-id $appgwId
 ```
 
-## Next steps
-For more information on how to enable the AGIC add-on using an existing Application Gateway and AKS cluster, see [AGIC add-on brownfield deployment](tutorial-ingress-controller-add-on-existing.md).
+## Related content
+
+- For more information on how to enable the AGIC add-on by using an existing Application Gateway instance and AKS cluster, see [this tutorial](tutorial-ingress-controller-add-on-existing.md).
+- For information about Application Gateway for Containers, see [What is Application Gateway for Containers?](for-containers/overview.md).