Add doc updates

docs/guide/ingress/spec.md

@@ -1,6 +1,13 @@
 # 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 of `pathType: ImplementationSpecific` are always ordered according to the rule order in the manifest.
+    - However, in case of mixed path types,  
+        - `pathType: Exact` match are always ordered first 
+        - followed by `pathType: Prefix` paths with the longest prefix first
+        - `pathType: ImplementationSpecific` paths in the order from 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 legacy aws cloud provider.
 
-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 the serive of type LoadBalancer, which makes the AWS LBC the default controller for service of type LoadBalancer. 
+  Users can disable this feature and revert to set Cloud Controller Manager (in-tree controller) as the default 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`, 
+  legacy cloud provider ignores the service resource (provided it has the correct patch) 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. The legacy cloud provider patch was added in Kubernetes v1.20 and is backported to Kubernetes v1.18.18+, 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 check [here](../../deploy/security_groups.md) 
+ - For users on 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.16 and before supports Kubernetes 1.15
 - IAM permissions
 - Helm v3
 - Optional dependencies