如何配置云计算平台的节点高可用切换？

配置云计算平台的节点高可用（HA）切换，核心逻辑其实就一句话：把“单点故障”的风险，通过冗余设计和状态同步机制，转移给集群中的其他健康节点。

这不仅仅是敲几行命令的事，而是一个涉及计算、存储、网络三个层面的系统工程。下面我从实战角度，拆解主流架构下的配置思路和关键坑点。

一、 先明确你的“节点”指什么？

在云原生和传统虚拟化语境下，“节点”通常有两种理解，配置策略完全不同：

1. 物理/虚拟机主机节点（Host Node）：比如 Kubernetes 的 Worker Node，或者 OpenStack/Nova 的物理宿主机。
2. 应用服务实例（Pod/Instance）：部署在节点上的具体业务程序。

绝大多数情况下，大家问的是第一种：当一台服务器宕机或网络断开时，上面的业务如何平滑迁移到另一台服务器上。

二、 主流技术栈的配置方案

1. Kubernetes 生态（当前最主流）

K8s 的高可用不是靠“重启”，而是靠“调度器”和“控制器”。

• 控制平面高可用（Control Plane HA）：

  • 核心组件：etcd, kube-apiserver, kube-scheduler, kube-controller-manager。
  • 配置要点：
    • etcd：必须奇数节点（3/5/7），采用 Raft 协议。只要超过半数节点存活，集群元数据就不会丢。配置时注意磁盘 I/O 性能，etcd 对延迟极度敏感。
    • API Server：前端挂负载均衡（LVS/Nginx/Cloud LB），后端多个 API Server 实例无状态运行。
    • Scheduler/Controller：默认就是多副本运行，Leader Election 机制会自动选主，不需要人工干预切换。

• 工作节点高可用（Worker Node HA）：

  • 原理：K8s 本身不保证单个 Pod 在节点故障时秒级迁移（那是 CNI 和 Volume 的事）。它做的是“驱逐”和“重新调度”。
  • 关键配置：
    • PDB (Pod Disruption Budget)：防止运维操作或节点故障时，同一服务的副本全部被挤掉。
    • Anti-Affinity：在 Deployment 中配置 podAntiAffinity，强制将同一个服务的不同副本分散到不同的 Node 上。这样一台 Node 挂了，只影响部分流量，而非全量。
    • Node Taints/Tolerations：配合自动伸缩组（如 AWS ASG 或阿里云 ECS 弹性伸缩），当监控检测到 Node 异常，自动剔除并创建新 Node，K8s 自动将 Pod 调度到新节点。

• 存储与网络依赖：

  • PV/PVC：如果用的是本地盘（Local PV），节点挂了数据就丢了，无法迁移。必须使用支持多活挂载的网络存储（如 Ceph RBD, NFS, 云厂商的 EBS/CPFS），且文件系统需支持 shared 模式（如 ODFS, CephFS）。
  • CNI 插件：确保 Calico/Cilium 等网络插件支持跨节点 IP 复用或 BGP 路由快速收敛，否则 Pod 迁移后 IP 变了，连接会断。

2. 传统虚拟化（OpenStack / VMware vSphere）

• vSphere HA：

  • 开启 DRS（分布式资源调度）和 HA 功能。
  • 配置 Host Isolation Response：当 ESXi 主机心跳丢失，但还能 ping 通网关时，判断是网络分区还是主机宕机，决定是重启 VM 还是保持原状。
  • 关键点：预留足够的 CPU/Memory 资源用于故障转移（Failover Slots）。

• OpenStack Nova HA：

  • Compute Service：Nova-compute 进程本身无状态，多节点部署即可。
  • 数据库与消息队列：MySQL + Galera Cluster / MHA，RabbitMQ + Clustering。这些中间件的高可用才是瓶颈。
  • Live Migration：依赖共享存储（NFS/Ceph）。如果存储不可用，只能做冷迁移（关机->开机）。

3. 云厂商托管服务（阿里云 ACK / 腾讯云 TKE / AWS EKS）

如果你用的是公有云的托管 K8s 或容器服务，你不需要手动配置底层节点的 HA。

• 你需要做的是：
  • 选择多可用区（Multi-AZ）部署：这是最关键的一步。将 Master 节点和工作节点分布在不同物理机房（可用区）。
  • 启用自动修复：云厂商会在检测到节点硬件故障时，自动隔离节点并触发替换流程。
  • 配置集群自动伸缩：设置最小/最大节点数，让系统在负载波动或节点缺失时自动调整规模。

三、 避坑指南：90% 的问题出在这里

很多人以为配了 HA 就万事大吉，结果真出事时发现数据丢了或服务没起来，原因通常是：

1. 脑裂（Split-Brain）：

   • 网络分区导致两个节点都认为自己是主节点，同时写入数据，导致数据损坏。
   • 对策：使用仲裁设备（Quorum Disk/Witness），或在 etcd 中配置 --heartbeat-interval 和 --election-timeout 合理值，避免过于敏感。

2. 存储 IO 瓶颈：

   • 节点 A 故障，大量 Pod 瞬间迁移到节点 B，B 的磁盘 IO 被打满，导致新起的 Pod 也挂掉，引发雪崩。
   • 对策：限制并发迁移数量（如 K8s 的 max-pods-per-node 和调度器参数），使用高性能 NVMe SSD，或采用存算分离架构。

3. 会话状态丢失：

   • 应用是无状态的吗？如果用户登录态存在内存或本地文件，节点切换后用户会被踢下线。
   • 对策：应用必须无状态化，Session 存入 Redis/Memcached，配置外部负载均衡器进行粘性会话（Sticky Session）或完全无状态转发。

4. DNS 缓存：

   • 内部 DNS 解析有 TTL，节点 IP 变更后，旧连接可能仍指向已死节点。
   • 对策：缩短 DNS TTL，或使用 Service Mesh（如 Istio）实现更细粒度的流量治理和服务发现。

四、 总结：如何验证你的 HA 配置是否有效？

别信文档，要信混沌工程。

1. 拔网线测试：在生产环境非高峰期，随机拔掉一个 Worker 节点的网线，观察：
   • 该节点上的 Pod 是否在预期时间内（如 30s-2min）被标记为 NotReady 并被驱逐？
   • 新的 Pod 是否在其他健康节点上成功启动？
   • 业务接口是否有可感知的中断？中断时长是多少？
2. 模拟磁盘故障：删除一个节点上的某个 Pod 的数据卷，看是否能从备份或其他副本恢复。
3. 压测结合：在 HA 切换期间进行持续压测，观察错误率峰值和恢复时间。

最后提醒：高可用没有银弹。对于大多数互联网业务，“多可用区部署 + 无状态设计 + 自动扩缩容” 比纠结于单机内的复杂 HA 配置更有效、更经济。如果你的业务允许分钟级停机，甚至可以考虑降级策略而非强一致性的实时切换。