Yep, we (Basecamp) have been bit by this with EKS too. By default the ALB Ingress Controller will put all cluster nodes into the target group and a request can hit kube-proxy in any AZ before being directed to the right place, causing a lot of inter-AZ traffic churn. It's mildly annoying.
(with alb-ingress-controller you can change target-type to IP to have traffic go direct to pods that will actually back a given service instead of via kube-proxy on a random node, but the big fault there is that if alb-ingress-controller gets hung up on something and you deploy, you can send traffic to nowhere because the target group still has old IPs for pods that don't exist).
Yep, we (Basecamp) have been bit by this with EKS too. By default the ALB Ingress Controller will put all cluster nodes into the target group and a request can hit kube-proxy in any AZ before being directed to the right place, causing a lot of inter-AZ traffic churn. It's mildly annoying.
(with alb-ingress-controller you can change target-type to IP to have traffic go direct to pods that will actually back a given service instead of via kube-proxy on a random node, but the big fault there is that if alb-ingress-controller gets hung up on something and you deploy, you can send traffic to nowhere because the target group still has old IPs for pods that don't exist).