I found the answer here. A faragate deployment requires the region and vpc-id.

helm upgrade -i aws-load-balancer-controller eks/aws-load-balancer-controller \
    --set clusterName=<cluster-name> \
    --set serviceAccount.create=false \
    --set region=<region-code> \
    --set vpcId=<vpc-xxxxxxxx>> \
    --set serviceAccount.name=aws-load-balancer-controller \
    -n kube-system

From the current LB conntroller manifest I found out that LB controller Pod specification doesn't have Readiness probe, only Liveness probe. That means that the Pod becomes Ready as soon as it pass the Liveness probe:

      livenessProbe:
        failureThreshold: 2
        httpGet:
          path: /healthz
          port: 61779
          scheme: HTTP
        initialDelaySeconds: 30
        timeoutSeconds: 10

But as we can see in the following output, LB controller's Pod is in Pending state:

[ec2-user@ip-X-X-X-X eks-cluster]$ kubectl get pods -n kube-system
NAME                                            READY   STATUS    RESTARTS   AGE
aws-load-balancer-controller-XXXXXXXXXX-p4l7f   0/1     Pending   0          30m

If Pod stays in Pending state, it means that kube-scheduler is unable to bind the Pod to a cluster node for whatever reason.

Kube-scheduler is a part of Kubernetes control plain that is responsible for assigning Pods to Nodes.

No Pod logs exist at this phase, because Pod's containers are not started yet.

The most convenient way to check the reason is using the kubectl describe command:

kubectl describe pod/podname -n namespacename

On the bottom of the output there are list of events related to the Pod life cycle. Here is an example for the generic Ubuntu Pod:

Events:
  Type    Reason     Age                From               Message
  ----    ------     ----               ----               -------
  Normal  Scheduled  37s                default-scheduler  Successfully assigned default/ubuntu to k8s-w1
  Normal  Pulling    25s (x2 over 35s)  kubelet, k8s-w1    Pulling image "ubuntu"
  Normal  Pulled     23s (x2 over 30s)  kubelet, k8s-w1    Successfully pulled image "ubuntu"
  Normal  Created    23s (x2 over 30s)  kubelet, k8s-w1    Created container ubuntu
  Normal  Started    23s (x2 over 29s)  kubelet, k8s-w1    Started container ubuntu

kubectl get events command can also show the problem. For example:

LAST SEEN   TYPE     REASON      OBJECT       MESSAGE
21s         Normal   Scheduled   pod/ubuntu   Successfully assigned default/ubuntu to k8s-w1
9s          Normal   Pulling     pod/ubuntu   Pulling image "ubuntu"
7s          Normal   Pulled      pod/ubuntu   Successfully pulled image "ubuntu"
7s          Normal   Created     pod/ubuntu   Created container ubuntu
7s          Normal   Started     pod/ubuntu   Started container ubuntu

or there could be a reason why Scheduler can't assign Pod to a Node:

"No nodes are available that match all of the predicates: Insufficient cpu (2), Insufficient memory (2)". 

In some cases errors could be found in kube-scheduler Pod logs in kube-system namespace. The logs could be listed using the following command:

kubectl logs $(kubectl get pods -l component=kube-scheduler,tier=control-plane -n kube-system -o name) -n kube-system 

Most common reasons why pod isn't scheduled are the following:

• lack of CPU or memory resources requested by a Pod on the Nodes.
• Pod cannot tolerate Taints on the Nodes
• Pod have Affinity/AntiAffinity configuration that prevents it from scheduling
• Storage or other specific resource (like GPU) requirements in Pod spec cannot be satisfied