acrolinx

Author: greg-lindsay

articles/application-gateway/for-containers/application-gateway-for-containers-components.md

@@ -12,7 +12,7 @@ ms.author: greglin
 
 # Application Gateway for Containers components
 
-This article provides detailed descriptions and requirements for components of Application Gateway for Containers. Information about how Application Gateway for Containers accepts incoming requests and routes them to a backend target is provided.  For a general overview of Application Gateway for Containers, see [What is Application Gateway for Containers](overview.md).
+This article provides detailed descriptions and requirements for components of Application Gateway for Containers. Information about how Application Gateway for Containers accepts incoming requests and routes them to a backend target is provided. For a general overview of Application Gateway for Containers, see [What is Application Gateway for Containers](overview.md).
 
 ### Core components
 
@@ -25,55 +25,55 @@ This article provides detailed descriptions and requirements for components of A
 
 - An Application Gateway for Containers frontend resource is an Azure child resource of the Application Gateway for Containers parent resource.
 - An Application Gateway for Containers frontend defines the entry point client traffic should be received by a given Application Gateway for Containers.
-  - A frontend can't be associated to multiple Application Gateway for Containers
-  - Each frontend provides a unique FQDN that can be referenced by a customer's CNAME record
-  - Private IP addresses are currently unsupported
-- A single Application Gateway for Containers can support multiple frontends
+  - A frontend can't be associated to multiple Application Gateway for Containers.
+  - Each frontend provides a unique FQDN that can be referenced by a customer's CNAME record.
+  - Private IP addresses are currently unsupported.
+- A single Application Gateway for Containers can support multiple frontends.
 
 ### Application Gateway for Containers associations
 
 - An Application Gateway for Containers association resource is an Azure child resource of the Application Gateway for Containers parent resource.
-- An Application Gateway for Containers association defines a connection point into a virtual network.  An association is a 1:1 mapping of an association resource to an Azure Subnet that has been delegated.
-- Application Gateway for Containers is designed to allow for multiple associations
-  - At this time, the current number of associations is currently limited to 1
-- During creation of an association, the underlying data plane is provisioned and connected to a subnet within the defined virtual network's subnet
+- An Application Gateway for Containers association defines a connection point into a virtual network. An association is a 1:1 mapping of an association resource to an Azure Subnet that has been delegated.
+- Application Gateway for Containers is designed to allow for multiple associations.
+  - At this time, the current number of associations is currently limited to 1.
+- During creation of an association, the underlying data plane is provisioned and connected to a subnet within the defined virtual network's subnet.
 - Each association should assume at least 256 addresses are available in the subnet at time of provisioning.
   - A minimum /24 subnet mask for each deployment (assuming no resources have previously been provisioned in the subnet).
     - If n number of Application Gateway for Containers are provisioned, with the assumption each Application Gateway for Containers contains one association, and the intent is to share the same subnet, the available required addresses should be n*256.
-  - All Application Gateway for Containers association resources should match the same region as the Application Gateway for Containers parent resource
+  - All Application Gateway for Containers association resources should match the same region as the Application Gateway for Containers parent resource.
 
 ### Application Gateway for Containers ALB Controller
 
-- An Application Gateway for Containers ALB Controller is a Kubernetes deployment that orchestrates configuration and deployment of Application Gateway for Containers by watching Kubernetes both Custom Resources and Resource configurations, such as, but not limited to, Ingress, Gateway, and ApplicationLoadBalancer.  It uses both ARM / Application Gateway for Containers configuration APIs to propagate configuration to the Application Gateway for Containers Azure deployment.
-- ALB Controller is deployed / installed via Helm
-- ALB Controller consists of two running pods
-  - alb-controller pod is responsible for orchestrating customer intent to Application Gateway for Containers load balancing configuration
-  - alb-controller-bootstrap pod is responsible for management of CRDs
+- An Application Gateway for Containers ALB Controller is a Kubernetes deployment that orchestrates configuration and deployment of Application Gateway for Containers by watching Kubernetes both Custom Resources and Resource configurations, such as, but not limited to, Ingress, Gateway, and ApplicationLoadBalancer. It uses both ARM / Application Gateway for Containers configuration APIs to propagate configuration to the Application Gateway for Containers Azure deployment.
+- ALB Controller is deployed / installed via Helm.
+- ALB Controller consists of two running pods.
+  - alb-controller pod is responsible for orchestrating customer intent to Application Gateway for Containers load balancing configuration.
+  - alb-controller-bootstrap pod is responsible for management of CRDs.
 
 ## Azure / general concepts
 
 ### Private IP address
 
