咱们一步步拆解问题——既然Master本地能正常访问https://masternode_ip:32323，说明Dashboard的Pod、ServiceAccount权限配置都没问题，问题大概率出在网络连通性或者端口转发的拦截上，按下面的步骤逐一排查：

1. 确认NodePort Service的状态与配置 #

先检查Service是否正确绑定了NodePort，并且和Pod连通：

• 执行命令查看Service详情：

  kubectl get svc -n kubernetes-dashboard
  

  确认输出里的TYPE是NodePort，PORT(S)列显示443:32323/TCP（或你配置的对应端口），EXTERNAL-IP为<nodes>（表示绑定集群所有节点的IP）。
• 再检查Endpoint是否正常关联Pod：

  kubectl get endpoints -n kubernetes-dashboard
  

  确保ENDPOINTS列有Dashboard Pod的IP（比如10.244.0.5:8443），这说明Service和Pod之间的转发是通的。

2. 检查Master节点的防火墙/安全组规则 #

这是最常见的原因——本地能访问但跨机器不行，通常是Master节点的防火墙挡住了32323端口：

• 如果你用的是firewalld（CentOS/RHEL系）：

  # 临时开放端口（重启后失效）
  firewall-cmd --add-port=32323/tcp
  # 永久开放端口
  firewall-cmd --add-port=32323/tcp --permanent
  # 重载规则生效
  firewall-cmd --reload
  

• 如果你用的是iptables（Debian/Ubuntu系）：

  # 开放端口
  iptables -A INPUT -p tcp --dport 32323 -j ACCEPT
  # 保存规则（不同系统命令可能不同，比如Ubuntu用iptables-save > /etc/iptables/rules.v4）
  iptables-save > /etc/sysconfig/iptables
  

• 如果你是云服务器（比如阿里云、AWS），还要检查安全组规则，确保入方向允许32323端口的TCP流量。

3. 验证跨机器的网络连通性 #

先排除基础网络问题：

• 从其他机器ping Master节点的IP，确认网段内网络是通的：

  ping <masternode_ip>
  

• 如果ping通，再测试端口是否能访问：

  # 用telnet测试
  telnet <masternode_ip> 32323
  # 或者用nc（更直观）
  nc -zv <masternode_ip> 32323
  

  如果显示Connection refused或者超时，说明端口确实被阻断，回到第二步检查防火墙/安全组。

4. 检查kube-proxy的运行状态 #

NodePort的转发依赖kube-proxy组件，确保它在Master节点正常运行：

• 查看kube-proxy Pod状态：

  kubectl get pods -n kube-system | grep kube-proxy
  

  确认状态是Running，如果有异常（比如CrashLoopBackOff），删除Pod让它自动重建：

  kubectl delete pod <kube-proxy-pod-name> -n kube-system
  

5. 核对Service的yaml配置细节 #

有时候自定义yaml可能有细微错误，导出Service配置确认：

kubectl get svc kubernetes-dashboard -n kubernetes-dashboard -o yaml

重点检查：

• spec.type是否为NodePort
• spec.ports[0].nodePort是否确实是32323
• spec.ports[0].targetPort是否匹配Dashboard Pod的端口（v1.10.0默认是8443）

按照上面的步骤排查，基本能定位到问题——多数情况都是防火墙没放行端口，或者kube-proxy异常导致转发失效。

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