记一次全自动的问题诊断过程

Vibe Coding 方法论已在众多项目中大放异彩，我自己也开发了几个相关工具。不过当涉及到运维工作时，问题的复杂性往往会大幅提升。前两天我用 Antigravity 成功解决了一个网络诊断问题，整个过程非常顺畅，特别想与大家分享这个经历。

回顾今年，最大的收获莫过于终于实现了基础设施即代码（Infrastructure as Code）。我使用 Pulumi 来管理整个 AWS 环境，这带来了显著的好处------特别是当问题由配置错误引起时，我们可以将修正记录到代码中，从而避免重复犯同样的错误。然而，对于日常的问题诊断工作，Pulumi 本身无法直接提供帮助。

诊断过程

前段时间，有人报告称 Pulumi 搭建的 EKS 集群出现了问题。我尝试部署一个测试 Pod，却遭遇镜像拉取失败的错误。考虑到这套环境已经使用了多次，我对其配置很有信心，问题很可能是有人手动修改了某些配置。既然要诊断的对象是 EKS 和 AWS 的各项配置，而这些资源都可以通过命令行工具访问，那么这个任务完全可以交给 AI 代理来处理。于是，我打开了 Antigravity。

我想创建一个 README.md 来详细描述问题，但最终只需要写下这两行关键信息：

md 复制代码

我的机器已经安装了 AWS CLI 和 kubectl。

使用的 AWS Profile 是 prod。

随后我向 Antigravity 提问：

md 复制代码

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

让我惊喜的是，Antigravity 随即提议执行以下命令：

bash 复制代码

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

虽然它的建议很贴心------想为我生成 kubeconfig 文件------但这一步其实是多余的，因为我的配置文件早已就位。我向它说明了这一点，它随即调整了方案。

接下来，Antigravity 迅速定位到了 Pod 层面的问题：

bash 复制代码

dial tcp 3.227.50.168:443: i/o timeout

这个错误表明网络连接已经超时。为了进一步诊断 EKS 的网络配置，它随后执行了：

md 复制代码

看起来 AWS CLI 的输出有问题。让我换一种方式检查网络配置：

*User accepted the command `$env:PAGER=''; aws eks describe-cluster --name my-infra-eks1-cluster --profile prod --query 'cluster.resourcesVpcConfig'`*

*Checked command status*

*User accepted the command `aws ec2 describe-subnets --subnet-ids subnet-022afbc288eec0c95 subnet-054c0ebc0fc6d50d9 --profile prod --output json | ConvertFrom-Json | Select-Object -ExpandProperty Subnets | Select-Object SubnetId, VpcId, CidrBlock, MapPublicIpOnLaunch, AvailabilityZone | Format-Table`*

*Checked command status*

进一步检查私有子网的配置后，它发现了一个关键信息：

md 复制代码

很好！我看到节点在**私有子网**中（`MapPublicIpOnLaunch: False`），并且没有外部 IP。现在让我检查这些子网的路由表和 NAT 网关配置：

*User accepted the command `aws ec2 describe-route-tables --filters "Name=association.subnet-id,Values=subnet-022afbc288eec0c95,subnet-054c0ebc0fc6d50d9" --profile prod --output json | ConvertFrom-Json | Select-Object -ExpandProperty RouteTables | ForEach-Object { $_.Routes } | Format-Table DestinationCidrBlock, GatewayId, NatGatewayId, State`*

路由表检查完毕后，它继续探查 NAT 网关的健康状况：

md 复制代码

好的，路由表看起来正常，已配置 NAT 网关。现在让我检查这个 NAT 网关的状态：

*User accepted the command `aws ec2 describe-nat-gateways --nat-gateway-ids nat-0e773344c68bd5f76 --profile prod --output json | ConvertFrom-Json | Select-Object -ExpandProperty NatGateways | Select-Object NatGatewayId, State, SubnetId, VpcId | Format-Table`*

md 复制代码

