企业官网建设流程全解析

1. 为什么单节点 Rancher 迟早会变成运维的噩梦

很多团队第一次接触 Rancher，都是在一台测试机上用 Docker 一条命令跑起来的。docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher，回车下去，几分钟后浏览器打开 IP 就能看到登录页，体验确实顺滑。我见过不少团队就这么把这套东西直接搬进了生产环境，然后安稳跑了几个月，直到某天凌晨那台机器磁盘写满、或者宿主机内核升级后重启失败，整个集群的管理入口直接消失——所有下游业务集群的纳管、监控、告警、应用发布全部停摆。

这就是单节点 Rancher 最要命的地方：它本身是一个管理平面，管理平面挂了，不代表业务挂了，但你会瞬间失去对业务的观测和操作能力。业务还在跑，你却成了"瞎子"。更尴尬的是，Rancher 的数据全部存在内嵌的 etcd（或单机 SQLite）里，机器一旦物理损坏，恢复成本极高，很多时候只能重建再重新导入集群。

所以这篇要聊的，是把 Rancher 从"一台机器上的玩具"变成"一个真正高可用的管理平面"的完整落地过程。核心关键词就三个：Rancher 高可用、Kubernetes 集群、etcd 数据一致性、负载均衡、证书管理。适合已经用过单机 Rancher、准备把它推进生产环境的运维和平台工程师，也适合正在做平台选型、想搞清楚"高可用到底高在哪"的技术负责人。下面我会把架构选型的逻辑、部署的每一步、以及那些文档里不会写的坑，全部摊开讲。

2. 高可用架构的骨架：三个角色必须分清楚

在动手之前，得先把 Rancher 高可用的整体架构在脑子里立起来。很多人部署失败，不是命令敲错了，而是根本没想明白"哪些组件需要冗余、冗余在哪一层"。Rancher 的高可用方案本质上是三层结构，每一层的职责和故障域都不一样。

2.1 管理集群、Rancher 工作负载、下游业务集群的分层关系

第一层是管理集群（Management Cluster），也就是承载 Rancher 自身的那个 Kubernetes 集群。第二层是跑在这个集群里的Rancher 工作负载，通常以 Helm Chart 形式部署，包含 Rancher Server 的多个副本、相关 Controller 等。第三层是下游业务集群（Downstream Cluster），也就是被 Rancher 纳管、真正跑业务应用的那些集群。

这三层的故障影响是递进的：管理集群挂了，Rancher 就没了；Rancher 挂了，下游集群本身还在跑，但你失去了统一管理入口；下游集群挂了，只影响那一个集群的业务。所以高可用的重点，是把第一层和第二层做冗余，让"管理入口"这个单点消失。

一个常见的误解是"我把 Rancher 部署在业务集群里不就行了"。技术上可以，但强烈不建议。管理平面和业务平面混在一起，业务集群的一次大规模发布或资源打满，可能直接把 Rancher 拖垮，反过来你连排查的工具都没了。管理集群应该独立、精简、稳定，只跑管理组件。

2.2 为什么控制平面节点必须是奇数，etcd 的 quorum 到底怎么算

管理集群如果用 RKE、RKE2 或 K3s 来搭，控制平面节点（同时承担 etcd 角色）的数量必须是奇数。这不是玄学，是 etcd 的 Raft 共识算法决定的。Raft 要求集群中超过半数（quorum）的节点存活才能正常读写，quorum 的计算公式是floor(n/2) + 1。

看表格就明白了：2 个节点和 1 个节点的容错能力一样（都是 0），但成本翻倍，所以是纯亏本买卖。3 个节点能容忍 1 台挂掉，是性价比最高的最小高可用配置。5 个节点能容忍 2 台，适合规模较大、对可用性要求极高的场景，但 etcd 的写性能会随节点数增加而下降，因为每次写都要同步到更多节点。我的经验是：中小规模生产环境，3 个控制平面节点足够；除非有明确的合规或规模要求，不要盲目上 5 个。

2.3 负载均衡层：把流量稳稳地分给三个 Rancher 副本

