先说一个我踩过的坑。之前在测试环境装 Rancher图省事用了单节点 Docker 方式直接跑当时觉得管理面挂了重启就行。结果有一次磁盘写满管理面直接失联底层 Kubernetes 集群的业务虽然还在跑但你想扩副本、改配置、看日志全部瘫痪最后只能登录各节点手工 kubectl 救急。那次之后我就想明白了生产环境只要上 Rancher就必须按 HA 来规划多花的资源就是买管理面的可用性。这篇是近期在生产环境搭建 Rancher 2.x HA 高可用集群的完整手顺。“手顺”这个词是我在同行文档里看来的意思是规范化的操作流程。整个方案基于三节点 K3s 作为 Rancher Server 的宿主集群前端再走一层负载均衡最终实现管理面故障自动切换。如果你正在做容器平台选型或者准备把 Rancher 从单节点迁到多节点这篇可以直接照着抄作业。看之前先确认一个前提你已经对 Kubernetes 的基本概念有印象知道 namespace、Deployment、ingress 大概是什么。完全零基础的话建议先花两周把 kubectl 用熟再回来做 HA别在还不熟悉环境的情况下直接上生产集群。1. 生产环境为什么不建议单节点 Rancher架构与决策逻辑1.1 单点管理面的隐形代价很多人觉得 Rancher 只是一个 Web 管理台后端连的是 K8s API管理面挂了对业务影响不大。这句话只对了一半。Rancher 2.x 里有大量自定义资源CRD和控制器逻辑比如集群导入、项目/命名空间管理、RBAC 同步、监控和日志组件调度都依赖 Rancher Server 持续工作。一旦 Rancher 不可用底层的业务容器确实不受影响但整个平台进入“只能看不能动”的状态新建命名空间、调整工作负载副本数、查看多集群状态、设置告警规则全部不可用。最难受的是升级场景。很多公司在节假日窗口升级集群结果 Rancher 挂了操作人员只能回到最原始的 kubectl 一条条执行效率极低还容易误操作。单点故障的恢复时间通常不只取决于重启那一下而是取决于“人找登录方式”的时间这在运维事故中往往是最致命的。生产环境上 RancherHA 不是可选项是默认项。1.2 Rancher 2.x HA 的三条实现路线Rancher 2.x 从 2.5 开始官方就明确推荐“在 Kubernetes 集群上部署 Rancher Server”而不是用 Docker 单容器。常见路线有三条我直接做成对比表路线实现方式优点缺点适用场景Docker 外部数据库Rancher Server 容器跑在单机数据放外部 MySQL/etcd思路简单适合临时环境容器本身仍是单点数据库还得另做 HA维护成本高不推荐生产三节点 K3s 集群K3s server 内嵌 etcdRancher 以 Deployment 部署其上轻量、安装快、升级链路短官方支持大规模集群下 K3s 不具备完整 RKE2 的某些加固特性中小规模生产环境团队人手有限三节点 RKE2 集群RKE2 server 作为宿主集群Rancher 部署其中更接近原生 K8s安全基线更完整适合大规模部署复杂度高etcd 和证书管理更繁琐大规模、严格要求合规的生产环境三条路线的核心差别不在 Rancher 本身而在“宿主的这套 K8s 集群谁来维护”。如果你的团队已经有成熟的 RKE2/K8s 运维能力选 RKE2 没问题。如果团队规模不大我建议直接 K3s它把 etcd、kubelet、containerd 都打包了升级一个二进制文件就能搞定。1.3 我为什么选“三节点 K3s 前置负载均衡”这次部署我选的路线是三台 4C/16G 的虚机组成 K3s server 集群体Rancher 通过 Helm 以三个副本的 Deployment 方式跑在这三台机器上前置用一组四层负载均衡器把 443 流量分发到三台节点。选 K3s 还有一个原因默认集成 Traefik 作为 ingress controllerRancher 创建 ingress 后直接就能被 Traefik 接住不需要我再单独装一套 nginx-ingress。K3s 的安装脚本基于 systemd 管理节点重启后服务自动拉起这对生产环境很重要。etcd、flannel、Traefik 全部被 service 托管单节点故障后的恢复路径非常清晰。相比直接用 RKE2省掉了不少初始化的体力活后续排查问题时系统组件也更容易定位。2. 部署前的核心准备节点、端口、域名、证书和负载均衡2.1 节点规划与资源配置先给一张我这次使用的节点规划表你可以直接套用角色数量CPU内存系统盘数据盘说明K3s Server 114C16G60G100G SSD同时部署 Rancher PodK3s Server 214C16G60G100G SSD同时部署 Rancher PodK3s Server 314C16G60G100G SSD同时部署 Rancher Pod内存这里多说一句。K3s 本身吃资源不高三个 server 各 4G 就能跑但 Rancher 部署后会有一堆控制器和 WebHook再加上将来你还要通过 Rancher 纳管其他集群它会持续的跟被纳管集群做信息同步。所以我建议控制面节点至少 16G别省。磁盘方面etcd 的数据就落在数据盘上IOPS 直接决定 etcd 的性能上限。生产环境千万别用普通机械盘甚至低 IOPS 的廉价云盘也要慎重etcd 对 fsync 时延极其敏感磁盘慢了整个集群会频繁出现 leader 切换。所有节点统一 Ubuntu 22.04 LTS开启 NTP 时钟同步。K8s 对节点间时钟偏差很敏感etcd 依赖稳定的网络时间建议直接用 systemd-timesyncd 或 chrony 配好不然排查故障时经常会出现各种诡异的证书过期和 Raft 选举问题。2.2 端口与安全组放行K3s 集群内部组件之间要通信生产环境又往往有防火墙或安全组端口规划必须提前列清楚。我整理了一份实际用到的端口清单端口协议方向用途建议放行范围6443TCP集群内K3s API Server其他节点加入集群时需访问三节点之间以及运维堡垒机8472UDP集群内flannel VXLAN 数据面端口三节点之间10250TCP集群内kubelet 端口API Server 需要访问它三节点之间2379/2380TCP集群内K3s 内嵌 etcd 客户端与节点通信端口三节点之间k3s 默认绑定在节点 IP80/443TCP外部入口Rancher Web UI 与 API 入口负载均衡器、办公网出口30000-32767TCP可选NodePort 服务暴露端口按需放行按业务需求配置安全组时最容易漏掉的是 8472 UDP 和 2380 端口。有一次我在客户的云环境部署服务起来后节点之间总报 flannel 路由异常查到最后就是安全组漏了 UDP 8472花了一个多小时。建议你在搭建前就把端口一次性放行别等启动报错了再一道一道加。2.3 域名与证书方案生产环境访问 Rancher 一定要用域名不要用 IP。原因是 Rancher Server 的地址会被写进它生成的 kubeconfig 里你后续通过 Rancher 纳管其他集群时这些集群的 agent 会反向访问 Rancher Server 地址。如果用了 IP后期域名变更或 IP 调整会非常痛苦。建议统一规划为rancher.example.com这种内部专用域名。证书方面生产环境最省心的做法是直接用公司内部的 CA 系统签一张 SAN 证书或者用采购的公网证书然后把证书文件和私钥提前准备好。我不太推荐在 K3s 环境里让 Rancher 自动通过 cert-manager 签发证书因为 cert-manager 的版本和 Rancher 有兼容性绑定升级 Rancher 时经常要连带升 cert-manager容易一起出问题。证书走已有 CARancher 这边只是引用一个 Kubernetes Secret升级时不会产生额外依赖。另外要注意证书的 SAN 里最好同时包含域名和当前节点的 IP。虽然生产环境以域名访问为主但某些场景下比如走 NodePort 调试Rancher agent 可能会用 IP 连接 Server证书不匹配会直接导致连接失败。2.4 前置负载均衡器的两种做法Rancher Server 前面必须有一层负载均衡。生产环境常见做法有两种我简单说明第一种是直接用云厂商的负载均衡器。现在各家云产品都支持四层 TCP 监听把 443 端口作为前端后端挂三台 K3s 节点的 443 端口健康检查方式选 TCP 或 HTTP 均可。如果选 HTTP 健康检查检查路径可以用https://rancher.example.com/healthz返回 200 即健康。第二种是自建 Nginx stream 模块做四层转发。我们这次环境里负载均衡器是内网部署的直接在 Nginx 上做了四层 TCP 转发配置大致如下stream { upstream rancher_servers { least_conn; server 192.168.10.11:443 max_fails3 fail_timeout5s; server 192.168.10.12:443 max_fails3 fail_timeout5s; server 192.168.10.13:443 max_fails3 fail_timeout5s; } server { listen 443; proxy_pass rancher_servers; proxy_timeout 10s; proxy_connect_timeout 5s; } }这里有一个关键点Rancher UI 大量使用 WebSocket 做日志和终端连接四层 TCP 转发不存在 WebSocket 兼容问题所以我强烈建议用四层而不是七层。如果一定要用七层反向代理必须配置好 WebSocket 的 Upgrade 头否则 Rancher 的 Pod 日志和命令行终端会时不时掉线排查起来让人抓狂。3. 三节点 K3s 集群搭建实操从零到 etcd 健康3.1 初始化第一个 K3s Server 节点先在准备好的三台机器上完成基础设置包括主机名、NTP、hosts 解析。然后登录第一台机器执行curl -sfL https://get.k3s.io | K3S_TOKENprod-rancher-ha sh -s - server \ --cluster-init \ --write-kubeconfig-mode644 \ --data-dir /data/k3s核心参数我逐一说明。--cluster-init表示以“内嵌 etcd”模式启动这是 K3s 组成 HA 集群的关键不加这个参数后面两个节点根本没法以 server 模式加入。--data-dir /data/k3s把数据目录放到独立数据盘避免系统盘被 etcd 日志和快照撑爆。--write-kubeconfig-mode644只是方便后续直接用 kubeconfig 文件操作生产环境如果对安全要求高可以不加但那样后续 kubectl 操作要切 root 用户。安装完成后第一件事是看 etcd 是否常见下列健康状态export KUBECONFIG/etc/rancher/k3s/k3s.yaml kubectl get nodes kubectl -n kube-system get pods -l componentetcd启动过程通常需要 30 到 60 秒第一次初始化 docker/containerd 镜像耗时会长一些。如果kubectl get nodes显示 NotReady看看 journalctl 输出最频繁的原因是镜像拉取慢或者安全组端口不通。确认第一个节点 Ready 后记录下cat /var/lib/rancher/k3s/server/node-token里的 token——这里注意server 节点加入集群用的 token 也是这个文件。K3s 的默认 token 属于 bootstrapping 用后续如果有必要可以轮换但生产环境通常保持稳定不建议频繁重装。3.2 将第二、第三节点加入集群登录第二台节点执行curl -sfL https://get.k3s.io | K3S_TOKENprod-rancher-ha sh -s - server \ --server https://192.168.10.11:6443 \ --data-dir /data/k3s注意这里没有--cluster-init因为集群已经初始化过了。--server指向第一个节点的 API ServerK3s 会从这个地址读取集群初始化信息。第三个节点同理。等命令跑完后回到第一台节点执行kubectl get nodes正常情况下三台节点都会是 Ready角色列全显示Control Plane。接着检查 etcd 成员kubectl -n kube-system get pods -l componentetcd -o wide三台节点上各有一个 etcd Pod状态是 Running。如果某个 etcd Pod 反复重启多半是 2380 端口没放行或者数据盘 IO 太慢导致 etcd 心跳超时。这里补充一个经验三个节点加入的时间间隔不要拉得太长。如果第一个节点 init 后隔了几天再加入第二台etcd 的 snapshot 文件可能已经膨胀新节点同步历史数据的时间会明显变长。生产环境尽量在半天窗口内把三个节点全部加完。3.3 验证集群高可用一次主动故障演练集群搭完后别急着装 Rancher先用十分钟做一次故障演练。方法很简单把第三台节点上的 k3s 服务停掉systemctl stop k3s然后回到第一台节点观察整个集群状态kubectl get nodes kubectl -n kube-system get pods你会发现第三台节点变成 NotReady但其他两台节点依然 Readyetcd 依然有健康成员业务调度不受影响。接着重启第三台节点的 k3s 服务systemctl start k3s等一两分钟节点恢复到 Readyetcd Pod 重新加入 Raft 成员列表。这个演练验证了底层宿主集群的容错能力至少在节点故障这一层K3s 是合格的。Rancher 本身的 HA 验证要在装完 Rancher 之后再测。4. 使用 Helm 安装 Rancher Server生产参数配置详解4.1 准备 Helm 仓库与命名空间K3s 自带 kubectl但 Helm 需要单独准备。建议在运维机器上安装 Helm 3然后添加 Rancher 官方仓库helm repo add rancher-latest https://charts.rancher.io/ helm repo update接着在 K3s 集群里创建 Rancher 专用命名空间kubectl create namespace cattle-systemRancher 的所有组件、服务和 ingress 都会放进这个命名空间。单独建 namespace 的好处是后续做 RBAC 授权、资源限额、备份时操作范围可以收敛得很干净。4.2 准备 TLS 证书 Secret按照前面的规划我们不用 cert-manager直接创建 Kubernetes TLS Secret。先在运维机器上准备好证书文件fullchain.pem和私钥文件privkey.pem然后执行kubectl -n cattle-system create secret tls tls-rancher-ingress \ --certfullchain.pem \ --keyprivkey.pemSecret 名字tls-rancher-ingress是 Rancher chart 默认读取的 secret 名如果没有特殊需求建议保持这个名字避免额外配置。创建后可以用下面命令确认kubectl -n cattle-system get secret tls-rancher-ingress此时如果你的证书是自建的内部 CA 签发记得让所有访问 Rancher 的客户端机器信任该 CA否则浏览器和 kubectl 都会报证书错误。4.3 编写 values.yaml 并执行安装Rancher 的 Helm chart 参数在不同版本间有少量差异生产环境一律建议先helm show values rancher-latest/rancher看一眼。我这次部署使用的 values 文件已经跑通2.7.x 和 2.8.x 通用内容如下hostname: rancher.example.com replicas: 3 bootstrapPassword: your-strong-password-here ingress: tls: source: secret extraTls: - hosts: - rancher.example.com secretName: tls-rancher-ingress关于这些字段我要做一些说明。replicas: 3必须和宿主集群的节点数匹配Rancher 官方 chart 默认就是 3但我见过有人手滑改成 1结果 pod 被反亲和规则卡住一直 Pending。bootstrapPassword是首次初始化时设置 admin 密码用的Rancher 会在第一次访问时引导你修改密码。这个字段在 UI 初始化完成后就不再生效所以即使不小心泄露影响也有限。然后执行安装helm install rancher rancher-latest/rancher \ -n cattle-system \ -f values.yaml安装过程大概持续三到五分钟期间 chart 会创建大量 CRD 和控制器。安装结束后用下面命令等待 Rancher workload 全部就绪kubectl -n cattle-system rollout status deploy/rancher当输出显示deployment rancher successfully rolled out时Rancher 的 Pod 已经全部启动。接着确认 Pod 在三台节点上的分布情况kubectl -n cattle-system get pods -o wide正常情况下三个 rancher Pod 会尽量分散在三个节点上。如果因为节点资源问题出现两个 Pod 挤在同一台节点可以适当调整资源分配但生产环境更推荐保持一节点一副本。4.4 验证管理面高可用再演练一次访问https://rancher.example.com用 bootstrap 密码进入 UI完成初始设置后还需要验证 Rancher 这一层的高可用。验证方法很粗暴但有效直接停掉一个节点的 k3s 服务然后刷新 Rancher UI。systemctl stop k3s # 在其中一个节点上执行正常情况下Rancher 的某个副本会跟着这节点的 k3s 一起下线但另外两个副本仍然在线负载均衡器会自动把请求转发到健康节点UI 无感知。这个验证做完管理面高可用才算真正落地。之后别忘把 k3s 服务重新启动。5. 生产环境常见故障排查与恢复演练实录5.1 故障速查表现象、原因、处理我把自己在部署和维护过程中遇到的典型故障整理成一张表每一条都是真实处理过的可以直接对照排查现象常见原因处理动作Rancher Pod 反复 CrashLoopBackOffTLS Secret 不存在、hostname 不匹配或 bootstrapPassword 不符合要求查看kubectl -n cattle-system logs deploy/rancher确认 Secret 与 values 中 hostname 一致后helm upgrade访问 UI 502 Bad GatewayTraefik ingress 未就绪或 Rancher Pod 尚未 Ready检查kubectl -n kube-system get pods中 Traefik 相关 Pod再查 cattle-system 的 ingress 状态浏览器证书错误客户端不信任内部 CA或证书 SAN 缺少域名安装 CA 根证书到客户端信任库检查证书 SAN 是否包含rancher.example.comkubectl 无法连接集群安全组未放行 6443或 kubeconfig 中 Server 地址错误确认安全组策略核对/etc/rancher/k3s/k3s.yaml中的 server 地址etcd Pod 频繁重启2380/2379 端口不通、磁盘 IO 慢、节点时钟偏移用journalctl -u k3s查日志逐项排查端口、IO、NTP新节点加入集群失败token 错误、etcd 尚未 ready、数据目录残留确认 token清理/data/k3s后重新加入观察 journalctl 输出这里补充一个经验排查 Rancher 问题尽量先看日志不要直接重启 Pod。Rancher 的日志里会明确写清是什么依赖出了问题比如 WebHook 配置异常、CRD 冲突、证书过期等。直接重启只会掩盖症状过几个小时又会复发。5.2 etcd 快照备份与恢复流程生产环境没有备份等于裸奔。K3s 提供了内嵌 etcd 快照能力操作非常直接k3s etcd-snapshot save \ --etcd-snapshot-dir /data/k3s/server/db/snapshots \ --name pre-upgrade-$(date %Y%m%d)快照文件默认会保存在/data/k3s/server/db/snapshots下格式是.zip恢复时需要用到。K3s 默认会在每 12 小时和每天凌晨各自动执行一次本地快照并保留一定数量。对于生产环境我会再加一个异地备份任务把.zip文件用 rsync 或者云对象存储定时传输到异地目录避免整个机房一起挂掉的情况。真正的恢复操作我建议先在测试环境完整演练一遍因为步骤里有坑。大致流程是将三台 K3s 节点全部停止服务在其中一台节点上执行k3s server \ --cluster-reset \ --cluster-reset-restore-path/data/k3s/server/db/snapshots/pre-upgrade-YYYYMMDD.zip这条命令会把该节点恢复为 etcd 的单一成员。之后另外两个节点需要清理旧数据目录再以普通 server 模式加入。恢复过程中最容易出现的问题是对cluster-reset命令不够熟悉导致误清数据所以再次强调恢复流程务必先在测试环境跑通再谈生产救援。5.3 Rancher 版本升级的正确姿势Rancher 的生产升级我建议遵循“小版本随更新大版本看说明”的原则。升级前至少完成三步第一步确认当前 Rancher 版本和目标是版本之间没有跳级要求。某些跨大版本升级比如从 2.6 直接跳到 2.8官方文档会明确要求必须先升到中间版本跳过中间版本往往会出现 CRD 兼容问题。第二步用前面说的命令打一个 etcd 快照并确认快照文件已生成且非零字节。第三步执行升级helm upgrade rancher rancher-latest/rancher \ -n cattle-system \ -f values.yaml \ --version 目标版本升级过程中 Rancher 的 Pod 会滚动重启启动时间一般比新装更快。升级完成后打开 UI 检查一遍功能重点看“集群管理”里纳管的集群是否状态正常。如果升级后某个集群显示状态异常先看 Rancher 日志通常是版本兼容性问题而不是数据丢失。5.4 生产环境避坑清单最后整理一份我自己遵守的避坑清单内容不多但每一条都是实践换来的不要直接在 Rancher Pod 里改配置或安装工具。任何对 Rancher 运行环境的定制都会在 Pod 重建时丢失正确做法是通过 Helm values 或者 Sidecar 方式实现。不要把业务工作负载调度到 K3s 控制面节点。控制面节点的资源被业务挤占严重影响 etcd 稳定性。如果确实需要复用节点资源要设置好资源 requests/limits并监控资源水位。不要把 LB 健康检查的超时时间设得太短。Rancher 后端 Pod 在做版本升级或滚动重启时健康检查可能短暂失败超时太短会触发 LB 频繁摘除后端反而造成抖动。一般设置 3 到 5 秒比较合理。不要频繁重启整个 K3s 集群。K3s 依赖 etcd 的 Member 列表不正常的重启顺序可能导致 Raft 集群进入脑裂状态。6. 生产环境运维备忘备份、监控、权限6.1 备份策略的完整链条etcd 快照是底线但我不建议只依赖它。更完整的备份链条应该是三层底层 etcd 快照保障节点故障恢复中层部署官方 rancher-backup 组件定期把 cattle-system 的资源配置打包上传到对象存储上层将 Rancher 的 ingress、证书 Secret、DNS 解析记录单独保存一份文档。三层备份互相兜底任何一层出问题都有挽回余地。备份频率建议etcd 快照每天至少一次异地拷贝每天一次Rancher 配置备份每天一次重大变更前手动备份一次。恢复目标可以按这个基准线设计尽量做到 RPO 不超过 24 小时。6.2 监控指标与告警建议Rancher 和 K3s 自带的指标已经比较丰富但要想在生产环境做到“提前发现问题”至少要监控以下几项etcd 层面的 fsync 耗时、leader 变化次数、内存占用和磁盘 IO 等待时间。etcd 磁盘使用率超过 80% 就要警惕快照文件会持续占用空间。K3s 节点层面的 CPU、内存、磁盘使用率以及journalctl -u k3s日志中是否频繁出现 timeout 或 election 关键词。Rancher 层面的 Pod 重启次数、容器日志错误数量、证书剩余有效期。证书过期是最容易被人忽略的生产事故提前 90 天设置告警一点都不过分。建议直接用 Prometheus 加 Alertmanager 做统一监控node_exporter 采机器指标kube-state-metrics 观察工作负载coredns 和 traefik 的指标也可以一并接入形成一套完整告警链。6.3 权限与安全加固生产环境切忌所有人共用 admin 账号。Rancher 支持内建 RBAC建议按团队划分用户、只读权限和运维权限谁做什么操作全都有审计日志。K3s 节点的 SSH 访问也建议收紧到堡垒机 IP不要直接暴露公网。另外K3s 和 Rancher 的版本更新要跟上。这里不是说天天追新而是每个季度至少确认一次当前版本是否处于官方支持窗口。长期停在老版本的风险不只是新功能缺失更关键是已有 CVE 没有修复安全审计时容易被单独点名。最后再分享一个我自己坚持的习惯生产环境任何变更前先在测试环境完整走一遍相同步骤。Rancher HA 这套方案我已经在不同环境部署过多次仍然坚持这四条先备份、再升级、后验证、留回滚。容器平台是运维工具链里的中枢平稳运行比新颖功能重要得多。希望这篇手顺能帮你少踩几个坑。