1. 为什么要关心高可用？
想象一下你在凌晨三点被电话吵醒，因为生产环境的Kubernetes集群挂掉了。这时候你会想，如果当初采用多主节点架构是不是就能避免这场灾难？这正是指挥中心（控制平面）和"记忆体"（etcd）都需要高可用设计的根本原因。
在传统单主节点架构中：
- 主节点宕机=集群完全瘫痪
- etcd故障=应用配置数据全部丢失
- 滚动升级=必须停机维护
通过将3个主节点组成集群，etcd也以集群形式运行，我们能达成：
- 任何单节点故障自动恢复
- 零停机更新系统组件
- 无缝处理大流量冲击
2. 环境规划与准备
（技术栈：Ubuntu 22.04 + Kubernetes v1.25 + etcd 3.5）
cat << EOF >> /etc/hosts
192.168.1.101 k8s-master-01
192.168.1.102 k8s-master-02
192.168.1.103 k8s-master-03
192.168.1.200 k8s-vip # 虚拟IP地址
EOF
# 所有节点通用的预配置（在每个节点执行）
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
sudo modprobe br_netfilter
echo "1" | sudo tee /proc/sys/net/ipv4/ip_forward
注释说明：
k8s-vip是虚拟IP，将负载均衡到各主节点- 禁用swap确保内存管理策略稳定
- 网络参数调优是容器网络的基础要求
3. etcd集群部署：数据的保险箱
# 在第一个主节点初始化etcd集群（以k8s-master-01为例）
etcd --name etcd-01 \
--data-dir /var/lib/etcd \
--initial-advertise-peer-urls http://192.168.1.101:2380 \
--listen-peer-urls http://0.0.0.0:2380 \
--listen-client-urls http://0.0.0.0:2379 \
--advertise-client-urls http://192.168.1.101:2379 \
--initial-cluster-token my-k8s-etcd \
--initial-cluster "etcd-01=http://192.168.1.101:2380,etcd-02=http://192.168.1.102:2380,etcd-03=http://192.168.1.103:2380" \
--initial-cluster-state new
# 后续节点加入集群（在k8s-master-02执行）
etcd --name etcd-02 \
--data-dir /var/lib/etcd \
--initial-advertise-peer-urls http://192.168.1.102:2380 \
--listen-peer-urls http://0.0.0.0:2380 \
--listen-client-urls http://0.0.0.0:2379 \
--advertise-client-urls http://192.168.1.102:2379 \
--initial-cluster-token my-k8s-etcd \
--initial-cluster "etcd-01=http://192.168.1.101:2380,etcd-02=http://192.168.1.102:2380,etcd-03=http://192.168.1.103:2380" \
--initial-cluster-state existing
关键参数揭秘：
--initial-cluster-token：相当于集群的身份证- 奇数节点数量确保选举可靠性（推荐3或5节点）
- 2380端口用于节点间通信，2379处理客户端请求
4. Kubernetes控制平面高可用部署
# 在第一个主节点初始化控制平面
kubeadm init --control-plane-endpoint "k8s-vip:6443" \
--upload-certs \
--pod-network-cidr=10.244.0.0/16 \
--apiserver-advertise-address=192.168.1.101
# 其他主节点加入命令（输出中会包含证书参数）
kubeadm join k8s-vip:6443 --token xyzabc \
--discovery-token-ca-cert-hash sha256:... \
--control-plane \
--certificate-key ... \
--apiserver-advertise-address=192.168.1.102
# 验证控制平面状态
kubectl get nodes -o wide
kubectl -n kube-system get pod -l tier=control-plane
核心组件协作逻辑：
- 所有API Server共享相同的CA证书
- kube-scheduler和kube-controller-manager选举Leader
- kube-proxy维护负载均衡规则
- CoreDNS自动同步所有节点的变更
5. 负载均衡器实战配置（以HAProxy为例）
frontend k8s-api
bind *:6443
mode tcp
option tcplog
default_backend k8s-masters
backend k8s-masters
mode tcp
balance roundrobin
option tcp-check
server k8s-master-01 192.168.1.101:6443 check fall 3 rise 2
server k8s-master-02 192.168.1.102:6443 check fall 3 rise 2
server k8s-master-03 192.168.1.103:6443 check fall 3 rise 2
frontend etcd-client
bind *:2379
mode tcp
default_backend etcd-cluster
backend etcd-cluster
mode tcp
balance leastconn
server etcd-01 192.168.1.101:2379 check
server etcd-02 192.168.1.102:2379 check
server etcd-03 192.168.1.103:2379 check
流量管理策略：
- API Server采用轮询均衡，分散读取压力
- etcd采用最少连接策略，防止热节点出现
- 健康检查保障故障节点自动剔除
6. 真实场景测试：模拟灾难恢复
# 模拟主节点宕机
ssh k8s-master-01 "sudo systemctl stop kube-apiserver"
# 观察服务连续性
kubectl get nodes # 应仍能正常返回所有节点
kubectl scale deployment nginx --replicas=5 # 扩容操作应当成功
# 验证etcd数据同步
docker run --rm -it \
--net=host \
appropriate/curl \
etcdctl --endpoints=http://192.168.1.102:2379 endpoint status
# 查看选举状态
kubectl -n kube-system exec etcd-k8s-master-02 -- etcdctl endpoint status
7. 典型应用场景分析
- 金融支付系统：需要7×24小时不间断处理交易请求
- 物联网数据平台：海量设备同时连接时避免单点过载
- 电商大促活动：突发流量需要弹性扩展控制平面
- 跨国多云部署：通过地域分布式集群降低延迟
8. 架构优势与成本分析
技术收益：
- 年故障停机时间从小时级降到秒级
- 支持滚动升级不影响业务运行
- 单个节点资源利用率提升40%
需要考虑的代价：
- 至少三台符合主节点规格的服务器
- 网络延迟要求<5ms（同机房建议）
- 运维复杂度指数级上升
9. 避坑指南：血的教训总结
- 时钟同步：所有节点必须使用NTP同步，时间差>5秒就会导致证书失效
- 证书管理：提前设置自动续期，曾因证书过期导致整个集群瘫痪
- 备份策略：虽然etcd有冗余，仍需定期快照备份到异地
- 网络隔离：控制平面流量与业务流量必须分属不同网段
- 监控死角：特别关注apiserver的499错误码和etcd的写入延迟
10. 部署全景图（概念示意图）
虽然没有图片，但通过以下符号可脑补架构：
[负载均衡器] --> [主节点1] --> etcd-01
|--> [主节点2] --> etcd-02
|--> [主节点3] --> etcd-03
|
v
工作节点池
11. 未来演进方向
- 边缘计算场景的轻量化控制平面
- 基于eBPF的网络性能优化
- 机器学习驱动的自动故障预测
- 多集群联邦管理方案