AWS EKS集群网络诊断实战：基于Antigravity的全自动问题排查

前些天，我利用 AI 代理工具 Antigravity 成功完成了一次对 AWS EKS 集群网络问题的全自动化诊断，整个过程高效、流畅，是一个将 AI 应用于复杂运维场景的典型实践。

在此之前，我已经通过 Pulumi 实现了整个 AWS 环境的基础设施即代码（IaC）管理。这种方式在应对配置错误时优势明显——修复可以被固化到代码中，防止问题复发。然而，对于偶发的、原因未知的线上故障，Pulumi 本身并不能直接提供诊断能力。

问题浮现：Pod镜像拉取失败

近期，有反馈称基于 Pulumi 搭建的 EKS 集群 my-infra-eks1-cluster 出现异常。我尝试部署一个测试 Pod 时，遭遇了镜像拉取失败的错误。鉴于该环境配置已稳定运行多次，我初步判断是人为的手动改动导致了问题。既然诊断对象是标准的 AWS EKS 及其网络组件，且所有信息均可通过 aws 和 kubectl 命令行获取，我决定将诊断任务交给 AI 代理。

我启动了 Antigravity，并为其提供了最简化的上下文：

我的机器已经安装了 AWS CLI 和 kubectl。使用的 AWS Profile 是 prod。

随后，我提出了问题：

参考 README.md 环境。我的 eks 集群 my-infra-eks1-cluster 访问网络有问题，你能帮我诊断一下吗？

全自动诊断流程

AI 代理的响应非常迅速且具有逻辑性。它首先提议执行基础命令来确认集群访问和节点状态：

aws eks update-kubeconfig --name my-infra-eks1-cluster --profile prod; kubectl get nodes; kubectl get pods -A

在我告知 kubeconfig 已就绪后，它跳过了配置生成步骤。通过检查 Pod 事件，它很快锁定了核心错误信息：

dial tcp 3.227.50.168:443: i/o timeout

这是一个明确的网络连接超时错误，表明出站流量可能受阻。

紧接着，Antigravity 开启了一套系统的 网络 排查流程：

1. 检查集群 VPC 配置：确认了集群所在的 VPC 和子网信息。
2. 分析子网属性：发现工作节点位于“私有子网”（MapPublicIpOnLaunch: False），这意味它们需要依靠 NAT 网关访问公网。
3. 验证路由表：检查私有子网关联的路由表，确认存在指向 NAT 网关的路由条目。
4. 检查 NAT 网关状态：确认 NAT 网关状态为 available 并获取了其关联的弹性公网 IP 18.143.220.16。至此，基础设施层看似正常。

随后，排查转向了安全层：

5. 检查安全组出站规则：节点安全组的出站规则允许所有流量（0.0.0.0/0），无异常。
6. 检查网络 ACL（NACL）：这是发现关键问题的环节。AI 代理检查了关联子网的网络 ACL 规则，发现：
   • 出站规则（Egress）：规则 100 允许所有流量到 0.0.0.0/0 ✅
   • 入站规则（Ingress）：仅允许来自特定 CIDR 10.60.0.0/16、10.62.1.10/32 和 10.62.0.0/16:38880 的流量。

问题根因浮出水面：网络 ACL 的入站规则过于严格，仅放行了特定 IP 段的回包流量。当 Pod 主动访问公网（如 Docker Hub）时，出站请求可以通过，但来自公网目标（如 3.227.50.168:443）的响应数据包在返回时，因为源 IP 不在 ACL 入站规则的白名单内而被丢弃，导致连接超时。

巧妙的验证与修复

诊断过程中还出现了一个有趣的插曲：AI 最初提议创建一个测试 Pod 来执行 ping 命令，但随即意识到由于网络问题，根本无法拉取镜像来创建这个 Pod，形成了一个“死循环”。它立刻调整策略，转而利用命名空间中一个已存在的 wallet-web Pod 来执行网络测试命令，从而验证了网络连通性确实中断。

最后，Antigravity 给出了修复建议：修改网络 ACL 的入站规则，放行来自 0.0.0.0/0 的临时端口（Ephemeral Ports）范围的流量，或至少确保能接收从已建立连接返回的流量。执行修正后，集群网络立即恢复正常。事后证实，问题根源正是一位同事在修改 ACL 时无意中收紧了入站规则所致。

总结与思考

本次诊断展示了 AI 代理在标准化云环境运维中的强大潜力。整个过程，我仅提供了目标（诊断网络）和基础凭证，AI 便自主完成了从信息收集、逻辑推理、根因定位到提供解决方案的全链条工作。

成功的关键在于两点：一是 AWS EKS 作为标准化服务，其架构和 API 已被 AI 充分学习；二是通过 aws 和 kubectl 这类命令行工具，AI 能够获取到足够进行诊断的结构化信息。

然而，在更复杂的现实环境中，企业往往拥有大量自定义架构和内部知识，且诊断工具链分散，这对通用 AI 构成了挑战。未来，通过 MCP（模型上下文协议）、Skills（技能插件）以及更精细的上下文工程（Context Engineering），有望让 AI 更深度、更安全地集成到各类运维系统中，真正实现智能化的基础设施管理。