原生K8s YAML运行正常，封装为Helm Chart部署后Nginx报上游连接拒绝错误
2026-9-26
问题排查方案
1. 优先核对Service选择器与Pod标签的匹配性
你当前Service的selector配置是同时匹配microservice: {{ .Values.microservice }}和Helm默认生成的example.selectorLabels，原生YAML部署时可能没有同时要求这两个标签，导致Service找不到对应的后端Pod。
- 执行命令查看当前运行Pod的标签：
kubectl get pod -n <你的业务命名空间> --show-labels - 执行命令查看Service的选择器配置：
kubectl describe svc -n <你的业务命名空间> <你的Service名称> - 检查Service的selector字段是否完全匹配Pod的labels，只要有一个键值对不匹配，Service就不会将流量转发到对应Pod，就会出现503错误。
如果不匹配，两种修复方案：
- 方案1：在Deployment的Pod模板labels中补充
microservice: {{ .Values.microservice }}字段，和Service的selector对齐 - 方案2：删除Service的selector中
microservice: {{ .Values.microservice }}这一行，只用默认的selectorLabels匹配
2. 核对ExternalName Service的目标域名是否正确
你的ExternalName指向的是example.example-tpvs.svc.cluster.local，需要确认：
- Helm部署的Service所在的命名空间是否为
example-tpvs - Helm生成的Service名称是否为
example，如果你的Helm release名称不是默认的，{{ include "example.fullname" . }}生成的名称会带release前缀，比如你用helm install test ./chart部署，生成的Service名称就是test-example，这时候ExternalName的域名就不对了，需要修改为对应生成的Service全名。
3. 验证Service连通性
如果前两步都没问题，执行下面的命令验证服务是否可达：
- 启动临时测试Pod：
kubectl run -it --rm debug --image=busybox:1.28 --restart=Never -- sh - 在测试Pod内执行命令访问业务Service：
wget -O- http://<你的Service名称>.<你的业务命名空间>.svc.cluster.local
如果访问不通，说明Service到Pod的链路有问题，再进一步排查Pod端口是否真的监听了80：
- 执行命令进入业务Pod：
kubectl exec -it <你的Pod名称> -n <你的业务命名空间> -- sh - 执行命令检查端口监听：
netstat -tunlp | grep 80，确认你的应用确实在监听0.0.0.0:80，而不是127.0.0.1:80
内容的提问来源于stack exchange，提问作者José Pablo Medina Grande
相关产品推荐
相关产品推荐
