阿里云SLB与K8S高可用集群实战：从零搭建到故障转移测试

1. 为什么你需要一个高可用的K8S集群？

想象一下，你负责一个核心的在线业务系统，它运行在一个单Master节点的K8S集群上。某个深夜，这台Master节点的ECS实例因为一次意外的硬件故障或者一次手滑的误操作，直接宕机了。接下来会发生什么？你的所有Pod调度、服务发现、配置更新都会瞬间停摆，业务中断，告警电话响个不停，而你只能一边手忙脚乱地恢复节点，一边承受着来自各方的压力。

这就是单点故障的可怕之处。对于生产环境，尤其是承载关键业务的系统，高可用（High Availability, HA） 不是一个“最好有”的选项，而是一个“必须有”的底线。一个高可用的K8S集群，意味着即使其中一个、甚至多个Master节点发生故障，整个集群的控制平面依然能正常工作，业务应用无感知，运维同学能睡个安稳觉。

那么，如何实现K8S集群的高可用呢？核心在于让多个Master节点协同工作，对外提供一个统一的访问入口。这个入口必须足够“聪明”，能够将客户端的请求（比如kubectl命令、Pod的调度请求）自动分发到健康的Master节点上，并且在某个节点故障时，立即将其从服务列表中剔除。在云上环境中，最直接、最可靠的方式就是利用云厂商提供的负载均衡服务。

在阿里云上，这个服务就是SLB（Server Load Balancer，现在也常被称为CLB/ALB）。它就像是一个站在集群前面的“交通指挥官”，我们只需要把多个Master节点的IP地址配置给它，它就会自动处理流量分发和健康检查。结合阿里云的ECS实例，我们可以用非常清晰的步骤，从零搭建起一个具备生产级可靠性的K8S高可用集群。这篇文章，我就将带你完整走一遍这个流程，从SLB的申请配置，到多Master集群的搭建，最后我们还会模拟节点故障，亲眼验证故障转移是否真的生效。整个过程我会结合我踩过的坑和最佳实践，让你不仅能搭起来，更能理解背后的原理。

2. 实战前的准备：规划与资源配置

动手之前，好的规划是成功的一半。我们需要明确整个架构，并准备好所有资源。这次实战的目标是构建一个经典的三Master多Worker高可用集群架构。

架构图景：我们会有3台Master节点（server2, server3, server4）和至少1台Worker节点（server6）。此外，还需要1台独立的服务器（server1）用于部署私有镜像仓库Harbor和NFS存储服务（方便后续演示有状态应用）。所有这些ECS实例都位于同一个专有网络VPC内，确保内网互通。最关键的是，我们需要一个内网SLB实例，它有一个虚拟IP（VIP，例如10.0.0.85），这个VIP将作为整个K8S集群对外的统一控制平面入口（control-plane-endpoint）。

资源清单与规格建议：

• Server1 (Harbor/NFS): 2核4G或更高。需要挂载数据盘用于存储镜像和NFS数据。
• Server2/3/4 (Master节点): 建议至少2核4G。Master节点运行etcd、kube-apiserver等关键组件，资源不能太紧张。生产环境根据集群规模（节点数、Pod数）酌情提升到4核8G或更高。
• Server6 (Worker节点): 根据你的业务应用需求来定，建议从4核8G起步。
• SLB实例: 选择私网实例，网络类型为专有网络，与ECS在同一VPC下。监听协议选择TCP，因为kube-apiserver默认使用6443端口提供HTTPS服务，这是一个TCP服务。

系统与组件版本统一：这是避免各种诡异问题的关键。我强烈建议所有节点使用相同的操作系统版本（如CentOS 7.9或Ubuntu 20.04），并提前确定好Docker和Kubernetes的版本。例如，我们可以选用：

• Docker: 20.10.x
• Kubernetes: 1.24.x (这是一个相对稳定且兼容性好的版本)
• kubeadm, kubelet, kubectl: 版本与Kubernetes一致。

基础环境初始化（所有节点都需要执行）： 这部分工作繁琐但至关重要，主要是为K8S的运行扫清障碍。

1. 关闭防火墙与SELinux：K8S需要自己管理网络规则。

   systemctl stop firewalld && systemctl disable firewalld
   setenforce 0
   sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
   

2. 关闭Swap分区：Kubernetes要求禁用Swap以确保内存管理和调度的正确性。

   swapoff -a
   sed