Kubernetes高可用部署详细步骤 - 实现稳定可靠的容器编排

公司刚上ref="/tag/2020/" style="color:#E3A3CF;font-weight:bold;">Kubernetes那会儿，一次意外断电直接让整个服务瘫了半小时。运维老李拍着桌子说：‘主节点只有一个，挂了当然全完蛋！’从那以后，团队下定决心搞高可用部署。现在哪怕两个节点同时出问题，业务照样跑得稳。

为啥要搞高可用？

Kubernetes默认安装通常只起一个控制平面节点。这就像家里总闸没备胎，跳一次就得全家摸黑找电箱。高可用的核心，就是让API Server、etcd这些关键组件多实例运行，彼此之间能自动顶上。

规划节点角色

至少准备三台服务器作为控制平面节点，奇数台方便选举。比如用kubeadm部署时，可以指定第一个节点为初始化节点：

kubeadm init --control-plane-endpoint="k8s-lb:6443" \ 
--upload-certs --apiserver-bind-port=6443

后续节点加入时使用 join-control-plane 参数，把证书和配置自动同步过来。这里的 k8s-lb 是个虚拟域名，背后接的是负载均衡器。

别忘了负载均衡

多个API Server不能各自为政。前端必须加一层四层负载均衡（如HAProxy或云厂商的SLB），客户端请求统一打到VIP上。这样kubectl命令不管连到哪个IP，看到的数据都一致。

举个例子，开发小王在办公室用内网LB地址访问集群，出差时切换成公网LB，体验完全一样——因为他根本不知道背后是哪台物理机在响应。

etcd集群独立部署更稳妥

虽然kubeadm支持把etcd和控制平面混布，但生产环境建议单独搭建三节点etcd集群。配置文件里明确指向：

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
etcd:
  external:
    endpoints:
      - https://192.168.10.11:2379
      - https://192.168.10.12:2379
      - https://192.168.10.13:2379
    caFile: /etc/kubernetes/pki/etcd/ca.crt
    certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
    keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key

网络插件也要跟上

Calico或者Flannel装好后，记得检查pod之间的互通性。曾经有个项目因为防火墙阻断了UDP 8472端口，VXLAN隧道建不起来，新节点一直卡在NotReady状态。排查半天才发现是安全组规则漏配。

定期模拟故障测试

每月停掉一台master节点的kubelet服务，观察是否自动转移。日志里能看到leader迁移记录，apiserver响应延迟短暂上升，但deployment控制器始终在工作。这种演练比写一百页文档都管用。