跨公网部署Kubernetes集群必须解决网络可达、证书信任链和组件通信超时三类核心问题：需确保apiserver绑定公网地址并放行6443等端口，etcd配置为可访问的公网endpoint，CNI插件（如Calico或Flannel）选用vxlan等跨网方案并避免CIDR重叠，同时对齐各组件对网络前提的隐式假设。
跨公网安装 Kubernetes 集群不是“拉起几台机器跑 kubeadm init 就完事”的事——网络不可达、证书信任链断裂、组件通信超时这三类问题，会直接卡死初始化流程。
节点间 kubelet 无法注册到 api-server
这是最常卡住的一步：内网 master 节点能监听 6443，但公网 node 节点发来的 CSR 请求根本没进日志，kubectl get nodes 始终为空。
- 检查
kubeadm join命令里填的 control-plane 地址是否可被 node 主机直接路由（比如填了192.168.0.1:6443，但 node 在公网根本 ping 不通） - 确认 master 的
apiserver启动参数是否显式绑定了公网监听地址，例如：--advertise-address=0.0.0.0或具体公网 IP，而非默认的127.0.0.1 - 防火墙必须放行
6443（API）、10250（kubelet metrics）、2379-2380（etcd）端口，且注意云厂商安全组是独立于系统防火墙的
kubeadm init 卡在 [wait-control-plane]
现象是命令长时间无响应，日志里反复出现 connection refused 或 timeout，本质是 etcd 或 apiserver 启动失败但未暴露错误。
- 默认
kubeadm init使用127.0.0.1作为本地 etcd endpoint，跨网场景下必须改用公网可访问地址，通过--cri-socket和--pod-network-cidr参数不足以解决；需额外配置etcd.external.endpoints指向带证书的公网地址 - 若使用自建 etcd 集群（非 kubeadm 内置），要确保所有 etcd 成员的
--initial-advertise-peer-urls和--listen-peer-urls都指向可互通的地址，且 peer 通信端口（2380）双向开放 - 容器运行时（如 containerd）若启用了私有镜像仓库认证，而
kubeadm拉取kube-apiserver镜像时未透传凭证，会导致镜像拉取失败静默卡住
CNI 插件部署后 Pod 网络不通，特别是跨网节点间
Flannel/Calico 能跑起来，coredns 处于 Running 状态，但不同节点上的 Pod 互 ping 不通，或 DNS 解析失败。
- Flannel 的
Backend类型不能选host-gw（仅限同子网），必须用vxlan或udp；Calico 则需确认FELIX_IPINIPENABLE开启，并设置正确的ipPoolCIDR，避免与底层物理网络重叠 - 检查各节点的
flanneld日志是否有Failed to create SubnetManager—— 这往往是因为 master 上的etcd地址未正确写入 Flannel ConfigMap，或 flannel 客户端证书不匹配 - 跨公网时，UDP 包可能被中间 ISP 限速或丢弃，
vxlan实际依赖 UDP 封装，建议在隧道层之上再套一层 TCP（如使用konnectivity-server或ssh -L端口转发）保底
真正棘手的不是某一个组件装不上，而是多个组件对“网络可达性”的假设不一致：kubeadm 认为节点能直连 API，CNI 认为底层网络支持 UDP 组播，etcd 认为 peer 节点能走内网延迟通信——这些隐含前提在混合云里全得手动对齐，漏掉任意一环，集群就停在半途不动。
