AWS EKS下Kubernetes LoadBalancer无法外部访问（frontend异常，2048正常）

对比同集群正常运行的2048应用配置，frontend对应LoadBalancer无法外网访问的核心原因如下：

• 容器实际监听端口与配置暴露端口不匹配
  使用的kodekloud/webapp-color:v2镜像内置Web服务默认监听8080端口，且容器以非root用户运行，无权限绑定80这类1024以下的特权端口。但Deployment配置将containerPort设为80，Service的targetPort也指向80，导致AWS侧创建的LoadBalancer将流量转发到目标80端口时，因无对应进程监听触发连接拒绝，最终表现为LoadBalancer DNS访问失败。
  同集群正常运行的2048应用，使用的alexwhen/docker-2048镜像内置Web服务默认监听80端口，与配置端口完全匹配，因此流量可正常连通。
• 缺失就绪探针导致Pod假就绪
  frontend Deployment未配置readinessProbe，Kubernetes仅通过容器运行状态判断Pod是否就绪，不会校验配置端口的连通性。即使Pod内服务未在80端口正常监听，只要容器处于Running状态，就会被纳入Service的可用后端列表，造成全资源状态正常、但实际流量不通的假象。
  2048应用虽也未配置探针，但因端口配置与实际监听端口匹配，不存在假就绪问题。
• 并行配置LoadBalancer Service与ALB Ingress未改变核心故障点
  为frontend应用同时创建type=LoadBalancer的Service和基于ALB的Ingress时，AWS侧会分别独立创建两类负载均衡实例：Service对应创建传统ELB，Ingress对应创建ALB。两个实例的后端均指向同一组Pod，因Pod端口配置错误，两个路径的流量均会连通失败，与单独访问LoadBalancer DNS失败的表现一致。2048应用虽也并行配置了两类负载均衡资源，但因端口配置正确，两类流量路径均可用。

• 对齐端口配置：要么将Deployment的containerPort、Service的targetPort调整为8080，匹配镜像默认监听端口；要么修改容器启动参数指定Web服务监听80端口，同时配置securityContext授予容器绑定特权端口的权限。
• 为Deployment补充readinessProbe，基于实际监听端口配置连通性检测，消除假就绪导致的排查盲区。

内容的提问来源于stack exchange，提问作者user890234