Helm Chart测试连接失败：mysvc:443连接被拒绝求助

核心原因分析 #

你遇到的Connection refused和nmap显示443/tcp closed，本质是Service的443端口没有关联到后端Pod的Endpoint——虽然Pod的3000端口正常、探针工作，但Service无法找到对应的Pod来转发流量。

排查步骤与修复方案 #

1. 检查Service与Pod的Label匹配 #

执行命令查看当前Service的Endpoint状态：

kubectl get endpoints <你的Service名称> -n <部署namespace>

如果输出中ENDPOINTS列是空的，说明Service的selector没有匹配到Pod的labels。

修复：
确保Service的selector完全匹配Pod的labels。比如helm create生成的默认Pod labels通常是app.kubernetes.io/name: <chart名>，你需要同步修改Service的selector：

# Service.yaml 片段
selector:
  app.kubernetes.io/name: <你的chart名称>

2. 验证Service端口配置正确性 #

检查Service的port定义是否包含必要字段，避免语法或逻辑错误：

# Service.yaml 正确示例
ports:
  - port: 443               # 对外暴露的端口
    targetPort: 3000        # 转发到Pod的端口
    protocol: TCP           # 明确指定协议（默认是TCP，但显式定义更稳妥）
    name: https             # 端口名称（可选，但Ingress引用时可能需要）

注意：targetPort可以是数字或字符串（如果Pod的containers.ports定义了name），但必须和Pod实际监听的端口一致。

3. 确认测试Pod与Service的Namespace一致性 #

helm test默认在Release对应的Namespace中运行测试Pod，若Service部署在其他Namespace，需使用FQDN访问：

wget mysvc.<Service所在Namespace>.svc.cluster.local:443

4. 排查NetworkPolicy限制 #

如果集群启用了NetworkPolicy，需确认是否存在规则阻止测试Pod访问Service的443端口。执行命令查看当前Namespace的NetworkPolicy：

kubectl get networkpolicy -n <部署namespace>

若存在拒绝访问的规则，需添加允许测试Pod（或所有Pod）访问Service的策略。

5. 验证kube-proxy状态 #

如果以上步骤都正常，检查节点上的kube-proxy是否正常运行，确保Service的IP和端口规则已正确同步：

kubectl get pods -n kube-system -l k8s-app=kube-proxy

若kube-proxy异常，重启对应Pod即可。

内容的提问来源于stack exchange，提问作者Vana