articles-about-ingress-for-aks

Author: ShawnJackson

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-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

@@ -11,33 +11,33 @@ ms.author: greglin
 
 # Disable and re-enable the AGIC add-on for your AKS cluster
 
-The Application Gateway Ingress Controller (AGIC) deployed as an Azure Kubernetes Service (AKS) add-on allows you to enable and disable the add-on with one line in the Azure CLI.
+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 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.
+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.
 
-## Disabling AGIC add-on with associated Application Gateway
+## Disable the AGIC add-on with an associated Application Gateway instance
 
-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:
+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:
 
-- 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.
+- Is the Application Gateway instance that the AGIC add-on is associated with deployed in the `MC_*` node resource group?
+- Does the Application Gateway instance that the AGIC add-on is associated with have the tag `created-by: ingress-appgw`? AGIC uses the tag to determine whether or not the add-on deployed the 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 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 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.
+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 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 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:
 
 ```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
+## 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 the add-on, or want to enable the add-on using an existing Application Gateway and AKS cluster, then run the following command:
+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") 
@@ -46,5 +46,5 @@ az aks enable-addons -n <AKS-cluster-name> -g <AKS-cluster-resource-group> -a in
 
 ## Related content
 
-- 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).
+- 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).