Rancher Server 以多副本方式运行后，前面必须有一层负载均衡（LB），把用户的 HTTPS 请求分发到各个副本。这一层可以是硬件 LB、云厂商的 LB，也可以是自建的 Nginx/HAProxy。关键要求有三个：支持 HTTPS 透传或终止、支持健康检查、能把 TCP 443 流量稳定分发。

这里有个容易忽略的点：Rancher 的 UI 和 API 走 443，但 Rancher 的 agent（下游集群里跑的 cattle-cluster-agent）连接管理平面时也走 443。所以 LB 必须对 443 做四层（TCP）转发，而不是只做七层 HTTP 转发。如果你用七层模式，agent 的 WebSocket 长连接可能被中断，表现为下游集群频繁掉线、显示"Unavailable"。这一点后面排错章节还会细说。

3. 部署前的硬性准备：节点、证书、DNS 一个都不能马虎

架构想清楚了，接下来是准备阶段。这一步做扎实，后面能省掉一大半的返工。我见过太多人卡在证书和 DNS 上，折腾一整天。

3.1 节点规划与系统基线配置

假设我们用 3 台机器做管理集群的控制平面（同时是 etcd 和 worker），再加一台独立的负载均衡器。节点规格上，Rancher 官方给的最低要求是 4C/16G，但那是"能跑起来"的底线。实际生产里，Rancher 加上监控、日志等组件，内存消耗不小，我建议每台至少 8C/32G，系统盘 200G 以上 SSD。etcd 对磁盘 IO 极其敏感，机械盘或低性能云盘会导致 etcd 频繁慢查询，进而引发集群不稳定。

系统基线方面，几件事必须提前做：

• 主机名唯一且可解析：每台机器设置唯一 hostname，并在所有节点的/etc/hosts里互相写全。Kubernetes 对主机名重复非常敏感。
• 关闭 swap：swapoff -a并注释掉/etc/fstab里的 swap 行。kubelet 默认不允许 swap 开启。
• 时间同步：所有节点必须用同一个 NTP 源，时间偏差超过阈值会导致证书校验失败、etcd 选举异常。
• 内核参数：加载br_netfilter、overlay模块，设置net.bridge.bridge-nf-call-iptables=1、net.ipv4.ip_forward=1。
• 防火墙端口：控制平面之间要放通 2379/2380（etcd）、6443（API Server）、10250（kubelet）、8472 或 4789（网络插件）等端口。

提示：etcd 对时钟漂移的容忍度很低，NTP 一定要配，而且最好配两个源做冗余。我遇到过因为一台机器时间慢了 40 秒导致 etcd 反复重新选举的案例，排查了很久才定位到时间同步。

3.2 证书策略：自签、企业 CA 还是 Let's Encrypt

Rancher 高可用部署里，TLS 证书是最容易出问题的一环。三种选择各有适用场景：

• 自签证书：Rancher 默认会生成自签证书，但浏览器会报警告，且下游 agent 需要信任该证书。适合内网测试。
• 企业 CA 签发：生产环境最常见。用公司内部 CA 给 Rancher 的域名签一张证书，所有节点和客户端预装 CA 根证书，信任链完整。
• 公网可信 CA（如 Let's Encrypt）：如果 Rancher 域名公网可达，可以用 ACME 自动签发。但内网环境不适用。

无论哪种，证书的CN/SAN 必须包含你访问 Rancher 用的域名，比如rancher.internal.example.com。如果证书和访问域名不匹配，Rancher 启动后 agent 会报 x509 错误。另外，证书有效期要留意，Rancher 的证书轮换机制在旧版本里并不完善，建议把证书到期时间纳入监控，提前 30 天告警。

3.3 DNS 与负载均衡 VIP 的绑定方式

用户和下游 agent 访问 Rancher，用的应该是一个统一的域名，这个域名解析到负载均衡的 VIP。有两种常见做法：

1. DNS 直接解析到 LB 的 VIP：最简单，推荐。域名 A 记录指向 LB 的虚拟 IP。
2. DNS 轮询解析到三个节点 IP：不推荐。因为 Rancher 副本之间不共享会话状态，轮询会导致用户操作时频繁跳节点，体验差，且无法做健康检查摘除。

