云原生环境下常见的网络故障场景
在一次上线高峰期，服务突然无法调用，日志显示连接超时。查看K8s Pod状态一切正常，但服务之间就是不通。这种情况你遇到过吗？这正是云原生面试中常被问到的网络排错题原型。
面试官不只想听你背概念，更想看你有没有在真实环境中定位问题的思路。比如：是不是Pod之间的网络策略（NetworkPolicy）拦了请求？DNS解析是否正常？还是CNI插件配置出了问题？
Pod间网络不通怎么查？
先别急着重启Pod。第一步是进到源Pod里用curl或telnet测试目标服务。如果连不上，接着检查目标Pod的IP和端口是否正确暴露。
然后看Service有没有正确关联Endpoints：
kubectl get endpoints <service-name>如果Endpoints为空，可能是Pod的label没对上，也可能是命名空间搞错了。这种低级错误在压力大的时候真有人犯。
DNS解析失败怎么办？
一个典型的面试问题是：Pod里ping service名称不通，但ping IP可以。这时候大概率是CoreDNS的问题。
进Pod执行：
nslookup your-service.default.svc.cluster.local如果解析失败，去看coredns的Pod有没有Running，日志有没有报错。有时候是因为Node资源不足被驱逐过，重启后没恢复网络。
如何模拟网络延迟排查问题？
有些面试官会问：“怎么在测试环境模拟高延迟，验证服务容错？”这时候可以用iptables或者专门的工具如tc（Traffic Control）。
比如，在Pod所在Node上执行：
tc qdisc add dev eth0 root netem delay 500ms这样就能模拟半秒延迟，观察上游服务会不会超时熔断。记得测完删掉规则：
tc qdisc del dev eth0 rootNetworkPolicy写错了会怎样？
有次上线后发现前端访问不了后端API，查了一圈才发现是NetworkPolicy加得太严，默认拒绝了所有入向流量。
K8s里NetworkPolicy默认是“白名单”机制，没明确允许的就是拒绝。面试常考这个问题：如何只允许特定命名空间的Pod访问某个端口？
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-from-frontend
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: frontend
ports:
- protocol: TCP
port: 80线上问题还原到本地怎么搞？
很多人卡在“本地好好的，线上就出事”。面试官喜欢问你怎么在本地复现线上网络环境。
可以用Kind（Kubernetes in Docker）搭个本地集群，配合自定义CNI配置，甚至引入Linkerd做服务网格。再用Helm把服务部署进去，模拟多节点通信。
关键是能说清楚每一步在还原哪个环节——是DNS？是负载均衡？还是TLS拦截？
常见面试题摘录
除了动手操作，理论也得跟上。下面这些题几乎每次面试都会碰上：
- Calico和Flannel的区别是什么？在跨节点通信上有什么不同？
- Service的ClusterIP是怎么实现的？iptables还是IPVS？
- Pod启动后长时间处于NotReady，可能是什么网络原因？
- Ingress Controller挂了会影响哪些流量？怎么快速恢复？
- 如何排查K8s节点之间的网络中断？用什么命令？
别光背答案。面试官更在意你能不能把kubectl、tcpdump、ip route这些工具串起来用，像修水管一样一步步找到堵点。