用kubeadm搭建3节点堆叠etcd控制平面+云厂商四层clb是最稳妥生产方案；3节点满足raft奇数容错要求，避免脑裂；需--upload-certs、内网地址注册etcd、clb禁ssl卸载、vip直连、时间同步、ssd挂载etcd目录。
直接说结论：用 kubeadm 搭建 3 节点堆叠 etcd 的控制平面 + 云厂商四层 CLB（如腾讯云 CLB、阿里云 SLB），是当前生产环境最稳妥、可快速验证、运维成本可控的方案。别碰二进制部署，除非你团队有专职 infra 工程师且已踩透所有 TLS 和证书轮换细节。
为什么必须用 3 个控制平面节点，而不是 2 或 4
etcd 集群依赖 Raft 选举，奇数节点才能避免脑裂。2 节点时任意一节点宕机，剩余节点无法达成多数派（quorum = 2），整个集群不可写；4 节点容错仍是 1（需 ≥3 节点在线），但多出 1 个节点纯属冗余，还增加网络开销和证书管理复杂度。
-
kubeadm init初始化第一个 master 时，必须带--upload-certs参数，否则后续kubeadm join --control-plane会因缺少证书而失败 - 所有控制平面节点的
/etc/hosts必须互相解析主机名（如k8s-master-1→10.0.1.10），kubeadm内部组件通信（如 apiserver 连 etcd）依赖主机名，不走 VIP - etcd 成员加入必须通过内网地址注册（如
https://10.0.1.10:2380），不能用 CLB VIP，否则 etcd peer 通信会超时
CLB 配置的关键参数不是“转发”，而是健康检查
云厂商 CLB 默认 TCP 端口探测（仅连通性）不足以识别 apiserver 实际状态。Kubernetes 的 /healthz 是 HTTP 接口，但 CLB 四层模式不支持 HTTP 探针——所以必须用 TCP+端口探测，并确保 apiserver 进程存活即代表可用。实测中，部分 CLB（如早期腾讯云 CLB）对 6443 端口的 FIN 包响应不稳定，建议在后端服务器上加一层轻量级 TCP 健康代理（如 nc -zv localhost 6443 脚本 + systemd timer），或直接启用 CLB 的“TCP SYN 监听”增强模式。
- CLB 后端权重必须设为相同值（如全为 100），
kubeadm不做客户端连接亲和，轮询即可 - CLB 监听端口必须为
6443，协议为 TCP，**禁止开启 SSL 卸载**——apiserver 与 kubelet、kubectl 的通信全程需要 mTLS - CLB 安全组必须放行源 IP 到后端节点的
6443端口，且后端节点本地防火墙（如iptables）也要显式允许该端口入向流量
kubeadm init 的 endpoint 必须指向 CLB VIP，但不能是域名
命令里写的 --control-plane-endpoint "10.0.1.100:6443"（VIP）会被写死进所有生成的 kubeconfig 和静态 Pod 清单。如果填域名（如 api.cluster.local），后续节点扩容或 DNS 故障时，apiserver 启动会卡在证书 SAN 校验失败——因为证书是用 VIP 签发的，不是域名。
- 初始化前务必确认所有节点时间同步（
chrony或systemd-timesyncd），误差 >1 秒会导致 TLS 握手失败，错误信息为x509: certificate has expired or is not yet valid -
kubeadm init输出的join命令含--certificate-key，该 key 2 小时过期，必须在时效内执行完其余 master 节点加入，否则要重新kubeadm init --upload-certs - 工作节点
join时**不能加--control-plane参数**，否则会尝试启动 etcd 和 controller-manager，导致端口冲突和资源争抢
最容易被忽略的是 etcd 数据目录权限和磁盘 IO：所有控制平面节点的 /var/lib/etcd 必须挂载在 SSD 上，且属主为 etcd:etcd（非 root）。曾有案例因误用机械盘 + 默认 IOPS，etcd 写入延迟飙升至 2s 以上，触发 apiserver 的 context deadline exceeded 错误，整个集群 API 响应停滞。
