kubeadm init 生成的证书默认仅绑定 localhost 和节点本地 ip，不包含公网地址或其它 node 访问入口，导致 tls 证书校验失败，进而引发 kubectl get nodes 返回 notready 或 connection refused；根本解决需通过 --apiserver-advertise-address 和 --apiserver-cert-extra-sans 确保所有访问路径纳入证书 san 列表，并确认 csr 自动批准、端口放行及公网路径配置正确。
kubeadm init 生成的证书默认只绑定 localhost 和节点本地 IP，不包含公网地址或其它 Node 的访问入口——这是主从通信失败最常见的根因。
为什么 kubectl get nodes 返回 NotReady 或连接 refused
根本问题往往不是网络不通，而是 TLS 证书校验失败。kubelet、kube-proxy 等组件在连接 kube-apiserver 时会严格验证服务端证书的 Subject Alternative Name (SAN) 列表。若请求使用的地址（比如公网 IP 或域名）不在 SAN 中，Go HTTP 客户端直接拒绝连接，错误类似：
Unable to connect to the server: x509: certificate is valid for 127.0.0.1, ::1, 192.168.6.201, not 59.110.220.63
解决思路很明确：让 kube-apiserver 的证书包含所有合法访问路径。
-
--apiserver-advertise-address必须设为 Node 实际用来访问 Master 的 IP（如内网 IP），它决定证书中默认加入的 SAN 条目之一 -
--apiserver-cert-extra-sans是关键补救项，可追加多个额外地址：内网 IP、公网 IP、DNS 域名（如api.cluster.local） - 不要依赖
--bind-address=0.0.0.0，它只控制监听地址，不影响证书内容 - 证书一旦生成（
/etc/kubernetes/pki/apiserver.crt），kubeadm 不会自动重签；改参数必须重新kubeadm init --dry-run验证后再执行
Node 加入集群时的证书与 kubeconfig 权限问题
运行 kubeadm join 时，传入的 token 和 discovery-ca-cert-hash 用于拉取 cluster-info ConfigMap，其中包含一个临时 admin.conf ——但这个文件里的 client-certificate-data 默认只授权给 system:masters 组，普通 Node 上的 kubelet 并不使用它。
真正驱动 Node 注册的是 kubelet 自己的凭据：
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- Node 启动后，kubelet 用内置的 CSR（Certificate Signing Request）机制向
kube-apiserver申请客户端证书 - 该 CSR 需被
system:node-bootstrapper角色自动批准（默认开启），否则kubelet一直卡在NotReady - 检查是否启用：运行
kubectl get clusterrolebinding kubeadm:node-autoapprove-bootstrap，应存在且绑定到system:bootstrappers组 - 若被误删，需手动恢复，否则所有新 Node 都无法完成 TLS 双向认证
防火墙与端口放行的实际影响范围
Master 和 Node 之间并非只有 6443 端口需要打通。忽略以下端口会导致组件静默失效：
-
6443：kube-apiserver 入口，所有控制面通信起点（必须） -
10250：kubelet API 端口，Master 上的kube-controller-manager和kube-scheduler需要调用它获取 Node 状态、Pod 列表、执行 exec/logs（Node 节点必须开放此端口入站） -
10255（已弃用但部分监控仍用）：只读 kubelet 端口，若关闭，cAdvisor 指标可能丢失 -
30000–32767：NodePort 类型 Service 的默认端口范围，若部署了对外暴露的服务，需确保该段对客户端开放，而非仅 Master↔Node
注意：iptables 或 nftables 规则可能覆盖 ufw/firewalld 设置；建议用 ss -tlnp | grep :10250 在 Node 上确认监听状态，并用 curl -k https://<master-ip>:6443/version</master-ip> 从 Node 手动测试连通性与证书有效性。
跨公网部署时最易忽略的两个加固点
当 Master 暴露在公网（如云服务器）时，光配对证书远远不够：
- Node 上的
kubelet配置里不能硬编码公网 IP 到--server参数；应统一通过/etc/kubernetes/kubelet.conf中的server:字段管理，该文件由kubeadm join自动写入，且默认使用--apiserver-advertise-address值 —— 若此处填了公网 IP，而 Node 本身又在内网，就会走公网绕路甚至失败 - 务必禁用
kube-apiserver的匿名访问：--anonymous-auth=false（kubeadm 默认已关），否则未认证请求可能绕过 RBAC 直接查集群信息 - 生产环境强烈建议用
externalLoadBalancer+ 多 Master + etcd 分离，单 Master 公网暴露属于高危配置，哪怕证书和防火墙都正确
证书 SAN、CSR 自动批准、端口语义差异、公网路径选择——这四点任意一个出错，都会导致 “网络能 ping 通但 k8s 不工作” 的典型假象。
