标签：K8s 与云原生故障排查 - Ai拆代码的曹操

查了 3 天 DNS 间歇超时，排除了网络、CNI、kube-proxy——最后发现是 CoreDNS 自动扩缩容的参数设反了

查了 3 天 DNS 间歇超时，排除了网络、CNI、kube-proxy——最后发现是 CoreDNS 自动扩缩容的参数设反了场景：微服务集群 ~120 个 Service，高峰期部分 Pod 报 Temporary failure in name resolution，API 响应从 <50ms

Gateway API 上线第 1 天就 503：Ingress 与新路由的 3 个隐性冲突场景：集群已有 Ingress 规则在跑，接入 Gateway API 后部分路由 503 路径：GatewayClass → Gateway → HTTPRoute → 控制器兼容性版本：K8s v1.

灰度 20% 流量全挂了——Istio DestRule 一个 label 拼错引发的 503 血案上篇讲了 Istio sidecar 启动慢是控制面配置没到，这篇我们来看另一个更沉默的陷阱：sidecar 启动好了、控制面也通了，但流量就是走不对。场景：order-service 做灰度发布

Istio sidecar 注入后启动慢 10 倍？不是资源不够，是控制面配置没到上篇讲了 Pod 能连内网却出不了外网——不是 CNI 的问题，是 SNAT 没开门。网络可达的问题排查完了，这篇我们来看一个更隐蔽的性能坑：Istio sidecar 注入后，Pod 启动从秒级拉到了分钟级。场景

Pod 能连内网却出不了外网？不是 CNI——是 SNAT 没开门场景：Pod 内 curl 外网 API 超时，但 curl 集群内 Service 秒回——开发改了三次应用配置没效果路径：坐标（Pod 内外网对比）→ 分层（Pod → CRI → Node iptables → 集群 kub

两个 Service 用了同一个端口号——K8s 的沉默最可怕场景：新部署一个有 NodePort 30080 的 Service，kubectl apply 报错"port is already allocated"，但查当前 namespace 的 Service 列表根本看不到 30080。

加了条 NetworkPolicy，消息队列直接断了——K8s 默认拒绝挨的第一刀场景：给支付服务加了一条 NetworkPolicy——只允许订单服务访问 8080。支付接口正常了，但订单突然收不到支付回调——不是代码改了，是订单到支付的异步消息走的是 RabbitMQ（5672 端口），被 N

nslookup 有 IP 还是不通？跨 Namespace 调用的两个隐藏门场景：微服务 A（ns-a）调用微服务 B（ns-b），curl 卡住直到超时——开发同学第一反应是"服务名写错了"，改了三次名字没效果路径：坐标（DNS 先查还是 NetPol 先查？）→ 分层（DNS → Serv

Service 通、Pod 正常，为什么外部总 503？Ingress 端口映射的隐藏陷阱场景：微服务上线后 Pod Running、Service 正常、集群内 curl 200，但外部域名访问一直 503 路径：坐标（503 现象 + 内部验证）→ 分层（Service→Ingress→Con

Endpoints 有 IP 还是不通？Service 排查的 3 个隐蔽陷阱场景：新部署 Nginx，Pod Running、Endpoints 有 IP，curl ClusterIP 超时——Service 所有 K8s 资源看起来都正常，但流量就是过不去路径：Service 层 → End