★ FEATURED ARTICLE Rancher的高可用搭建圈内一直有个误区以为把Rancher Server容器在几台机器上各跑一遍前面挂个负载均衡就算HA。真正在生产环境做过的人都知道这套方案连第一个真实的故障都扛不过去——容器里的token、证书、数据库状态各自为政一旦某台机器上的副本掉线整个管理面就会出现各种不一致的脏数据。Rancher Server本身是Kubernetes多集群管理的控制面它下面往往挂着几十上百个业务集群。控制面一旦挂掉日常变更、告警联动、权限审批全部瘫痪。所以生产环境的Rancher业界通行做法是用RKERancher Kubernetes Engine先拉起一套独立的Kubernetes集群再把Rancher通过Helm部署进去。这套方案覆盖Rancher 2.x整个生命周期也是官方文档在高可用章节一直推荐的标准路径。这份手顺就是从裸节点起步按生产标准把整套HA环境完整走一遍。所谓手顺其实就是从制造业传出来的说法——按固定顺序执行的可重复操作流程适合负责Rancher落地的运维同学或者正在做生产架构规划的同学直接按步骤抄作业。1. 架构选型为什么生产环境必须把Rancher装进Kubernetes1.1 Rancher在集群管理体系里的真实位置很多刚接触Rancher的人把它当成一个普通的Web管理面板来用。这个理解不能说错但会低估它对基础设施的依赖。Rancher的核心能力不只是展示几个Kubernetes集群的状态它还要承担多集群的统一认证、RBAC策略下发、项目资源配额、监控告警和审计日志。这些能力全部依赖Rancher自身所依托的etcd和Kubernetes API来存储状态、派发任务。也就是说Rancher自身是一个运行在Kubernetes之上的复杂应用它的元数据、用户账号、集群注册信息都会写入自己所在K8s集群的etcd。如果只在单台机器上docker run一个容器机器重启、磁盘故障、docker daemon异常都可能导致管理面长时间不可用。更麻烦的是单节点模式下数据和状态都在容器里想迁移都难。1.2 三条技术路线的对比生产环境规划Rancher我见过的主要有三条路线。一是直接在多个节点上启动Rancher容器再用NFS共享数据或手工同步。这种做法维护成本极高官方也不支持属于看起来高可用实际上全是单点。二是用RKE1创建一套独立Kubernetes集群然后在上面通过Helm安装Rancher。这是Rancher 2.x从早期到中期最主流的方案配套工具成熟etcd快照、集群恢复、节点升级都有现成命令。三是从2.7左右开始官方主推的RKE2方案部署方式更贴近K8s原生但引入了新组件和新的升级逻辑运维团队需要重新适应。三条方案的特点放在一起对比会更直观方案部署难度etcd管理升级路径适用场景多容器 手工同步低混乱状态不一致不明确演示/测试生产不推荐RKE1 Helm中rke命令快照/恢复成熟稳定现有团队对RKE/文档熟悉RKE2 三节点中高内置快照/配置文件新但持续演进新项目愿意跟进官方新方案我这次手里这套环境是老团队维护目标Rancher版本是2.6.x大家已经习惯用rke命令管理集群状态所以最终选了RKE1。这个选择放到今天也不算过时生产环境最重要的不是追新而是可控。1.3 一句话说清最终架构整套环境的链路是这样的办公网用户访问https://rancher.example.com域名解析到一个虚拟IPVIPVIP由keepalived管理流量交给HAProxyHAProxy以四层方式把TCP 443转发到三个Rancher节点中的任意一个节点上的Nginx Ingress Controller负责TLS终止再把请求转发到cattle-system命名空间里的Rancher三个Pod副本Rancher通过API访问自己所在的Kubernetes集群同时通过agent与一个个下游业务集群保持长连接。理解这条链路很重要后面每一步配置、每一个故障排查都绕不开它。2. 基础设施清单节点、VIP、端口和DNS先把地基画清楚2.1 节点角色与资源规划生产环境Rancher管理集群我建议至少三台节点。在小规模场景下每台节点同时承担controlplane、etcd、worker三个角色就够了如果以后要纳管的集群数量很大或者Rancher上要跑的监控数据量猛增再考虑把worker角色拆出去单独部署。拿我这次环境举例规划的节点信息如下节点IP角色配置建议rke-node-110.10.20.11controlplane etcd worker8C16Getcd独立SSD盘rke-node-210.10.20.12controlplane etcd worker8C16Getcd独立SSD盘rke-node-310.10.20.13controlplane etcd worker8C16Getcd独立SSD盘lb-1 / lb-210.10.20.21 / 10.10.20.22HAProxy Keepalived4C8G即可管理集群本身负载不重真正吃资源的是etcd的磁盘IO而不是CPU。控制面三节点全角色部署可以保证任何一台节点宕机etcd仲裁仍然超过半数组件。2.2 VIP、DNS和hosts文件VIP我规划为10.10.20.100。DNS上把rancher.example.com解析到VIP办公网和运维网都能访问。这里有个细节企业内部DNS偶尔会出问题所以我会在三个Rancher节点和两台LB的 /etc/hosts 里把hostname和内部IP写死避免组件之间跨网络解析时依赖外部DNS。另外hostname在RKE部署前就要定好不要中途修改。Kubelet注册节点时用的是hostname如果部署到一半把节点名改了会出现旧的NotReady节点残留处理起来比较麻烦。2.3 端口清单与防火墙放行生产环境的端口放行最怕的就是开多了和漏开了。以这套架构为例需要放行的端口集中在以下几个方向方向协议/端口用途办公网 - VIPTCP 443Rancher UI办公网 - VIPTCP 80HTTP跳转HTTPS部署机 - 三节点TCP 22RKE通过SSH执行部署三节点之间TCP 6443Kubernetes API三节点之间TCP 2379/2380etcd客户端与peer三节点之间UDP 8472VXLAN隧道默认flannelkeepalived的VRRP报文如果交换机开启了组播隔离还要在安全组里放行相关协议。很多人只记得开443结果部署完发现VIP漂移不了一查就是VRRP报文被防火墙丢了。2.4 提前写好环境登记表每次搭建Rancher前我会先做一张环境登记表把节点IP、主机名、角色、VIP、域名、证书负责人、备份路径一次填完。别小看这个动作生产环境出问题时这张表能节省大量排查时间。我踩过的坑是环境搭到一半发现两台节点的IP段不在同一网卡下导致etcd peer之间互相不通最后只能重新编排IP。前期把清单画清楚比后期返工便宜太多。3. 节点初始化从裸机到可被RKE接管的基础配置3.1 内核参数与模块加载RKE在部署Kubernetes时对节点操作系统有一组硬性要求任何一个不满足都有可能在rke up阶段或者集群运行后冒出各种难以解释的现象。最基础的是加载br_netfilter和overlay内核模块然后设置一组sysctl参数。为了不让这些操作散布在多个步骤里我习惯把这些配置写成一个文件一次性下发到三台节点避免每台机器遗漏不同的参数。下面这段脚本我在Ubuntu 20.04和22.04上都验证过可以原样复制。cat /etc/sysctl.d/99-rancher.conf EOF net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 vm.swappiness 0 fs.inotify.max_user_instances 8192 fs.file-max 2097152 vm.max_map_count 262144 EOF sysctl --system modprobe br_netfilter modprobe overlay swapoff -a sed -i / swap / s/^\\(.*\\)$/#\\1/ /etc/fstab参数含义很简单bridge-nf让防火墙规则对桥接流量生效是网络插件工作的前提ip_forward用于容器流量转发swappiness设成0是避免swap拖慢etcd这种IO敏感组件。inotify和file-max的上限防止节点上文件句柄或inotify实例耗尽这在Pod数量多的时候经常遇到。3.2 Docker安装与版本锁定RKE1通过SSH在节点上执行docker命令所以Docker的版本和稳定性直接决定集群能不能起来。以Ubuntu 20.04为例推荐直接从Docker官方仓库安装并锁定版本apt-get update apt-get install -y ca-certificates curl gnupg install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | tee /etc/apt/sources.list.d/docker.list /dev/null apt-get update apt-get install -y docker-ce5:20.10.24~3-0~ubuntu-focal docker-ce-cli containerd.io apt-mark hold docker-ce docker-ce-cli containerd.io systemctl enable --now docker为什么一定要apt-mark hold生产环境最防不胜防的就是某个例行升级把docker daemon版本悄悄改了RKE不兼容新版本集群出现一堆异常。我在早期维护一套环境时吃过这个亏升级完docker整组节点被Kubelet标记为NotReady事后才意识到是版本漂移。除了版本还要注意节点用户权限。RKE通过配置里指定的user登录节点执行docker命令如果这个用户不是root需要把它加入docker组否则rke up会报权限错误。3.3 etcd磁盘IO敏感别省这块etcd是Rancher管理集群最核心的存储Rancher的配置、用户、集群注册信息最终都落在etcd里。它每次写入都要落盘而且对延迟极其敏感一条毫秒级的写请求排队都可能拖慢整个控制面。生产环境强烈建议把etcd的数据目录放到独立SSD数据盘上。RKE默认会把etcd数据放在宿主机的/var/lib/etcd目录所以至少这个目录要承载在SSD盘上不要在机械盘上尝试跑生产环境性能差距在故障场景下会被放大得很明显。我自己的标准是控制面节点配一块数据盘单独挂载到/var/lib/etcd文件系统用ext4或xfs。硬件条件有限时至少保证etcd目录不要和系统盘、Docker数据目录混用。否则一旦日志把系统盘写满etcd会先跟着出问题——这个后面故障复盘时还会再提到。3.4 时间同步etcd的隐形依赖很多Kubernetes问题排查到最后都会发现根因其实是时钟漂移。etcd对节点间时间偏移极其敏感时间差距一旦超过阈值就会导致心跳乱序、leader频繁切换最终表现为整个集群间歇性不可用。所以三台节点在初始化时就要统一配置chrony指向企业内网NTP源。配置好之后一定要当场验证我习惯执行timedatectl status查看系统时间再执行chronyc sources确认同步源的状态和延迟。这一步看似简单但漏掉的后果往往要等出故障时才暴露出来。之前有一回某台虚拟机重启后chrony服务没起来时钟慢了两分钟etcd的选举日志刷了一整屏排查了一晚上才定位到时间问题。3.5 部署机的准备工作RKE是从部署机的角度发起操作的所以部署机只需要安装rke、kubectl和helm三个工具并保存三台节点的SSH私钥。强烈建议不要用root登录节点而是创建一个专门的运维用户把公钥部署到三台节点的~/.ssh/authorized_keys里。这样RKE配置里指定user为这个运维用户即可安全性和可维护性都会好很多。部署机上最好也固定工具版本我习惯把rke、kubectl版本写在环境登记表里。这里再提醒一次rke工具不是越新越好它的版本要和目标Rancher版本、目标Kubernetes版本匹配。版本错配是rke up阶段最常见的失败原因之一。4. 三节点Rancher集群的RKE部署实录cluster.yml与rke up4.1 一份可复用的cluster.yml在部署机上创建目录比如/opt/rancher-ops把SSH私钥放进去然后写cluster.yml。三节点全角色的一套配置文件大致长这样nodes: - address: 10.10.20.11 hostname_override: rke-node-1 user: ops role: [controlplane, etcd, worker] ssh_key_path: /opt/rancher-ops/id_rsa - address: 10.10.20.12 hostname_override: rke-node-2 user: ops role: [controlplane, etcd, worker] ssh_key_path: /opt/rancher-ops/id_rsa - address: 10.10.20.13 hostname_override: rke-node-3 user: ops role: [controlplane, etcd, worker] ssh_key_path: /opt/rancher-ops/id_rsa services: etcd: snapshot: true creation: 6h retention: 6h backup_config: interval_hours: 12 retention: 3 kube-api: service_node_port_range: 30000-32767 kubelet: extra_args: max-pods: 200 ingress: provider: nginxhostname_override是很有用的字段。如果节点本身主机名不规范或者有多张网卡导致地址选择混乱可以直接在这里强制指定。address是RKE用来SSH的地址如果节点有内网外网多张网卡还要加internal_address字段让集群内部组件走内网通信避免流量绕公网。services.etcd里的snapshot、creation和retention控制的是etcd自动快照的生成与保留。我习惯把自动快照间隔设为6小时、保留6份另外再用backup_config做一层更稳妥的定期备份间隔12小时、保留3份。注意快照目录默认在/var/lib/etcd/snapshots千万别把它和etcd数据放在同一个物理磁盘上否则磁盘一坏就全没了。4.2 为什么角色要三件套全给可能会有同学问controlplane节点为什么还要带worker其实对一套管理型集群来说Rancher自身的Pod数量不算多三节点全角色完全可以承载。而且这样的部署形态最简洁任何一台节点宕机其余两台仍能保证etcd仲裁和API可用Rancher的Pod也能在其它节点重新调度起来。如果纳管集群规模很大或者要在管理集群上额外跑监控、日志组件再拆出独立worker节点也不迟。4.3 拨动rke up第一次耗时最长配置写好后执行cd /opt/rancher-ops rke up --config cluster.yml第一次rke up会拉取一堆镜像kube-apiserver、etcd、nginx-ingress、metrics-server、coredns等。网络环境一般的话这一步可能拖很久。解决办法是在Docker daemon配置里设置镜像加速源registry mirror并把镜像预拉到三台节点上。注意镜像下载慢的时候不要反复按CtrlC重启rke的状态文件会残留最好是等日志明确报错后再处理。如果一切顺利结束后当前目录会生成kube_config_cluster.yml和cluster.rkestate。用kubeconfig验证kubectl --kubeconfig kube_config_cluster.yml get nodes三台节点都是Ready状态说明RKE这一步已经完成。4.4 立刻备份三样东西少一样都危险rke up完成后部署机上最宝贵的三个产物是cluster.yml、kube_config_cluster.yml、cluster.rkestate。其中cluster.rkestate尤其重要它记录了集群当前完整状态。没有它后续执行etcd恢复、节点替换、集群更新时rke无法识别现有集群等于钥匙丢了。我会把这三个文件加上etcd快照一起打包加密后放到灾备目录。任何一次变更操作之前都要重新备份一次cluster.rkestate。这个习惯在恢复演练和故障处置时价值巨大。4.5 RKE阶段常见失败点RKE阶段我遇到过的失败主要集中在三类一是SSH连通性密钥权限太高或者用户不在docker组二是镜像拉取超时三是节点之间网络端口没放行特别是etcd端口。排查时不要盯着rke日志最后几行无脑重试先用ssh、nc、openssl s_client这类工具逐层确认再回到rke up。5. 负载均衡与VIPHAProxy Keepalived 的落地细节5.1 前置判断什么时候可以跳过这一节如果企业已经买了商业负载均衡或云上NLBRancher架构可以简化直接把NLB后端指向三台节点的443端口DNS解析到NLB即可后面关于HAProxy的配置都可以跳过只要保证健康检查指向的是TCP 443而不是节点管理地址。如果机房是自建物理机或云主机没有统一的LB服务那么HAProxy加Keepalived就是性价比最高的组合。下面写的是自建LB场景采用四层转发方案思路和云上NLB完全一致理解后很容易迁移。5.2 HAProxy只做四层透传TLS证书交给Ingress这里有个关键的架构决策HAProxy用mode tcp而不是mode http。原因在于Rancher入口的TLS证书已经有了证书由节点上的Nginx Ingress统一终结。如果HAProxy做七层反代就必须在LB上再维护一份证书而且要把证书配置、续期流程在LB上重复一遍完全没有必要。四层转发的好处是简单、稳定、天然支持WebSocket长连接。Rancher UI里终端、日志等实时功能都依赖WebSocket四层模式下连接直接透传不用额外调超时。global log /dev/log local0 maxconn 4096 defaults log global mode tcp retries 3 timeout connect 5s timeout client 60s timeout server 60s frontend rancher_frontend bind *:80 bind *:443 default_backend rancher_backend backend rancher_backend balance roundrobin option tcp-check tcp-check connect port 443 server rke-node-1 10.10.20.11:443 check inter 3s fall 3 rise 2 server rke-node-2 10.10.20.12:443 check inter 3s fall 3 rise 2 server rke-node-3 10.10.20.13:443 check inter 3s fall 3 rise 2tcp-check是用来做后端健康检查的它每3秒尝试和节点443端口建立TCP连接连续失败3次把节点标记为DOWN连续成功2次标记为UP。这样的健康检查比单纯ping节点IP要可靠得多它能直接反映出Ingress层面的接收能力。5.3 Keepalived让VIP在故障时自动漂移两台LB上分别安装keepalived一个MASTER一个BACKUP。配置核心如下vrrp_script check_haproxy { script /usr/bin/killall -0 haproxy interval 2 weight -2 } vrrp_instance VI_RANCHER { state MASTER # BACKUP机器上写 BACKUP interface eth0 virtual_router_id 55 priority 150 # BACKUP机器写 120 advert_int 1 virtual_ipaddress { 10.10.20.100/24 dev eth0 } track_script { check_haproxy } }track_script是灵魂。它每2秒检查一次本机haproxy进程是否存活如果进程挂了权重自动降低VIP会立刻漂移到另一台LB。这样即使haproxy卡死或崩溃入口流量也不会断在单一节点上。有个容易被忽略的细节如果交换机启用了组播限制VRRP广播报文会被丢弃导致两台LB都认为自己是MASTERVIP冲突。此时要在配置里加上unicast_peer把对端的真实IP明确告诉keepalived用单播方式通告心跳。5.4 上生产前的验证动作配置完成后按这个顺序验证第一ip addr show eth0确认VIP在主LB上第二从办公网访问https://rancher.example.com确认证书和页面正常第三故意停掉主LB的haproxy进程观察VIP是否在几秒内漂移到BACKUP再恢复主LB状态。我每次都会把这个故障演练记录下来作为生产环境运维档案的一部分。6. Helm安装Rancher Server证书、Secret和关键参数6.1 证书是前置条件别等装完再想在Helm安装Rancher之前就得先把证书准备好。生产环境推荐使用企业内部CA签发的证书SAN里必须包含Rancher访问域名rancher.example.com最好再把VIP加上。证书有效期建议直接申请三年同时定好到期续期流程。没有内部CA体系的也可以用公有信任的自动签发证书但要注意这类证书有效期短续期自动化要提前配好。6.2 先创建两个Secret这是最常见的坑Rancher需要两个Secret。第一个是Ingress使用的证书密钥第二个是内网CA的根证书。操作如下kubectl create ns cattle-system kubectl -n cattle-system create secret tls tls-rancher-ingress \ --certfullchain.pem \ --keyprivate.key kubectl -n cattle-system create secret generic tls-ca \ --from-filecacerts.peminternal-ca.pem很多人第一次装Rancher只创建了tls-rancher-ingress忘了tls-ca结果装完以后Rancher内部的webhook、审计、集群代理组件互相不信任界面能打开但操作经常报奇怪的TLS错误。tls-ca这个Secret的作用就是让Rancher内部组件能够验证由内网CA签发的证书。6.3 Helm安装命令与参数解释用Helm 3安装Rancher官方charthelm repo add rancher-stable https://releases.rancher.com/server-chart/stable helm repo update helm upgrade --install rancher rancher-stable/rancher \ --namespace cattle-system --create-namespace \ --set hostnamerancher.example.com \ --set replicas3 \ --set ingress.tls.sourcesecret \ --set privateCAtrue \ --set bootstrapPasswordYourStrongPassw0rd!逐个说明hostname是访问域名必须和证书SAN一致replicas设成3对应三个节点上跑3个Rancher副本ingress.tls.sourcesecret表示证书来自前面创建的secret而不是cert-manager自动签发privateCAtrue配合tls-ca secret使用bootstrapPassword是首次登录时需要使用的管理员临时密码。部署完成后可以用如下命令跟踪状态kubectl -n cattle-system rollout status deployment/rancher kubectl -n cattle-system get pods6.4 首次访问与初始化浏览器打开https://rancher.example.com使用bootstrapPassword登录系统会要求设置新的admin密码。之后进入主界面Rancher会自动把当前集群登记为local集群。到这里Rancher Server本身已经高可用三个Pod副本、三个etcd节点、两套LB和VIP在前面承接流量。我习惯把首次登录后的页面截图存进环境档案作为交付证据和后续对比基准。有一点要特别说明Rancher应用本身不依赖持久化卷它的所有状态都存在K8s的etcd和secret中。所以Pod哪怕全部被删掉也能重新拉起并恢复状态。这也是为什么前面反复强调etcd备份的重要性——Rancher高可用的本质其实就是这套底层Kubernetes集群的高可用。7. 生产上线前的验证清单与日常运维基线7.1 全链路检查清单新环境交付给业务方之前我会按下面这张清单过一遍检查项方法预期DNS解析nslookup rancher.example.com返回VIP 10.10.20.100VIP联通ping 10.10.20.100通HTTPS访问curl -kI https://rancher.example.com返回200或302证书有效期openssl s_client -connect 域名:443 -servername 域名剩余天数充足Rancher Podkubectl -n cattle-system get pods全部 Runninglocal集群健康kubectl get nodes -A三节点 Ready下游集群注册在UI中导入测试集群状态Active这个清单每次上线都要走一遍别觉得重复。生产事故里相当一部分就是上线前少查了一两项导致域名、证书、VIP、后端这些环节埋了雷。7.2 备份etcd快照、Rancher备份和恢复演练RKE阶段已经在cluster.yml里配置了etcd自动快照手动备份则用rke etcd snapshot-save --name manual-backup-202501 --config cluster.yml快照文件会落到节点的/var/lib/etcd/snapshots目录。光有快照还不够我建议再装一套Rancher Backup Chart它可以备份Rancher的CRD和全局配置把备份文件推到对象存储或NFS上。etcd快照和Rancher备份配合使用才能保证完整恢复。恢复演练必须真的做过一次。我会准备一套临时环境按照备份恢复手顺把数据还原验证登录、下游集群列表、权限菜单都还在。如果演练都没做所谓高可用也就是个纸面方案。7.3 升级顺序先K8s再RancherRancher升级有一个雷打不动的顺序先升级底层Kubernetes集群再升级Rancher chart。底层K8s升级用rke up --update-onlyRKE会按照cluster.yml里指定的版本增量更新。升级前看官方兼容矩阵确认RKE版本、K8s版本和Rancher版本三者匹配。我见过不少团队图省事直接helm upgrade把Rancher升到新大版本结果底层的RKE/K8s版本太老一堆API兼容问题冒出来。运维老手的原则是小版本谨慎升大版本先看release notes再动手。7.4 巡检节奏与告警生产环境跑起来之后巡检不靠人肉要变成自动化任务。我维护这套环境时至少会配置以下告警VIP端口拨测失败、haproxy进程挂掉、任一节点磁盘使用率超过80%、etcd leader频繁切换、证书剩余天数低于30天。每季度做一次LB故障切换演练每半年做一次完整恢复演练。这些动作写进运维日历比出事后再熬夜救火划算得多。8. 故障复盘生产里真实翻过的车8.1 案例一证书过期全站UI直接不可用管理集群上线大概第11个月某天早上业务方反馈Rancher页面打不开。我第一时间用curl -v访问域名发现TLS握手直接失败再看证书截止日期正好过期两天。整个链路排查很顺利因为现象太典型了。修复步骤分三步第一步从内部CA重新申请证书SAN保持不变第二步更新Ingress的Secret第三步重新加载Ingress Controller。具体命令如下kubectl -n cattle-system create secret tls tls-rancher-ingress \ --certfullchain.pem --keyprivate.key \ --dry-runclient -o yaml | kubectl apply -f - kubectl -n cattle-system delete pods -l apprancher --force --grace-period0删Pod是为了让Ingress和Rancher重新加载证书。这个案例的教训有两点一是证书到期告警必须提前配不要依赖人的记忆二是证书内容要保证完整链很多中间证书缺失的情况浏览器报错信息会很怪容易误导排查方向。8.2 案例二系统盘写满etcd跟着遭殃另一套环境出现过一次全集群NotReady事故。当时是凌晨监控先弹出一台节点磁盘使用率99%接着集群节点陆续进入NotReady。排查链路是kubectl get nodes看到异常ssh进节点df -h显示根分区已满du逐层定位发现是Docker容器日志和etcd自动快照堆满了系统盘。临时处理是清掉过期的快照文件和日志再把自动快照的保留份数调小。根治方案是把数据盘重新规划让/var/lib/etcd和/var/lib/docker都落在独立大容量盘上系统盘只放操作系统。这个案例说明一个道理高可用架构的脆弱点往往不在组件数量而在那些没有容量基线的目录。8.3 案例三HAProxy健康检查把所有节点标红还有一次HAProxy的后端全部显示DOWNVIP却是通的页面访问超时。按这个现象逐层排查先看haproxy日志发现TCP连接超时再在LB上手动nc到节点443端口端口拒绝进节点检查发现是安全组规则变更把LB到节点的TCP 443拦截了。把规则恢复后的第二天又碰上健康检查的3秒间隔和防火墙conntrack会话超时时间不一致导致节点被间歇标记DOWN。调整tcp-check间隔后恢复正常。这个案例想说的是四层健康检查只能证明TCP端口通链路里任何一个防火墙、安全组、conntrack参数都可能成为隐藏故障源。排查时不要被端口不通这个表象牵着走要沿着链路把每一跳都验证一遍。8.4 我把这些教训沉淀成了一条自查顺序在这些故障之后我手头Rancher环境每次出问题都按固定顺序自查一看证书有效期二看VIP和LB后端状态三看磁盘容量四看etcd健康五看Kubernetes节点状态。这个顺序基本覆盖了Rancher生产环境80%以上的故障面。做完再下结论不要一上来就重装Rancher那种做法只会加重问题。个人体会Rancher高可用搭建本身并不难真正难的是把它当作一台精密仪器来看待。前期每多一点规划、每一次故障演练都在降低未来凌晨被电话叫醒的概率。如果你现在刚开始搭建不要急着把页面跑起来就庆祝先按上面的检查和备份基线过一遍再决定是否交付生产。
阅读完成 · 觉得有帮助？