NAT 网关状态为 `available`，表面上看正常。让我进一步检查 NAT 网关所在的公有子网及其关联的弹性 IP：

*User accepted the command `aws ec2 describe-nat-gateways --nat-gateway-ids nat-0e773344c68bd5f76 --profile prod --output json | ConvertFrom-Json | Select-Object -ExpandProperty NatGateways | Select-Object -ExpandProperty NatGatewayAddresses | Format-Table`*

*User accepted the command `aws ec2 describe-subnets --subnet-ids subnet-01d07402f48299965 --profile prod --output json | ConvertFrom-Json | Select-Object -ExpandProperty Subnets | Select-Object SubnetId, MapPublicIpOnLaunch, AvailabilityZone | Format-Table`*

接下来需要检查安全组和网络访问控制列表（ACL）的配置：

css 复制代码

NAT 网关配置看起来也是正常的，已获得公网 IP `18.143.220.16`。现在让我检查一下安全组和网络 ACL 配置：

*User accepted the command `aws ec2 describe-instances --filters "Name=private-ip-address,Values=10.60.21.217" --profile prod --query 'Reservations[0].Instances[0].SecurityGroups[*].[GroupId,GroupName]' --output table`*

*User accepted the command `aws ec2 describe-security-groups --group-ids sg-0506cc37f37d190f5 --profile prod --query 'SecurityGroups[0].{Egress:IpPermissionsEgress}' --output json | ConvertFrom-Json | Select-Object -ExpandProperty Egress | Format-List`*

这时，问题的根源浮现了水面：

md 复制代码

太好了！现在真相大白了。网络 ACL 的配置情况是：
- **出站规则（Egress=True）**：规则 100 允许所有流量目的地为 `0.0.0.0/0` ✅
- **入站规则（Egress=False）**：仅允许来自 `10.60.0.0/16`、`10.62.1.10/32` 和 `10.62.0.0/16:38880` 的流量

这就是症结所在：**虽然出站流量可以正常离开，但返回的流量遭到了阻止**！让我检查入站规则是否允许返回的临时端口流量：

*User accepted the command `kubectl exec -it network-tester -n default -- ping -c 3 8.8.8.8`*

这时，AI 意识到了一个逻辑上的矛盾------由于网络问题导致无法拉取镜像，自然也就没有可用的 Pod 来进行测试。它迅速调整了策略：

md 复制代码

您说得对！这确实形成了一个死循环------无法拉取镜像，就无法创建测试 Pod；而没有 Pod，我们又无法测试网络。

让我换个思路，直接利用已经运行的 Pod 来进行网络测试。我注意到 `wallet-web` Pod 已经成功运行，完全可以用它来验证网络连接：

*User accepted the command `kubectl exec -it wallet-web-5c8d94dc6b-r57wn -n wallet -- sh -c "wget -O- -T 5 https://registry-1.docker.io 2>&1 || curl -v --max-time 5 https://registry-1.docker.io 2>&1 || echo 'Both wget and curl failed'"`*

找了一个存在的 Pod 执行而是，结论是网络确实有问题。

最后它也给了我修正命令，调整了 ACL 后恢复正常。根本原因是某位同事手动修改了 ACL 配置，但没有意识到这个看似简单的改动会造成如此严重的后果。

总结

就如同 Vibe Coding 的理念一样，这次我只是提供了最基本的提示，就让 AI 完成了整个诊断过程。之所以能这么顺利，核心原因有两个：首先，AWS 和 EKS 都是非常标准的云服务，AI 的知识库已经积累了充足的相关信息；其次，通过 aws 和 kubectl 这两个命令行工具，AI 就能获取到进行诊断所需的全部信息。

然而，在现实世界中，许多组织都拥有自己独特的系统架构和知识体系，往往与通用 AI 的认识存在较大偏差。同时，AI 目前可调用的诊断工具相当零散，难以高效地聚合信息进行分析。我认为这些问题可以通过 MCP、Skills 以及上下文工程等新兴技术和方法论来逐步改善。