K8s服务暴露失败大排查

Kubernetes服务暴露失败大排查：从入门到放弃再到涅槃重生

作为踩过所有暴露方式坑的SRE，我整理了这份"服务见光死"排查宝典。跟着以下步骤操作，让您的服务重见天日！

一、快速自检表（3分钟定位80%问题）

# 一键诊断命令
kubectl get svc -o wide | grep <服务名> && \
kubectl get endpoints <服务名> && \
kubectl get pods -l <选择器标签>

✅ 健康状态特征：

Service类型正确（LoadBalancer/NodePort/Ingress）
Endpoints有正确IP:Port
关联Pod状态Running且READY

🚨 经典报错对照：

现象	嫌疑犯	验尸命令
External IP pending	云平台LB配置异常	`kubectl describe svc`
Connection timeout	安全组/防火墙拦截	`telnet <IP> <PORT>`
404 Not Found	Ingress路由错误	`kubectl get ingress -o yaml`
只能集群内访问	服务类型ClusterIP	`kubectl edit svc <名称>`

二、暴露方式专项排查（对症下药）

1. NodePort型服务失明

# 检查端口映射
kubectl get svc <名称> -o jsonpath='{.spec.ports[0].nodePort}'

# 节点级验证（所有节点执行）
nc -zvw3 $(hostname -i) <NodePort>

常见死因：

节点防火墙未放行端口范围（默认30000-32767）
kube-proxy未同步iptables规则（重启大法好）

2. LoadBalancer型服务罢工

# 查看云厂商LB状态
kubectl describe svc <名称> | grep -A5 Events

# AWS/GCP/Aliyun特殊检查项
AWS：检查Security Group入站规则
GCP：验证防火墙规则中的target-tags
阿里云：查看SLB实例状态

3. Ingress型服务404

# 经典配置错误示例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: faulty-ingress
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service: 
            name: not-exist-service  # 错误点：服务不存在
            port: 
              number: 8080

诊断命令：

# 查看Ingress映射状态
kubectl get ingress -o wide
kubectl describe ingress <名称>

# 进入Ingress Controller查看日志
kubectl logs -n ingress-nginx <pod-name>

三、网络层深度解剖（手术刀级排查）

1. 四层连通性测试

# 启动网络诊断Pod
kubectl run net-tool --image=nicolaka/netshoot -it --rm --restart=Never

# LoadBalancer测试
curl -v http://<EXTERNAL-IP>:<PORT>

# NodePort测试（任意节点IP）
telnet <Node-IP> <NodePort>

# 直接Pod测试
kubectl exec -it <pod-name> -- curl localhost:<targetPort>

2. 安全组/防火墙审查

# AWS安全组检查
aws ec2 describe-security-groups --group-ids <sg-id> \
  --query 'SecurityGroups[0].IpPermissions'

# 本地防火墙检查
iptables -L -n | grep <NodePort>
firewall-cmd --list-all

3. 服务网格干扰排查

# 查看是否启用Istio等网格
kubectl get pod -n istio-system

# 临时禁用Sidecar注入
annotations:
  sidecar.istio.io/inject: "false"

四、血泪案例库（前人踩坑后人乘凉）

案例1：阿里云SLB的幽灵事件
现象：External IP始终pending
根因：未配置付费类型的LoadBalancer
解决：

annotations:
  service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: "slb.s1.small"

案例2：NodePort的随机消失
现象：NodePort服务间歇性不可用
根因：kube-proxy的conntrack表满
解决：

sysctl -w net.netfilter.nf_conntrack_max=1000000

案例3：Ingress的路径陷阱
现象：访问返回404但服务正常
根因：pathType配置为Exact而非Prefix
解决：

pathType: Prefix

五、防暴毙指南（运维的自我修养）

服务暴露健康检查

# 带探针的Service配置
apiVersion: v1
kind: Service
metadata:
  annotations:
    # AWS健康检查配置
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "10"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/health"

自动修复配置

# 监控Endpoint变化自动重启
kubectl rollout restart deployment/my-app

可视化监控大盘

暴露成功率
端到端延迟
流量异常波动

六、终极排障工具箱

工具	用途	使用场景
ksniff	抓包分析	`kubectl sniff <pod>`
kubectl-debug	实时调试	`kubectl debug <pod>`
netstat	端口监听检查	`netstat -tulnp`
wireshark	流量深度分析	`tcpdump -i any port <端口>`

七、检查清单（逐项打勾保平安）

服务类型是否正确？
端口映射是否匹配？
云平台LB是否正常？
防火墙是否放行？
Ingress Controller是否健康？
节点kube-proxy是否工作？
服务选择器是否匹配Pod标签？

最后说句大实话：所有服务暴露问题，最后都是网络问题！ 下次遇到类似情况，不妨从底层网络层开始倒查，往往会事半功倍。记住，能ping通不代表能访问，能访问不代表能交互，必须做全链路验证！

（配个梗图：左边程序员在燃烧的服务器前崩溃，右边运维淡定地拉下电闸，字幕"重启解决90%问题，剩下10%需要重启两次"）

posted on 2025-03-18 18:26 Leo-Yide 阅读(29) 评论(0) 收藏举报