所以标准做法是：一个域名 → 一个 LB VIP → LB 后端挂三个 Rancher 副本的 443 端口。这个链路要提前打通并验证，别等 Rancher 装完了才发现 DNS 解析错了。

4. 用 RKE2 拉起管理集群：从零到 API Server 可用

管理集群的搭建工具，主流有 RKE、RKE2、K3s 三种。RKE 是 Rancher 早期的经典方案，基于 Docker 运行组件；RKE2 是新一代，组件以静态 Pod 形式运行，更贴近上游 Kubernetes，安全性和稳定性更好；K3s 轻量，适合边缘和资源受限场景。新部署我强烈建议用 RKE2，它是目前 Rancher 官方主推的管理集群方案，后续升级路径也更清晰。

4.1 第一个 server 节点的初始化

RKE2 的安装非常简洁。在第一个节点上执行官方安装脚本，然后写配置文件。配置文件/etc/rancher/rke2/config.yaml是关键，内容大致如下：

token: <一个足够复杂的预共享密钥> tls-san: - rancher.internal.example.com - <LB的VIP> node-ip: <本机内网IP> write-kubeconfig-mode: "0644" cni: canal

几个参数值得解释：token是集群加入凭证，所有节点必须一致，用openssl rand -base64 32生成一个强随机值，别用弱口令；tls-san里必须加上你最终访问 Rancher 的域名和 LB VIP，否则 API Server 的证书不包含这些地址，后续访问会报证书错误；node-ip显式指定内网 IP，避免多网卡机器选错地址。

配置写好后再启动服务：systemctl enable rke2-server --now。启动后 RKE2 会自动拉起 etcd、API Server、controller-manager、scheduler 等静态 Pod。用kubectl get nodes确认节点 Ready，用kubectl get pods -A确认核心组件都 Running。

4.2 第二、第三个节点如何安全加入

第一个节点起来后，从/var/lib/rancher/rke2/server/node-token读取完整的 token（注意这个文件里的 token 比 config.yaml 里写的多了前缀，要用文件里的完整值）。然后在第二、第三个节点上，配置文件里除了token和node-ip，还要加一行server: https://<第一个节点IP>:9345，指向已有的 server。

依次启动后，在第一个节点上kubectl get nodes应该能看到三个节点陆续 Ready。这时候 etcd 集群也自动组成了三节点。可以用kubectl -n kube-system exec -it <etcd-pod> -- etcdctl member list确认三个成员都在，且状态健康。

注意：三个节点加入的间隔不要太长，也不要在 etcd 还没稳定时就急着装 Rancher。等所有节点 Ready、核心 Pod 全部 Running 且重启次数为 0，再进行下一步。

4.3 验证 etcd 健康与集群自愈能力

集群搭好后，做一次"破坏性验证"很有必要：手动停掉一个控制平面节点的 rke2-server 服务，观察集群是否仍然可用（kubectl get nodes还能返回，Pod 调度正常），然后再启动回来，确认节点重新加入、etcd 成员恢复。这个演练能让你对"高可用到底能不能扛"心里有底。

etcd 健康检查可以用etcdctl endpoint health --cluster和etcdctl endpoint status --cluster，关注IS LEADER、RAFT TERM、DB SIZE等指标。如果发现某个成员频繁 leader 切换，多半是磁盘 IO 或网络延迟问题，要尽早处理。

5. Helm 部署 Rancher 与负载均衡的对接细节

管理集群就绪，接下来部署 Rancher 本身。官方推荐用 Helm，这样升级、回滚、改配置都方便。

5.1 添加 Helm 仓库与命名空间规划

先添加 Rancher 的 Helm 仓库：

helm repo add rancher-stable https://releases.rancher.com/server-charts/stable helm repo update

然后创建命名空间cattle-system（Rancher 的固定命名空间，不要改）。这里有个细节：Rancher 的 Helm Chart 对命名空间有强依赖，装错命名空间会导致后续组件找不到资源。所以老老实实用cattle-system。

5.2 关键 values 参数逐项拆解

部署命令的核心是 values 参数。以企业 CA 证书为例：

helm install rancher rancher-stable/rancher \ --namespace cattle-system \ --set hostname=rancher.internal.example.com \ --set replicas=3 \ --set ingress.tls.source=secret \ --set privateCA=true \ --set bootstrapPassword=<初始管理员密码>

