AWS Load Balancer Controller

When an Ingress resource satisfying the controller's requirements is created, the controller automates the following AWS resource lifecycle:

1. ALB Creation: Creates an Application Load Balancer (ELBv2), which can be internet-facing or internal. Subnets can be specified via annotations.
2. Target Groups: Creates Target Groups for each unique Kubernetes service in the Ingress.
3. Listeners: Creates Listeners for every port in the Ingress. Defaults to 80 or 443 if not specified. Certificates can be attached via annotations.
4. Rules: Creates Listener Rules for each path to route traffic to the correct Kubernetes Service.

Note: Avoid out-of-band modifications to these AWS resources. The controller manages these configurations and may revert manual changes during reconciliation. Use Ingress/Service annotations, controller flags, or IngressClassParams for configuration instead.

The AWS Load Balancer Controller (LBC) automatically discovers subnets for NLB and ALB creation through a three-step process:

1. Candidate Subnet Determination:
   • If tag filters are specified (via IngressClassParams for Ingress), only matching subnets are candidates.
   • If no tag filters are specified, the controller looks for subnets with matching role tags or, for LBC version >= 2.12.1, subnets whose reachability (public/private) matches the LoadBalancer's schema.
2. Subnet Filtering:
   • Cluster Tag Check: Subnets must match the cluster name via kubernetes.io/cluster/<cluster-name> (can be disabled via SubnetsClusterTagCheck flag).
   • IP Availability: Subnets with fewer than 8 available IP addresses are filtered out.
3. Final Selection: The controller selects one subnet per availability zone based on priority (Cluster Tag match > Lexicographical Subnet ID).

The AWS Load Balancer controller supports Pod readiness gates to ensure a pod is registered to the ALB/NLB and healthy before Kubernetes considers it 'Ready'. This prevents rolling updates from terminating old pods before new pods are actually capable of receiving traffic.

Requirements:

1. Target Type: This feature only works when using target-type: ip. It does not work with target-type: instance because the ALB is not aware of individual pod health in that mode.
2. Namespace Labeling: You must apply the label elbv2.k8s.aws/pod-readiness-gate-inject: enabled to the pod's namespace.
3. Resource Order: To ensure all pods receive the configuration, you must create the Ingress or Service and label the namespace before creating the pods/deployments.

When active, the controller injects readiness gates with the prefix target-health.elbv2.k8s.aws into the pod spec during creation.

$ kubectl create namespace readiness
$ kubectl label namespace readiness elbv2.k8s.aws/pod-readiness-gate-inject=enabled

By default, the AWS Load Balancer Controller assumes full control over target groups and de-registers any targets not currently in the cluster. To allow a target group to be shared across multiple Kubernetes clusters or to support arbitrary targets from other sources, you must enable MultiCluster mode using specific annotations.

• For ALB (Ingress): Add the annotation alb.ingress.kubernetes.io/multi-cluster-target-group: "true" to your Ingress resource.
• For NLB (Service): Add the annotation service.beta.kubernetes.io/aws-load-balancer-multi-cluster-target-group: "true" to your Service resource.

When enabled, the controller takes a snapshot of the cluster state and stores it in a ConfigMap named aws-lbc-targets-$TARGET_GROUP_BINDING_NAME within the same namespace as your load balancer resources.

# Example ALB Ingress with MultiCluster enabled
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echoserver
  namespace: echoserver
  annotations:
    alb.ingress.kubernetes.io/multi-cluster-target-group: "true"
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/tags: Environment=dev,Team=test
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: echoserver
                port:
                  number: 80