K8s集群容灾演练：如何用阿里云SLB实现Master节点秒级切换？

K8s集群容灾演练如何用阿里云SLB实现Master节点秒级切换在云原生技术栈中Kubernetes集群的高可用性早已不是“锦上添花”而是“生死攸关”的生产级刚需。想象一下凌晨三点你的核心业务集群某个Master节点突然宕机kubectl命令瞬间卡死监控面板一片飘红——这种场景对任何运维团队来说都是噩梦。传统的多Master架构虽然提供了冗余但故障转移的平滑性、客户端连接的持续性、证书管理的复杂性这些细节才是真正考验系统健壮性的地方。今天我们不谈空洞的理论直接切入实战。我将带你深入一个真实的容灾演练场景如何利用阿里云负载均衡SLB构建一个能够实现Master节点秒级切换、对业务几乎无感知的高可用K8s集群。本文面向的是已经拥有基础集群、正在寻求生产级高可用方案的运维工程师和架构师。我们将聚焦于故障转移的实战细节特别是当server2这个Master节点模拟宕机时SLB如何将流量无缝切换到server3和server4并深入分析kubectl连接中断时间、证书更新机制等核心问题最后给出Worker节点的重连策略优化建议。1. 高可用架构的核心理解SLB在K8s中的角色在开始动手之前我们必须先厘清一个关键概念SLB在这里扮演的究竟是什么角色很多人误以为它只是简单地将流量分发给后端的多个apiserver。实际上在K8s高可用架构中SLB的核心价值在于为集群客户端kubectl、kubelet、controller-manager等提供一个稳定、唯一的访问端点并将这个端点的故障转移能力从分钟级提升到秒级甚至亚秒级。1.1 传统多Master架构的痛点在没有SLB的传统部署中高可用通常通过以下方式实现多个Master节点部署相同的apiserver、scheduler和controller-manager。使用Keepalived HAProxy维护一个虚拟IPVIP。客户端配置直接指向这个VIP。这种方式存在几个明显短板VIP切换依赖ARP广播在复杂的云网络环境中可能延迟较高且受网络设备影响大。客户端连接状态丢失VIP切换后所有TCP连接会中断客户端必须重新建立连接导致kubectl get pods等命令会短暂报错。配置管理复杂每个客户端都需要手动配置或通过DNS解析VIP增加了运维负担。1.2 阿里云SLB带来的范式转变阿里云SLB本文以传统型负载均衡CLB为例它完美适用于四层TCP流量转发作为一个全托管的服务彻底解决了上述问题特性传统VIP方案阿里云SLB方案对高可用的价值故障检测与切换依赖Keepalived脚本秒级到分钟级内置健康检查秒级自动剔除异常后端切换速度更快更可靠连接保持VIP切换导致所有TCP连接重置SLB实例IP不变连接由SLB代理后端故障对客户端透明客户端几乎无感知运维复杂度需自行维护HAProxy配置、Keepalived脚本控制台或API管理配置简单无需维护底层服务大幅降低运维负担扩展性水平扩展能力有限可根据性能需求选择不同规格后端可随时增删节点轻松应对集群规模增长提示阿里云SLB分为应用型负载均衡ALB七层适用于HTTP/HTTPS、网络型负载均衡NLB四层超高性能和传统型负载均衡CLB四层/七层。对于K8s apiserver的6443端口HTTPS理论上ALB和CLB都支持但更推荐使用CLB的TCP监听。因为apiserver的TLS终止发生在客户端与apiserver之间SLB无需解密流量只需做TCP转发这样性能最优且配置最简单。核心原理当你在SLB上创建一个监听器监听TCP 6443端口并将所有Master节点的6443端口添加为后端服务器后SLB就成为了集群的“流量入口”。所有发往SLB公网或私网IP:6443的请求都会被均匀或按策略分发到健康的Master节点。SLB会通过定期向后端发送TCP SYN包或配置的HTTP/HTTPS健康检查来探测后端服务状态。一旦某个Master节点的apiserver进程停止或主机宕机健康检查失败SLB会在秒级内自动将其从后端服务器组中移除流量不再转发至该故障节点而是由剩余的健康节点接管。2. 实战部署构建基于SLB的高可用K8s集群理论清晰后我们进入实战环节。假设我们已有三台Master节点server2, server3, server4和若干Worker节点目标是将其改造为通过SLB访问的高可用集群。2.1 前置准备与集群规划首先确保你的环境符合以下要求阿里云账号及足够的权限创建SLB和ECS实例。VPC网络所有ECS实例Master和Worker必须位于同一个VPC内确保内网互通。安全组需要放行SLB到Master节点6443端口的流量以及Master、Worker节点间的必要端口如2379-2380 for etcd, 10250 for kubelet等。我们的目标架构如下[阿里云SLB (私网IP: 10.0.0.100)] | | TCP:6443 | ----------------------------------- | | | [Master-1: server2] [Master-2: server3] [Master-3: server4] (10.0.0.3:6443) (10.0.0.4:6443) (10.0.0.5:6443) | | | ----------------------------------- | [etcd Cluster] | ----------------------------------- | | | [Worker-1] [Worker-2] [Worker-N]2.2 步骤一创建并配置阿里云私网SLB实例登录阿里云控制台进入负载均衡SLB产品页面。创建实例选择私网实例因为K8s集群内部通信通常走内网更安全、延迟更低、无公网流量费用。网络类型选择专有网络并选择你的K8s集群所在的VPC。根据预估的apiserver访问量选择适当的规格对于大多数场景入门规格已足够。添加TCP监听监听协议TCP监听端口6443(K8s apiserver默认端口)后端端口6443(转发到Master节点的端口)调度算法加权轮询或最小连接数均可。轮询更公平最小连接数可能更均衡。配置健康检查这是实现自动故障转移的关键。对于TCP监听SLB会尝试与后端服务器的6443端口建立TCP连接。响应超时时间建议设为5秒。健康检查间隔建议设为3秒。不健康阈值连续失败3次后判定为不健康。健康阈值连续成功2次后恢复为健康。这样配置意味着一个后端节点从健康到被剔除最快可能在5秒 * 3次 15秒内完成。你可以根据对故障敏感度的要求调整这些值更短的间隔和超时能更快发现故障但也会增加SLB和后端的负载。# 你可以通过阿里云CLI快速创建监听示例 # 首先获取你的SLB实例ID和VServerGroup ID如果使用默认服务器组可跳过创建VServerGroup aliyun slb CreateLoadBalancerTCPListener \ --LoadBalancerId lb-xxx \ --ListenerPort 6443 \ --BackendServerPort 6443 \ --Bandwidth -1 \ --Scheduler wrr \ --PersistenceTimeout 0 \ --HealthyThreshold 2 \ --UnhealthyThreshold 3 \ --HealthCheckConnectTimeout 5 \ --HealthCheckInterval 3添加后端服务器将你的三台Master节点server2, server3, server4的内网IP和端口6443添加到该监听的后端服务器组中。确保这些ECS实例的安全组入方向允许来自SLB所在安全组或SLB服务网段的TCP 6443端口访问。2.3 步骤二使用kubeadm初始化首个Master节点在server2上使用kubeadm初始化集群。最关键的一步是--control-plane-endpoint参数必须设置为SLB的私网IP地址和端口。# 在 server2 (10.0.0.3) 上执行 sudo kubeadm init \ --control-plane-endpoint10.0.0.100:6443 \ # 这是SLB的私网IP和端口 --pod-network-cidr172.16.0.0/16 \ # 与你选择的CNI插件匹配如Calico、Flannel --upload-certs \ # 自动上传证书供其他Master节点加入时使用 --apiserver-cert-extra-sans10.0.0.100,server2,server3,server4,公网IP或其他需要包含在证书中的域名/IP注意--apiserver-cert-extra-sans参数至关重要。它确保生成的apiserver证书包含了SLB的IP地址10.0.0.100以及所有Master节点的主机名/IP。这样当客户端通过SLB连接时证书验证才能通过避免x509: certificate is valid for ... not 10.0.0.100的错误。初始化成功后按照提示配置kubectlmkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config同时你会得到两个重要的命令其他Master节点加入集群的命令包含--control-plane和--certificate-key。Worker节点加入集群的命令普通的kubeadm join。2.4 步骤三加入其他Master节点在server3和server4上执行从server2初始化输出中得到的Master加入命令。这个命令已经包含了--control-plane-endpoint10.0.0.100:6443和必要的证书密钥。# 在 server3 (10.0.0.4) 和 server4 (10.0.0.5) 上分别执行 sudo kubeadm join 10.0.0.100:6443 \ --token your-token \ --discovery-token-ca-cert-hash sha256:your-hash \ --control-plane \ --certificate-key your-certificate-key执行成功后这些节点上也会生成/etc/kubernetes/admin.conf文件。请务必检查每个Master节点上的这个文件确保其中的server字段指向的是SLB地址https://10.0.0.100:6443而不是某个节点的具体IP。# 检查admin.conf配置 cat /etc/kubernetes/admin.conf | grep server # 应该输出server: https://10.0.0.100:64432.5 步骤四配置所有Worker节点修改所有现有Worker节点以及未来要加入的Worker节点的kubelet配置使其通过SLB连接apiserver。找到kubelet配置文件通常位于/etc/kubernetes/kubelet.conf或/var/lib/kubelet/config.yaml。修改apiserver地址将其中指向单个Master IP的地址改为SLB地址。# /var/lib/kubelet/config.yaml 片段 apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration ... clusterDNS: - 172.251.0.10 clusterDomain: cluster.local # 关键修改将原来的 server: https://10.0.0.3:6443 改为 # 注意这里不是直接修改kubelet.conf而是修改kubelet启动参数或kubeadm生成的配置文件。 # 更可靠的方法是使用kubeadm join时直接指定正确的endpoint。实际上更干净的做法是如果Worker节点尚未加入直接使用从server2初始化得到的Worker加入命令这个命令里的--discovery-token-unsafe-skip-ca-verification或自动发现的地址应该已经是SLB的地址。如果Worker节点已加入则需要更新/etc/kubernetes/kubelet.conf中的clusters.cluster.server字段。更新/etc/kubernetes/bootstrap-kubelet.conf如果存在。重启kubelet服务sudo systemctl daemon-reload sudo systemctl restart kubelet。验证Worker节点状态在任一Master节点上执行kubectl get nodes所有Worker节点应显示为Ready状态。至此一个基于阿里云SLB的高可用K8s集群架构就搭建完成了。此时所有客户端包括kubectl、kubelet、scheduler等都将通过https://10.0.0.100:6443这个统一的入口与集群交互。3. 模拟故障与深度分析SLB秒级切换的幕后架构搭建好了但我们更关心的是它是否真的“高可用”。现在让我们模拟server2节点宕机并深入观察和分析整个故障转移过程。3.1 故障模拟与现象观察初始状态确认在SLB控制台确认三台Master节点均为健康状态。模拟宕机在server2上直接关闭apiserver服务或更暴力地关机。# 在 server2 上执行 sudo systemctl stop kube-apiserver # 或者 sudo shutdown -h now观察SLB控制台等待约15-30秒取决于你设置的健康检查参数你会看到server2的健康状态从正常变为异常并且其权重可能变为0意味着SLB不再向其转发任何新流量。客户端体验测试在另一台机器上使用配置了SLB地址的kubectl持续执行命令。# 在一个循环中持续获取pod状态观察是否有中断 while true; do kubectl get pods -n kube-system 21 | head -n 3; sleep 1; done理想情况下你应该看不到任何错误输出命令会持续成功执行。这是因为SLB在TCP层工作对于已建立的连接如果server2是当前连接的后端当server2宕机该TCP连接会中断kubectl客户端会收到一个连接错误。但是由于kubectl命令通常是短连接执行完即断开下一次循环执行时kubectl会向SLB发起新的TCP连接此时SLB已经将server2剔除新连接会被分配到健康的server3或server4上因此从用户角度看只有极短暂的失败可能一次循环失败随后立即恢复。3.2 关键指标深度分析1. kubectl连接中断时间这个时间主要由以下几部分构成SLB健康检查发现时间即从server2apiserver进程停止到SLB健康检查连续失败达到“不健康阈值”的时间。这是我们之前配置的响应超时(5s) * 不健康阈值(3) 15秒。这是最大可能时间实际网络丢包可能导致更快失败。SLB后端服务器剔除与流量切换时间SLB判定后端不健康后将其从转发池中移除的时间几乎是瞬间的毫秒级。客户端重连时间对于像kubectl这样的命令行工具它不内置连接池和重试机制但k8s client-go有。当连接失败后需要用户或脚本重新发起请求。如果使用client-go的客户端如某些控制器其内置的指数退避重试机制可能会在几百毫秒到几秒内自动重试并连接到新的健康后端。因此对于交互式命令中断时间≈SLB健康检查发现时间最坏15秒。对于自动化控制器中断时间可能更短。2. 证书更新机制这是高可用集群另一个容易踩坑的地方。我们的证书是在初始化时用--apiserver-cert-extra-sans包含了SLB IP和所有Master IP的。这意味着证书是通用的无论SLB将请求转发到哪个Master节点该节点提供的证书都包含SLB的IP(10.0.0.100)因此客户端验证通过。无需定期更新只要SLB的IP不变且Master节点IP都在证书的SAN列表中证书就一直有效。新增Master节点如果需要扩容Master新节点加入时使用的证书密钥是初始化时上传的其生成的证书也包含所有初始的SAN。但新节点的IP如果不在初始SAN列表中需要手动更新apiserver证书或者更简单的方法在初始化第一个节点时尽可能将未来可能用到的IP段或域名通过--apiserver-cert-extra-sans加入。3. etcd集群的健壮性Master节点的高可用不仅仅在于apiserver还在于底层的etcd集群。我们的三个Master节点也部署了etcd成员。当server2宕机时如果etcd是独立部署的且三个节点都是投票成员那么失去一个节点etcd集群仍能正常读写剩余2个节点满足quorum。如果server2上的etcd进程也停止了etcd集群会自动将其标记为不健康领导者选举会在剩余节点间进行。只要多数节点2存活etcd集群就可用apiserver就能从健康的etcd节点获取数据。关键是要确保kube-apiserver的--etcd-servers参数指向所有etcd节点例如https://10.0.0.3:2379,https://10.0.0.4:2379,https://10.0.0.5:2379这样当一个etcd节点故障时apiserver可以自动尝试其他节点。3.3 故障恢复验证将server2恢复后启动apiserver服务SLB的健康检查会重新探测到其6443端口可用。经过连续成功次数达到“健康阈值”后SLB会将其重新加回后端服务器组流量开始重新分发到server2。这个过程同样对客户端透明。4. 生产级优化与进阶策略基础的秒级切换实现了但要达到真正的生产级稳健还需要考虑以下优化点。4.1 Worker节点kubelet重连策略优化默认情况下kubelet与apiserver的连接断开后会尝试重连。但我们可以优化其参数使其更适应网络波动或短暂的主机故障。编辑kubelet的systemd服务文件/etc/systemd/system/kubelet.service.d/10-kubeadm.conf或kubelet配置文件调整以下参数# /var/lib/kubelet/config.yaml 中可调整的部分 apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration ... # 增加与apiserver通信的QPS和突发值在节点数量多时可能有用 kubeAPIQPS: 50 kubeAPIBurst: 100 ... # 以下参数通常在kubelet命令行参数中设置 # 在 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf 中修改 [Service] EnvironmentKUBELET_KUBECONFIG_ARGS--bootstrap-kubeconfig/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig/etc/kubernetes/kubelet.conf EnvironmentKUBELET_CONFIG_ARGS--config/var/lib/kubelet/config.yaml # 添加或修改以下参数 EnvironmentKUBELET_EXTRA_ARGS--node-status-update-frequency10s --runtime-request-timeout15m --image-pull-progress-deadline30m --streaming-connection-idle-timeout30m更关键的是确保kubelet在apiserver不可用时不会过于频繁地重启或标记自己为不健康。kubelet本身有重试逻辑通常不需要额外配置。但你需要监控kubelet日志观察在SLB切换期间是否有异常。4.2 多可用区部署与SLB高可用对于更高要求的容灾场景可以考虑Master节点跨可用区部署将三个Master节点分别部署在同一个地域的不同可用区AZ内避免单个可用区故障导致整个控制平面瘫痪。SLB实例本身的高可用阿里云SLB实例本身采用集群部署具备高可用性。但对于极致要求可以在前端再结合全球加速或DNS轮询实现跨地域容灾。4.3 监控与告警搭建完善的监控体系对以下指标设置告警SLB后端服务器健康状态任何Master节点健康检查失败立即告警。apiserver请求错误率通过Prometheus监控apiserver_request_total和apiserver_request_errors指标。etcd集群健康状态监控etcd_server_has_leader和etcd_server_leader_changes_seen_total。控制平面组件状态确保scheduler和controller-manager也以多副本模式运行且健康。4.4 定期容灾演练高可用不是“配置即完成”必须通过定期演练来验证。建议每月或每季度执行一次演练计划内演练在业务低峰期手动在SLB控制台摘除一个Master后端观察业务影响。模拟故障随机选择一台Master节点重启其kube-apiserver服务或模拟网络分区。记录与复盘详细记录故障发现时间、切换时间、业务影响时长并不断优化健康检查参数和应急预案。通过以上四个部分的拆解我们从理论到实践从搭建到优化完整地掌握了利用阿里云SLB构建高可用K8s集群并实现Master节点秒级切换的全套方案。记住真正的“高可用”是一个持续的过程它依赖于清晰的架构、正确的配置、细致的监控和不断的演练。当你对这套流程了然于胸面对真正的故障时才能做到从容不迫。