逐项说：hostname必须和证书 SAN 一致；replicas=3是 Rancher Server 的副本数，配合三节点集群，理想情况下每个节点跑一个副本；ingress.tls.source=secret表示用你自己创建的 TLS Secret，需要提前把证书和私钥导入为cattle-system下的 Secret；privateCA=true告诉 Rancher 使用私有 CA，这样它生成的 agent 连接配置会带上正确的 CA 证书；bootstrapPassword是首次登录的初始密码，登录后会被要求修改。

如果证书是公网可信 CA 签发的，privateCA设为 false，ingress.tls.source可以用rancher（让 Rancher 自己申请）或secret。内网环境一律用secret+privateCA=true，这是最可控的组合。

5.3 Ingress、Service 与外部 LB 的流量路径打通

Rancher 部署后会创建一个 Ingress 和一个 Service。流量路径是：外部 LB → 节点 443（Ingress Controller）→ Rancher Service → Rancher Pod。这里要确认两件事：

第一，管理集群里要有 Ingress Controller。RKE2 默认不带，需要额外装一个（比如 ingress-nginx）。装好后，Ingress 会把rancher.internal.example.com的流量路由到 Rancher Service。

第二，外部 LB 的后端要指向所有节点的 443 端口（或 Ingress Controller 的 NodePort），并配置 TCP 健康检查。健康检查建议用 TCP 443 探测，而不是 HTTP，因为 Rancher 的某些路径对未认证请求返回非 200，用 HTTP 检查容易误判。

部署完成后，kubectl -n cattle-system get pods应该看到 3 个 rancher Pod 都 Running。用浏览器访问域名，能看到登录页，说明整条链路通了。

6. 那些文档不会告诉你的坑：从踩坑到定位的完整链路

前面讲的是"顺利路径"，但真实部署里，问题往往出在细节。这一章我把几个高频坑的排查过程完整还原，你可以照着这个思路复现定位。

6.1 下游集群一直 Unavailable：agent 连不上管理平面的排查顺序

现象：Rancher 起来了，导入下游集群后，集群状态一直显示Unavailable或Pending。这是最高频的问题。排查顺序应该是从下游往上游倒推：

1. 先看下游集群里的 cattle-cluster-agent Pod 日志：kubectl -n cattle-system logs -l app=cattle-cluster-agent。如果日志里是dial tcp <LB_IP>:443: i/o timeout，说明网络不通；如果是x509: certificate signed by unknown authority，说明 CA 证书没被信任；如果是context deadline exceeded，可能是 LB 七层转发导致 WebSocket 断了。
2. 确认 LB 是四层转发：前面提过，agent 走 443 的 TCP 长连接，LB 必须做 TCP 模式。如果 LB 是七层 HTTP 模式，agent 的 WebSocket 会被中断，表现为连接建立后很快断开、反复重连。
3. 确认证书 SAN 包含 agent 访问的地址：agent 是用hostname去连的，如果证书 SAN 里没有这个域名，就会 x509 报错。
4. 确认下游集群能解析该域名：内网 DNS 如果没配，agent 解析不到，自然连不上。可以在下游节点上nslookup rancher.internal.example.com验证。

这个顺序的逻辑是：agent 是"客户端"，问题要么在网络（连不上）、要么在证书（连上了但不信任）、要么在 LB 模式（连上了但被断）。按这个链路走，基本能定位到根因。

6.2 证书 SAN 不匹配导致的 x509 报错

这个坑我踩过不止一次。表现是 Rancher UI 能打开（因为浏览器可能手动信任了），但 agent 报 x509。根因是证书的 SAN 列表里缺了某个访问地址。比如你证书只签了rancher.internal.example.com，但 LB 的 VIP 也被用来访问，或者某些 agent 配置里用了 IP，就会不匹配。

解决办法是重新签发证书，把所有可能的访问入口（域名、LB VIP、必要时节点 IP）都加进 SAN。签发后更新 Secret，然后kubectl -n cattle-system rollout restart deploy/rancher让 Rancher 重新加载证书。注意，更新证书后，已经导入的下游集群可能需要重新生成 agent 配置（在 UI 里对集群点"Edit"再保存，或删除重建 agent），否则旧配置里还是旧 CA。

