Add doc updates (#3347)

* add several doc updates

* reword per comments

Author: oliviassss

docs/guide/ingress/spec.md

@@ -1,6 +1,12 @@
 # Ingress specification
 This document covers how ingress resources work in relation to The AWS Load Balancer Controller.
 
+!!!note ""
+    - Beginning from v2.4.3 of the AWS LBC, rules are ordered as follows:  
+        - `pathType: Exact` paths are always ordered first 
+        - followed by `pathType: Prefix` paths, with the longest prefix first
+        - followed by `pathType: ImplementationSpecific` paths, in the order they are listed in the manifest
+
 An example ingress, from [example](../../examples/2048/2048_full.yaml) is as follows.
 
 ```yaml

docs/guide/service/annotations.md

@@ -480,6 +480,10 @@ Load balancer access can be controlled via following annotations:
         ```
 
 ## Legacy Cloud Provider
-The AWS Load Balancer Controller manages Kubernetes Services in a compatible way with the legacy aws cloud provider. The annotation `service.beta.kubernetes.io/aws-load-balancer-type` is used to determine which controller reconciles the service. If the annotation value is `nlb-ip` or `external`, legacy cloud provider ignores the service resource (provided it has the correct patch) so that the AWS Load Balancer controller can take over. For all other values of the annotation, the legacy cloud provider will handle the service. Note that this annotation should be specified during service creation and not edited later.
+The AWS Load Balancer Controller manages Kubernetes Services in a compatible way with the AWS cloud provider's legacy service controller.
 
-The legacy cloud provider patch was added in Kubernetes v1.20 and is backported to Kubernetes v1.18.18+, v1.19.10+.
+- For users on v2.5.0+, The AWS LBC provides a mutating webhook for service resources to set the `spec.loadBalancerCLass` field for Serive of type LoadBalancer, effectively making the AWS LBC the default controller for Service of type LoadBalancer. 
+  Users can disable this feature and revert to using the AWS Cloud Controller Manager as the default service controller by setting the helm chart value `enableServiceMutatorWebhook` to false with `--set enableServiceMutatorWebhook=false` .
+- For users on older versions, the annotation `service.beta.kubernetes.io/aws-load-balancer-type` is used to determine which controller reconciles the service. If the annotation value is `nlb-ip` or `external`,
+  recent versions of the legacy cloud provider ignore the Service resource so that the AWS LBC can take over. For all other values of the annotation, the legacy cloud provider will handle the service. 
+  Note that this annotation should be specified during service creation and not edited later. Support for the annotation was added to the legacy cloud provider in Kubernetes v1.20, and is backported to v1.18.18+ and v1.19.10+.

docs/guide/service/nlb.md

@@ -161,7 +161,8 @@ service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
 See [Subnet Discovery](../../deploy/subnet_discovery.md) for details on configuring Elastic Load Balancing for public or private placement.
 
 ## Security group
-AWS doesn't support attaching security groups to NLBs. To allow inbound traffic from an NLB, the controller automatically adds inbound rules to the worker node security groups, by default.
+ - From v2.6.0, the AWS LBC creates and attaches frontend and backend security groups to NLB by default. For more information please see [the security groups documentation](../../deploy/security_groups.md) 
+ - In older versions, the controller by default adds inbound rules to the worker node security groups, to allow inbound traffic from an NLB.
 
 !!! tip "disable worker node security group rule management"
     You can disable the worker node security group rule management using an [annotation](./annotations.md#manage-backend-sg-rules).

helm/aws-load-balancer-controller/README.md

@@ -22,7 +22,11 @@ AWS Load Balancer controller manages the following AWS resources
 As a security best practice, we recommend isolating the controller deployment pods to specific node groups which run critical components. The helm chart provides parameters ```nodeSelector```, ```tolerations``` and ```affinity``` to configure node isolation. For more information, please refer to the guidance [here](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/#isolating-tenant-workloads-to-specific-nodes).
 
 ## Prerequisites
-- Kubernetes >= 1.19
+- Supported Kubernetes Versions 
+  - Chart version v1.5.0+ requires Kubernetes 1.22+
+  - Chart version v1.4.0+ requires Kubernetes 1.19+
+  - Chart version v1.2.0 - v1.3.3 supports Kubernetes 1.16-1.21
+  - Chart version v1.1.6 and before supports Kubernetes 1.15
 - IAM permissions
 - Helm v3
 - Optional dependencies