AWS抗投诉服务器 AWS EKS Ingress 创建后 ALB 未生成？AWS Load Balancer Controller 日志排查
这个问题我在实际项目里见得最多的场景，不是“Ingress 配错了”这么简单，而是控制器没拿到创建权限、子网没识别、账号没过账单校验、IngressClass 不匹配几类问题叠在一起。很多人看到 Kubernetes 里 Ingress 已经创建成功，就默认 AWS 会自动出 ALB，结果等了十几分钟还是空的。
如果你现在的状态是：kubectl get ingress 有资源，但 EXTERNAL-IP 一直为空，AWS 控制台里也没有 ALB，建议不要先改 YAML，先看日志。大多数问题在日志里都能直接定位。
AWS抗投诉服务器 先判断：到底卡在哪一层
| 现象 | 常见原因 | 优先看哪里 |
|---|---|---|
| Ingress 已创建，ALB 不出现 | Controller 未运行 / 未识别 IngressClass / IAM 权限不足 | controller 日志、Pod 状态 |
| ALB 创建了一半又消失 | 子网标签不对、Security Group 冲突、目标组创建失败 | controller 日志、AWS CloudTrail |
| 一直提示 reconcile，但没有报错 | Ingress 注解不完整、监听器规则不满足、找不到可用子网 | controller 日志中的 discover / subnet / rule 相关信息 |
| 控制台能看到 ALB，外网访问不了 | 安全组、子网公网属性、目标组健康检查失败 | ALB 安全组、Target Group health check |
第一步：直接看 AWS Load Balancer Controller 日志
很多人只看 Kubernetes 事件，实际上真正有用的是控制器日志。先执行：
kubectl -n kube-system get pods | grep load-balancer kubectl -n kube-system logs deploy/aws-load-balancer-controller --tail=200
重点不是“有没有报错”，而是看报错类型。常见几类信息基本可以直接定因：
- AccessDenied：IAM 角色权限不够，或者 IRSA 没绑对。
- failed to auto-discover subnets：子网标签不对，控制器找不到可用子网。
- no matching subnet：公有/私有子网选择不符合你的 scheme。
- ingress class is not matched：IngressClass 名称和控制器不一致。
- could not build model：注解格式错误、目标端口/服务对象不对。
我建议你把日志里这 4 个关键词直接搜一遍：AccessDenied / subnet / ingress class / model。通常十分钟内就能把方向缩小到 1-2 个点。
最常见的 6 个真实原因，不是每个都要改 YAML
1）控制器没正常工作，或者装在错误的命名空间
有些团队 Helm 装完就结束，实际 Pod 处于 CrashLoop、ImagePullBackOff，或者 controller service account 绑定错了。表面上 Ingress 资源正常，实际上没人去监听它。
检查方式：
kubectl -n kube-system get deploy,pod,sa | grep load-balancer kubectl -n kube-system describe pod -l app.kubernetes.io/name=aws-load-balancer-controller
如果 Pod 没起来，先别折腾 Ingress，先修控制器。
2）IAM / IRSA 没配对，创建权限缺失
这是最容易被忽略的一项。AWS Load Balancer Controller 不是“自动有权限”，它需要明确的 IAM Policy 和 ServiceAccount 绑定。很多账号是从别人模板里复制过来的，OIDC 没建，或者 role ARN 指错，最后日志里就是一堆 AccessDenied。
重点看：
- 是否启用了 EKS OIDC provider
- ServiceAccount 是否绑定了正确的 IAM Role
- 策略里是否包含创建 ELB、TargetGroup、Listener、SecurityGroup 的权限
如果你看到日志类似 “not authorized to perform elasticloadbalancing:CreateLoadBalancer”，基本不用怀疑，先修权限。
AWS抗投诉服务器 3）子网标签不完整，控制器找不到能用的 Subnet
这是 ALB 不生成的高频原因。EKS 里的 Ingress 不是靠“子网存在”就行，而是要看标签是否符合控制器识别规则。很多人只创建了私有子网，忘了打标签，或者把公有/私有混着标。
典型问题：
- 没有打
kubernetes.io/cluster/cluster-name相关标签 - 公有子网缺少面向 ALB 的角色标签
- 私有子网被误用成公网入口
实际处理顺序：先确认 Ingress 想暴露公网还是内网，再去匹配子网标签，不要反着配。
4）IngressClass 或 annotation 写错，控制器压根没接单
很多案例不是 AWS 的问题，而是 Ingress 对象根本没交给 AWS Load Balancer Controller。比如你装了多个 ingress controller，Nginx 和 AWS 共存时，类名一旦不一致，就会出现“资源创建了，但没人处理”。
建议检查：
kubectl get ingressclass kubectl describe ingress your-ingress-name
确保 ingressClassName 和实际 controller 对得上。老项目里还常见只写了 annotation，没写 ingressClassName，导致新版本行为不一致。
5）Service 后端端口、Target Type、健康检查不匹配
ALB 能创建出来，但 Target Group 不健康时，表面看像“没生成”。尤其是：
- Service 端口和容器监听端口不一致
- 注解里 target-type 选了 ip，却实际网络/安全组没放通
- 健康检查路径返回 404 或 301，导致全部 unhealthy
这种问题的特征是：ALB 在控制台里能看到，但流量进不来。不要只盯 Ingress，要去看 Target Group health。
6）账号层面被账单、验证或风控卡住
这个是很多人搜索时忽略的点。尤其是新开 AWS 账号，账号没完成付款方式验证、账单状态异常、额度受限，都可能导致资源创建失败或延迟。
我实际遇到过几种情况：
- 新号绑定了卡，但未完成验证，控制器一直报创建失败
- 账号有历史欠费，EKS 集群还在，ALB 新建被限制
- 企业账号审批没走完，IAM 权限看似有，实际被 SCP 拦截
如果你的日志里没有明显权限错误，但 AWS 控制台创建 ALB 一直失败，建议同步检查账单中心、付款方式、组织策略，不要只在集群里排查。
账号开通、实名认证、充值续费：对这类故障影响比你想的大
AWS抗投诉服务器 如果你是新买账号或刚注册不久，先确认三件事：
- 实名认证/企业认证是否完成：部分地区和支付方式会触发二次审核。
- 付款方式是否有效：信用卡、借记卡、PayPal 等可用性因地区不同而不同，卡片风控拒绝是常见失败点。
- 账号是否有余额/账单限制：AWS 这类按量服务不是预付充值模式，但账单状态异常会影响资源创建和续费。
对企业用户来说，最好不要把生产 EKS 和 ALB 放在“刚注册、还在审”的账号里。真实项目里，一旦碰到账单验证失败，排障时间往往比修 YAML 更长。
成本上要怎么判断：Ingress Controller 不收费，ALB 是收费的
很多团队以为“用了 controller 就免费”，这个理解不对。AWS Load Balancer Controller 本身不收费，但它创建出来的 ALB、目标组、LCU、数据处理都会计费。
| 方案 | 适合场景 | 成本特点 |
|---|---|---|
| ALB + AWS Load Balancer Controller | HTTP/HTTPS、路径/域名转发、多服务入口 | 有固定小时费 + 流量/规则计费，低流量也会有底座成本 |
| NLB | TCP/UDP、低层转发、长连接 | 通常规则更简单，适合不需要七层能力的场景 |
| ClusterIP + 外部反代 | 测试环境、内部访问 | 便宜，但运维成本会转移到你自己身上 |
如果只是做测试环境，很多团队会因为一个 ALB 的持续计费而超预算。尤其是多个环境各自起一个 ALB，月度费用会比你想的快得多。实际落地时，我通常会建议：能合并入口就合并，能内网就别公网暴露。
按排障优先级，建议你这样做
- 先看 controller Pod 是否正常运行。
- 再看日志里有没有 AccessDenied、subnet、ingress class 关键词。
- 检查 IAM Role / IRSA / OIDC 是否绑定正确。
- 确认子网标签、ALB 公网/内网类型是否匹配。
- 检查 Service 端口、目标组健康检查、Security Group 放行。
- 最后再去看账单、付款方式、组织策略和账号风控状态。
这个顺序很重要。很多人一上来就删 Ingress 重建，结果问题根源是账号权限或者子网标签，重建十次也没用。
常见问题
Q1：Ingress 已经创建，为什么 ALB 还是不出来？
A：最常见是 controller 没接到请求，或者没有权限创建 ELB。先看日志里的 AccessDenied 和 subnet 相关信息。
Q2：删掉 Ingress 再创建能解决吗？
A：只有在 annotation、ingressClassName 改对之后才有意义。权限、子网标签、账单问题不解决，重建没效果。
Q3：AWS 账号刚开通，能直接上生产吗？
A：不建议。至少先完成付款方式验证、权限边界检查和一次完整的 ALB 创建测试，再上正式流量。
Q4：为什么控制台里看不到创建失败记录？
A：有些失败只会出现在 controller 日志或 CloudTrail 里，不一定在 ECS/EKS 页面直接显示。CloudTrail 很适合查 API 拒绝。
如果你现在只想快速定位，优先看这两条日志
kubectl -n kube-system logs deploy/aws-load-balancer-controller --tail=200 | grep -E "AccessDenied|subnet|ingress class|failed|error"
如果这里出现权限错误，先修 IAM；如果是 subnet 问题，先补标签；如果没有任何报错但还是不生成，回头检查 IngressClass 和账单状态。按这个顺序排，效率最高。
这类问题的本质不是“ALB 没生成”，而是控制器、权限、网络标记、账号状态四层里有一层没打通。只要日志能看懂，通常半小时内就能锁定原因。