Situation#
A service looked healthy from inside the cluster, but traffic routed through the ALB kept failing health checks during deployment windows. The issue was not a single broken setting. It was drift between ingress assumptions, readiness behavior, and what the load balancer actually expected.
What I changed#
I traced the request path from Ingress to target group behavior, then tightened the interfaces between Kubernetes and AWS:
- aligned the health check path with what the application really exposed
- checked service-to-pod port mapping against ingress expectations
- made readiness behavior reflect external availability more accurately
- verified controller-created target group behavior instead of only reading manifests
Why it worked#
The problem stopped looking like "ALB is failing" and started looking like an interface mismatch between declared routing intent and runtime health semantics. Once those boundaries were made explicit, diagnosis got much faster and the rollout path became more predictable.
Operational result
The biggest win was not only the fix itself, but a calmer release path with fewer ambiguous failures during deployment.
Reusable lesson#
In EKS, ingress failures are often coordination failures across multiple control loops rather than one bad YAML field. The fastest path is usually to verify each boundary directly: Ingress, target group behavior, service mapping, pod readiness, and application path exposure.