企业官网建设流程全解析

从一次线上故障复盘说起：记K8s跨namespace访问的3个常见坑与排查指南

凌晨3点的告警短信总是格外刺眼。某金融系统的支付服务突然大面积超时，仪表盘上business命名空间的错误率曲线像过山车一样飙升。作为值班工程师，我迅速打开终端，却发现middleware命名空间的Redis集群监控一切正常——这场看似简单的"服务不可用"背后，隐藏着Kubernetes跨namespace访问的典型陷阱。

1. 网络策略拦截：看不见的柏林墙

当kubectl get pods -n business显示所有Pod都处于Running状态时，我的第一反应是检查网络连通性。在业务Pod内执行curl -v http://svc-middle01.middleware:6379返回Connection timed out，但直接访问同命名空间的服务却畅通无阻——这是典型的NetworkPolicy拦截症状。

通过以下命令快速验证网络策略：

# 检查生效的NetworkPolicy kubectl get networkpolicy -A --selector='app=middle01' # 查看具体规则细节 kubectl describe networkpolicy -n middleware redis-allow-specific

常见配置错误包括：

• 只允许特定标签的Pod访问（但业务Pod未打对应标签）
• 限制源IP范围时误将业务Pod IP段排除
• 策略命名空间选择器漏掉关键业务namespace

临时解决方案：

# 紧急放通所有流量（生产环境慎用） kubectl apply -n middleware -f - <<EOF apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-temporary spec: podSelector: {} ingress: - {} EOF

2. CoreDNS解析异常：迷路的服务发现

当网络策略排查无果后，业务Pod内执行nslookup svc-middle01.middleware返回NXDOMAIN错误，暴露了第二个坑——DNS解析失效。这通常由以下原因导致：

一个真实的修复案例：

# 调整NDOTS参数后重建业务Pod kubectl patch deployment app01 -n business -p '{"spec":{"template":{"spec":{"dnsConfig":{"options":[{"name":"ndots","value":"2"}]}}}}}'

3. ExternalName Service陷阱：美丽的误会

最隐蔽的问题出现在使用ExternalName Service的场景。某团队为了"简化配置"，在business命名空间创建了如下服务：

apiVersion: v1 kind: Service metadata: name: external-redis namespace: business spec: type: ExternalName externalName: svc-middle01.middleware.svc.cluster.local

表面上看，业务代码访问http://external-redis:6379似乎更简洁，但实际上：

1. ExternalName会返回CNAME记录而非A记录
2. 部分客户端库无法正确处理CNAME递归查询
3. 当CoreDNS版本升级时可能触发解析逻辑变化

推荐做法：

# 直接使用FQDN访问原始服务 redis-cli -h svc-middle01.middleware.svc.cluster.local -p 6379 # 或创建ClusterIP类型的Service进行转发 kubectl apply -n business -f - <<EOF apiVersion: v1 kind: Service metadata: name: proxy-redis spec: ports: - protocol: TCP port: 6379 targetPort: 6379 EOF

4. 终极排查工具箱

当所有常规手段都失效时，这套组合拳往往能发现意外问题：

1. 端点检查：

   kubectl get endpoints -n middleware svc-middle01

2. 流量嗅探：

   kubectl sniff -n business <pod-name> -f "host svc-middle01.middleware" -o pcap

3. 时间戳比对：

   # 检查Service和Endpoint的更新时间 kubectl get svc,ep -n middleware -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.annotations.kubectl\.kubernetes\.io/last-applied-configuration}{"\n"}{end}'

4. 跨命名空间连通性测试Pod：

   kubectl run -it --rm --restart=Never test-pod --image=nicolaka/netshoot \ --overrides='{"spec": {"namespace": "business"}}' \ --command -- curl -v http://svc-middle01.middleware:6379

那次事故最终发现是NetworkPolicy更新后未同步到所有节点，导致部分请求被错误拦截。我们在每个节点执行iptables -L -n | grep middleware才确认了这个问题。现在团队已经将网络策略检查纳入发布清单，类似的故障再未重现。