6.3 etcd 磁盘 IO 打满引发的连锁反应

etcd 对磁盘延迟极其敏感。如果管理集群的磁盘是低性能云盘，etcd 的 WAL 写入延迟升高，会触发 leader 选举超时，表现为 API Server 间歇性不可用、kubectl命令卡顿、Rancher UI 转圈。

排查方法：在 etcd Pod 里跑etcdctl endpoint status --cluster -w table，看DB SIZE和延迟；同时在节点上用iostat -x 1看磁盘await和util。如果await长期高于 10ms，基本可以确定是磁盘瓶颈。

解决方向：换 SSD 或更高性能的云盘；把 etcd 的数据目录单独挂一块盘；减少管理集群上的其他重 IO 负载（这也是为什么管理集群要独立、精简）。这个坑的教训是：etcd 的磁盘不能省，省下来的钱会在故障时加倍还回去。

7. 上线之后：备份、升级与日常巡检的实操清单

高可用部署完成不等于万事大吉，运维的功夫在平时。这一章给一份可以直接抄的清单。

7.1 etcd 快照与 Rancher 配置备份的双保险

etcd 快照是管理集群的"后悔药"。RKE2 支持自动快照，在 config.yaml 里配置：

etcd-snapshot-schedule-cron: "0 */6 * * *" etcd-snapshot-retention: 10 etcd-snapshot-dir: /var/lib/rancher/rke2/server/db/snapshots

每 6 小时一次，保留 10 份。快照要定期异地备份，别只留在本机，否则机器坏了快照也没了。恢复时用rke2 server --cluster-reset --cluster-reset-restore-path=<快照路径>。

除了 etcd，Rancher 自身的配置（比如通过 UI 创建的用户、角色、集群配置）也存在 etcd 里，所以 etcd 快照覆盖了大部分。但如果你用了外部数据库（Rancher 支持外部 MySQL/PostgreSQL），那要单独备份数据库。我的建议是：中小规模直接用 Rancher 内嵌的 etcd 存储，简单可靠；规模大了再考虑外部数据库。

7.2 Rancher 版本升级的正确姿势与回滚预案

升级 Rancher 用 Helm：先helm repo update，然后helm upgrade rancher rancher-stable/rancher --namespace cattle-system --version <目标版本> --reuse-values。--reuse-values很重要，它保留你之前的配置，避免升级时参数丢失。

升级前必做三件事：备份 etcd 快照、确认目标版本的升级路径（有些版本不能跨大版本直升，要逐级升）、在测试环境先演练一遍。升级过程中 Rancher Pod 会滚动重启，期间 UI 可能短暂不可用，但下游集群不受影响。如果升级后出问题，用helm rollback rancher <revision>回滚到上一个版本，配合 etcd 快照兜底。

7.3 日常巡检要看哪几个指标

日常巡检不用面面俱到，盯住几个关键指标就够：

这套巡检可以做成脚本定时跑，结果推到告警渠道。证书到期和磁盘使用率是最容易被忽略、又最容易引发故障的两项，务必纳入监控。

8. 一些关于"高可用"的实话

部署完这套东西，我想说几句可能不太中听但很实在的话。高可用不是装完三个节点就自动拥有的属性，它是一个需要持续验证和维护的状态。我见过太多团队把架构搭得很漂亮，然后一年不做一次故障演练，真出事时发现备份恢复流程没人会、LB 的健康检查配错了、证书过期了没人管——纸面上的高可用，在故障面前一文不值。

所以我的建议是：每季度至少做一次故障演练，随机停一个控制平面节点、模拟一次 LB 后端摘除、走一遍 etcd 快照恢复流程。演练不是为了证明系统没问题，而是为了在真正出事前，把人的操作熟练度和预案的漏洞都暴露出来。另外，管理集群的变更要克制，别把它当成实验田，任何升级和配置调整都先在测试环境验证。Rancher 高可用的价值，最终体现在"你几乎感觉不到它的存在"——它稳稳地在后台管着所有集群，而你从不需要为它半夜爬起来。这才是这套架构真正该达到的状态。