Merge branch 'MicrosoftDocs:main' into main

Author: eak13

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

@@ -13,6 +13,9 @@ ms.author: greglin
 
 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.
 
+> [!TIP]
+> Consider [Application Gateway for Containers](for-containers/overview.md) for your Kubernetes ingress solution. For more information, see [Custom health probe for Application Gateway for Containers](for-containers/custom-health-probe.md).
+
 ## Code for adding a readiness or liveness probe
 
 ```yaml
@@ -68,4 +71,4 @@ Any property that the readiness or liveness probe can't infer uses the following
 
 ## Related content
 
-- [What is Application Gateway for Containers?](for-containers/overview.md)
+- [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 back-end pods by using Application Gateway metrics and the Azure Kubernetes Metrics Adapter.
+description: This article provides instructions on how to scale your AKS backend pods by using Application Gateway metrics and the Azure Kubernetes Metrics Adapter.
 services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
@@ -14,7 +14,7 @@ ms.author: greglin
 
 As incoming traffic increases, it becomes crucial to scale up your applications based on the demand.
 
-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.
+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 backend pool and a backend HTTP setting.
 
 Use the following two components:
 
@@ -24,9 +24,12 @@ Use the following two components:
 > [!NOTE]
 > The Azure Kubernetes Metrics Adapter is no longer maintained. Kubernetes Event-driven Autoscaling (KEDA) is an alternative.
 
+> [!TIP]
+> Consider [Application Gateway for Containers](for-containers/overview.md) for your Kubernetes ingress solution. For more information, see [Scaling and availability for Application Gateway for Containers](for-containers/scaling-zone-resiliency.md).
+
 ## Set up the Azure Kubernetes Metrics Adapter
 
-1. Create a Microsoft Entra service principal and assign it `Monitoring Reader` access over the Application Gateway instance's resource group:
+1. Create a Microsoft Entra service principal and assign it `Monitoring Reader` access over the Application Gateway deployment's resource group:
 
     ```azurecli
     applicationGatewayGroupName="<application-gateway-group-id>"
@@ -46,7 +49,7 @@ Use the 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 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.
+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 backend pool and backend HTTP setting in the Application Gateway deployment.
 
     ```yaml
     apiVersion: azure.com/v1alpha2
@@ -56,8 +59,8 @@ Use the following two components:
     spec:
         type: azuremonitor
         azure:
-            resourceGroup: myResourceGroup # replace with your Application Gateway instance's resource group name
-            resourceName: myApplicationGateway # replace with your Application Gateway instance's name
+            resourceGroup: myResourceGroup # replace with your Application Gateway deployment's resource group name
+            resourceName: myApplicationGateway # replace with your Application Gateway deployment's name
             resourceProviderNamespace: Microsoft.Network
             resourceType: applicationGateways
         metric:
@@ -123,7 +126,7 @@ Test your setup by using a load test tool like ApacheBench:
 ab -n10000 http://<applicaiton-gateway-ip-address>/
 ```
 
-## Next steps
+## Related content
 
 - [Troubleshoot Application Gateway Ingress Controller issues](ingress-controller-troubleshoot.md)
-- [What is Application Gateway for Containers?](for-containers/overview.md)
+- [Application Gateway for Containers](for-containers/overview.md)

articles/application-gateway/ingress-controller-cookie-affinity.md

@@ -13,6 +13,9 @@ ms.author: greglin
 
 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.
 
