Acrolinx

Author: JackStromberg

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

@@ -10,7 +10,7 @@ ms.author: greglin
 ---
 
 # Add Health Probes to your service
-By default, Ingress controller will provision an HTTP GET probe for the exposed pods.
+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.
 
 > [!TIP]

articles/application-gateway/ingress-controller-annotations.md

@@ -287,7 +287,7 @@ spec:
 
 ## Request Timeout
 
-Use the following annotation to specify the request timeout in seconds. After the timeout, Application Gateway fails a request if the response is not received.
+Use the following annotation to specify the request timeout in seconds. After the timeout, Application Gateway fails a request if the response isn't received.
 
 ### Usage
 

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

@@ -10,17 +10,17 @@ 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 will differ 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.
+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.
 
 > [!TIP]
 > Also see [What is Application Gateway for Containers](for-containers/overview.md).
 
 ## Disabling AGIC add-on with associated Application Gateway 
-If the AGIC add-on automatically deployed the Application Gateway for you when you first set everything up, 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 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 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 is not 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 is not met, i.e. the Application Gateway lacks that tag, then disabling the add-on won't delete the Application Gateway in the MC_* node resource group. 
+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. 
 
 > [!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. 
@@ -39,4 +39,4 @@ az aks enable-addons -n <AKS-cluster-name> -g <AKS-cluster-resource-group> -a in
 ```
 
 ## Next steps
-For more details 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 using an existing Application Gateway and AKS cluster, see [AGIC add-on brownfield deployment](tutorial-ingress-controller-add-on-existing.md).

articles/application-gateway/ingress-controller-install-existing.md

@@ -413,8 +413,7 @@ Since Helm with `appgw.shared=true` and the default `prohibit-all-targets` block
 
 Let's assume that we already have a working AKS cluster, Application Gateway, and configured AGIC in our cluster. We have an Ingress for
 `prod.contoso.com` and are successfully serving traffic for it from the cluster. We want to add `staging.contoso.com` to our
-existing Application Gateway, but need to host it on a [VM](https://azure.microsoft.com/services/virtual-machines/). We
-are going to reuse the existing Application Gateway and manually configure a listener and backend pools for
+existing Application Gateway, but need to host it on a [VM](https://azure.microsoft.com/services/virtual-machines/). We're going to reuse the existing Application Gateway and manually configure a listener and backend pools for
 `staging.contoso.com`. But manually tweaking Application Gateway config (using
 [portal](https://portal.azure.com), [ARM APIs](/rest/api/resources/) or
 [Terraform](https://www.terraform.io/)) would conflict with AGIC's assumptions of full ownership. Shortly after we apply

articles/application-gateway/ingress-controller-install-new.md

@@ -13,7 +13,7 @@ ms.author: greglin
 # How to Install an Application Gateway Ingress Controller (AGIC) Using a New Application Gateway
 
 The instructions below assume Application Gateway Ingress Controller (AGIC) will be
-installed in an environment with no pre-existing components.
+installed in an environment with no preexisting components.
 
 > [!TIP]
 > Also see [What is Application Gateway for Containers](for-containers/overview.md).
@@ -39,7 +39,7 @@ choose to use another environment, ensure the following command-line tools are i
 
 ## Create an Identity
 
-Follow the steps below to create a Microsoft Entra [service principal object](../active-directory/develop/app-objects-and-service-principals.md#service-principal-object). Record the `appId`, `password`, and `objectId` values - these values will be used in the following steps.
+Follow the steps below to create a Microsoft Entra [service principal object](../active-directory/develop/app-objects-and-service-principals.md#service-principal-object). Record the `appId`, `password`, and `objectId` values - these values are used in the following steps.
 
 1. Create AD service principal ([Read more about Azure RBAC](../role-based-access-control/overview.md)):
     ```azurecli
@@ -56,7 +56,7 @@ Follow the steps below to create a Microsoft Entra [service principal object](..
     ```
     The output of this command is `objectId`, which will be used in the Azure Resource Manager template below
 
-1. Create the parameter file that will be used in the Azure Resource Manager template deployment later.
+1. Create the parameter file that is used in the Azure Resource Manager template deployment later.
     ```bash
     cat <<EOF > parameters.json
     {
@@ -70,7 +70,7 @@ Follow the steps below to create a Microsoft Entra [service principal object](..
     To deploy an **Kubernetes RBAC** enabled cluster, set the `aksEnableRBAC` field to `true`
 
 ## Deploy Components
-This step will add the following components to your subscription:
+This step adds the following components to your subscription:
 
 - [Azure Kubernetes Service](/azure/aks/intro-kubernetes)
 - [Application Gateway](./overview.md) v2
@@ -112,7 +112,7 @@ With the instructions in the previous section, we created and configured a new A
 
 ### Set up Kubernetes Credentials
 For the following steps, we need setup [kubectl](https://kubectl.docs.kubernetes.io/) command,
-which we'll use to connect to our new Kubernetes cluster. [Cloud Shell](https://shell.azure.com/) has `kubectl` already installed. We'll use `az` CLI to obtain credentials for Kubernetes.
+which we use to connect to our new Kubernetes cluster. [Cloud Shell](https://shell.azure.com/) has `kubectl` already installed. We'll use `az` CLI to obtain credentials for Kubernetes.
 
 Get credentials for your newly deployed AKS ([read more](/azure/aks/manage-azure-rbac#use-azure-rbac-for-kubernetes-authorization-with-kubectl)):
 
@@ -150,7 +150,7 @@ To install Microsoft Entra Pod Identity to your cluster:
      ```
 
 ### Install Helm
-[Helm](/azure/aks/kubernetes-helm) is a package manager for Kubernetes. We'll use it to install the `application-gateway-kubernetes-ingress` package.
+[Helm](/azure/aks/kubernetes-helm) is a package manager for Kubernetes. We use it to install the `application-gateway-kubernetes-ingress` package.
 
 > [!NOTE]
 > If you use [Cloud Shell](https://shell.azure.com/), you don't need to install Helm.  Azure Cloud Shell comes with Helm version 3. Skip the first step and just add the AGIC Helm repository.