-- A private IP address isn't explicitly defined as an Azure Resource Manager resource.  A private IP address would refer to a specific host address within a given virtual network's subnet.
+- A private IP address isn't explicitly defined as an Azure Resource Manager resource. A private IP address would refer to a specific host address within a given virtual network's subnet.
 
 ### Subnet delegation
 
 - Microsoft.ServiceNetworking/trafficControllers is the namespace adopted by Application Gateway for Containers and may be delegated to a virtual network's subnet.
 - When delegation occurs, provisioning of Application Gateway for Containers resources doesn't happen, nor is there an exclusive mapping to an Application Gateway for Containers association resource.
-- Any number of subnets can have a subnet delegation that is the same or different to Application Gateway for Containers.  Once defined, no other resources, other than the defined service, can be provisioned into the subnet unless explicitly defined by the service's implementation.
+- Any number of subnets can have a subnet delegation that is the same or different to Application Gateway for Containers. Once defined, no other resources, other than the defined service, can be provisioned into the subnet unless explicitly defined by the service's implementation.
 
 ### User-assigned managed identity
 
 - Managed identities for Azure resources eliminate the need to manage credentials in code.
-- A User Managed Identity is required for each Azure Load Balancer Controller to make changes to Application Gateway for Containers
+- A User Managed Identity is required for each Azure Load Balancer Controller to make changes to Application Gateway for Containers.
 - _AppGw for Containers Configuration Manager_ is a built-in RBAC role that allows ALB Controller to access and configure the Application Gateway for Containers resource.
 
  > [!Note]
 > The _AppGw for Containers Configuration Manager_ role has [data action permissions](../../role-based-access-control/role-definitions.md#control-and-data-actions) that the Owner and Contributor roles do not have. It is critical proper permissions are delegated to prevent issues with ALB Controller making changes to the Application Gateway for Containers service.
 
 ## How Application Gateway for Containers accepts a request
 
-Each Application Gateway for Containers frontend provides a generated Fully Qualified Domain Name managed by Azure.  The FQDN may be used as-is or customers may opt to mask the FQDN with a CNAME record.
+Each Application Gateway for Containers frontend provides a generated Fully Qualified Domain Name managed by Azure. The FQDN may be used as-is or customers may opt to mask the FQDN with a CNAME record.
 
 Before a client sends a request to Application Gateway for Containers, the client resolves a CNAME that points to the frontend's FQDN; or the client may directly resolve the FQDN provided by Application Gateway for Containers by using a DNS server.
 
@@ -87,7 +87,7 @@ A set of routing rules evaluates how the request for that hostname should be ini
 
 ### HTTP/2 Requests
 
-Application Gateway for Containers fully supports HTTP/2 protocol for communication from the client to the frontend. Communication from Application Gateway for Containers to the backend target uses the HTTP/1.1 protocol. The HTTP/2 setting is always enabled and cannot be changed. If clients prefer to use HTTP/1.1 for their communication to the frontend of Application Gateway for Containers, they may continue to negotiate accordingly.
+Application Gateway for Containers fully supports HTTP/2 protocol for communication from the client to the frontend. Communication from Application Gateway for Containers to the backend target uses the HTTP/1.1 protocol. The HTTP/2 setting is always enabled and can't be changed. If clients prefer to use HTTP/1.1 for their communication to the frontend of Application Gateway for Containers, they may continue to negotiate accordingly.
 
 ### Modifications to the request
 
@@ -97,9 +97,9 @@ Application Gateway for Containers inserts three extra headers to all requests b
 - x-forwarded-proto
 - x-request-id
 
-**x-forwarded-for** is the original requestor's client IP address.  If the request is coming through a proxy, the header value appends the address received, comma delimited.  In example: 1.2.3.4,5.6.7.8; where 1.2.3.4 is the client IP address to the proxy in front of Application Gateway for Containers, and 5.6.7.8 is the address of the proxy forwarding traffic to Application Gateway for Containers.
+**x-forwarded-for** is the original requestor's client IP address. If the request is coming through a proxy, the header value appends the address received, comma delimited. In example: 1.2.3.4,5.6.7.8; where 1.2.3.4 is the client IP address to the proxy in front of Application Gateway for Containers, and 5.6.7.8 is the address of the proxy forwarding traffic to Application Gateway for Containers.
 
-**x-forwarded-proto** returns the protocol received by Application Gateway for Containers from the client.  The value is either http or https.
+**x-forwarded-proto** returns the protocol received by Application Gateway for Containers from the client. The value is either http or https.
 
 **x-request-id** is a unique guid generated by Application Gateway for Containers for each client request and presented in the forwarded request to the backend target. The guid consists of 32 alphanumeric characters, separated by dashes (for example: d23387ab-e629-458a-9c93-6108d374bc75). This guid can be used to correlate a request received by Application Gateway for Containers and initiated to a backend target as defined in access logs.
 

articles/application-gateway/for-containers/overview.md

@@ -80,7 +80,7 @@ Application Gateway for Containers supports the following features for traffic m
 
 There are two deployment strategies for management of Application Gateway for Containers:
 
-- **Bring your own (BYO) deployment:** In this deployment strategy, deployment and lifecycle of the Application Gateway for Containers resource, Association and Frontend resource is assumed via Azure portal, CLI, PowerShell, Terraform, etc. and referenced in configuration within Kubernetes.
+- **Bring your own (BYO) deployment:** In this deployment strategy, deployment and lifecycle of the Application Gateway for Containers resource, Association, and Frontend resource is assumed via Azure portal, CLI, PowerShell, Terraform, etc. and referenced in configuration within Kubernetes.
   - **In Gateway API:** Every time you wish to create a new Gateway resource in Kubernetes, a Frontend resource should be provisioned in Azure prior and referenced by the Gateway resource. Deletion of the Frontend resource is responsible by the Azure administrator and isn't deleted when the Gateway resource in Kubernetes is deleted.
 - **Managed by ALB Controller:** In this deployment strategy ALB Controller deployed in Kubernetes is responsible for the lifecycle of the Application Gateway for Containers resource and its sub resources. ALB Controller creates Application Gateway for Containers resource when an ApplicationLoadBalancer custom resource is defined on the cluster and its lifecycle is based on the lifecycle of the custom resource.
   - **In Gateway API:** Every time a Gateway resource is created referencing the ApplicationLoadBalancer resource, ALB Controller provisions a new Frontend resource and manage its lifecycle based on the lifecycle of the Gateway resource.
@@ -112,7 +112,7 @@ Application Gateway for Containers is currently offered in the following regions
 
 ### Implementation of Gateway API
 
-ALB Controller implements version [v1](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1) of the [Gateway API](https://gateway-api.sigs.k8s.io/)
+ALB Controller implements version [v1](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1) of the [Gateway API](https://gateway-api.sigs.k8s.io/).
 
 | Gateway API Resource      | Support | Comments     |
 | ------------------------- | ------- | ------------ |
@@ -123,7 +123,7 @@ ALB Controller implements version [v1](https://gateway-api.sigs.k8s.io/reference
 
 ### Implementation of Ingress API
 
-ALB Controller implements support for [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
+ALB Controller implements support for [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
 
 | Ingress API Resource      | Support | Comments     |
 | ------------------------- | ------- | ------------ |