+> [!TIP]
+> Consider [Application Gateway for Containers](for-containers/overview.md) for your Kubernetes ingress solution. For more information, see [Application Gateway for Containers session affinity overview](for-containers/session-affinity.md).
+
 ## Example
 
 ```yaml
@@ -34,4 +37,4 @@ spec:
 
 ## Related content
 
-- [What is Application Gateway for Containers?](for-containers/overview.md)
+- [Application Gateway for Containers](for-containers/overview.md)

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

@@ -13,31 +13,34 @@ ms.author: greglin
 
 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.
+The life cycle of the Azure Application Gateway deployment differs when you disable the AGIC add-on, depending on whether you created the Application Gateway deployment 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 deployment.
 
-## Disable the AGIC add-on with an associated Application Gateway instance
+> [!TIP]
+> Consider [Application Gateway for Containers](for-containers/overview.md) for your Kubernetes ingress solution.
+
+## Disable the AGIC add-on with an associated Application Gateway deployment
 
-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 the AGIC add-on automatically deployed Application Gateway for you when you first set up everything, then disabling the AGIC add-on might delete the Application Gateway deployment by default. The AGIC add-on considers two criteria to determine if it should delete the associated Application Gateway deployment:
 
-- 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.
+- Is Application Gateway deployed in the `MC_*` node resource group?
+- Does the Application Gateway deployment have the tag `created-by: ingress-appgw`? AGIC uses the tag to determine whether or not the add-on deployed 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 both criteria are met, the AGIC add-on deletes the Application Gateway deployment 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 Application Gateway.
 
-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.
+If the first criterion isn't met, disabling the add-on doesn't delete the Application Gateway deployment, even if the deployment has the `created-by: ingress-appgw` tag. Likewise, if the second criterion isn't met (that is, the Application Gateway deployment lacks that tag), disabling the add-on doesn't delete the Application Gateway deployment 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.
+> If you don't want the add-on to delete your Application Gateway deployment when you disable the add-on, but the deployment 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 the AGIC add-on on an existing Application Gateway instance and AKS cluster
+## Enable the AGIC add-on on an existing Application Gateway deployment 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:
+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 deployment 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 +49,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 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).
+- For more information on how to enable the AGIC add-on by using an existing Application Gateway deployment and AKS cluster, see [this tutorial](tutorial-ingress-controller-add-on-existing.md).
+- For information about Application Gateway for Containers, see [this overview article](for-containers/overview.md).

articles/application-gateway/ingress-controller-expose-service-over-http-https.md

@@ -14,16 +14,19 @@ ms.author: greglin
 
 This article illustrates the usage of [Kubernetes ingress resources](https://kubernetes.io/docs/concepts/services-networking/ingress/) to expose an example Azure Kubernetes Service (AKS) service through [Azure Application Gateway](https://azure.microsoft.com/services/application-gateway/) over HTTP or HTTPS.
 
+> [!TIP]
+> Consider [Application Gateway for Containers](for-containers/overview.md) for your Kubernetes ingress solution.
+
 ## Prerequisites
 
 - An installed `ingress-azure` Helm chart:
   - [Greenfield deployment](ingress-controller-install-new.md): If you're starting from scratch, refer to these installation instructions, which outline steps to deploy an AKS cluster with Application Gateway and install the Application Gateway Ingress Controller (AGIC) on the AKS cluster.
-  - [Brownfield deployment](ingress-controller-install-existing.md): If you have an existing AKS cluster and Application Gateway instance, refer to these instructions to install AGIC on the AKS cluster.
+  - [Brownfield deployment](ingress-controller-install-existing.md): If you have an existing AKS cluster and Application Gateway deployment, refer to these instructions to install AGIC on the AKS cluster.
 - An x509 certificate and its private key, if you want to use HTTPS on this application.
 
 ## Deploy the guestbook application
 
-The `guestbook` application is a canonical Kubernetes application that consists of a web UI front end, a back end, and a Redis database.
+The `guestbook` application is a canonical Kubernetes application that consists of a web UI frontend, a backend, and a Redis database.
 
 By default, `guestbook` exposes its application through a service with the name `frontend` on port `80`. Without a Kubernetes ingress resource, the service isn't accessible from outside the AKS cluster. You use the application, and set up ingress resources to access the application, through HTTP and HTTPS.
 
@@ -56,7 +59,7 @@ spec:
           servicePort: 80
 ```
 
-This ingress exposes the `frontend` service of the `guestbook-all-in-one` deployment as a default back end of the Application Gateway instance.
+This ingress exposes the `frontend` service of the `guestbook-all-in-one` deployment as a default backend of the Application Gateway deployment.
 
 Save the preceding ingress resource as `ing-guestbook.yaml`:
 
@@ -68,13 +71,13 @@ Save the preceding ingress resource as `ing-guestbook.yaml`:
 
 1. Check the log of the ingress controller for the deployment status.
 
-Now the `guestbook` application should be available. You can check the availability by visiting the public address of the Application Gateway instance.
+Now the `guestbook` application should be available. You can check the availability by visiting the public address of the Application Gateway deployment.
 
 ## Expose services over HTTPS
 
 ### Without a specified host name
 
-If you don't specify a host name, the `guestbook` service is available on all the host names that point to the Application Gateway instance.
+If you don't specify a host name, the `guestbook` service is available on all the host names that point to the Application Gateway deployment.
 
 1. Before you deploy the ingress resource, create a Kubernetes secret to host the certificate and private key:
 
@@ -177,4 +180,4 @@ spec:
 
 ## Related content
 
-- [What is Application Gateway for Containers?](for-containers/overview.md)
+- [Application Gateway for Containers](for-containers/overview.md)

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

@@ -13,6 +13,9 @@ ms.author: greglin
 
 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]
+> Consider [Application Gateway for Containers](for-containers/overview.md) for your Kubernetes ingress solution.
+
 ## 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:
@@ -73,7 +76,7 @@ spec:
               servicePort: 80
 ```
 
-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.
+Assuming that all the prerequisites are fulfilled, and you have an Application Gateway deployment 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 deployment's public IP address and the `ws.contoso.com` domain.
 
 The following cURL command would test the WebSocket server deployment:
 
@@ -98,4 +101,4 @@ To avoid the `502 Bad Gateway` error, you might need to add an HTTP `GET` handle
 
 ## Related content
 
-- [What is Application Gateway for Containers?](for-containers/overview.md)
+- [Application Gateway for Containers](for-containers/overview.md)