企业官网建设流程全解析

先说一个我踩过的坑。之前在测试环境装 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 一条条执行，效率极低，还容易误操作。单点故障的恢复时间通常不只取决于重启那一下，而是取决于“人找登录方式”的时间，这在运维事故中往往是最致命的。生产环境上 Rancher，HA 不是可选项，是默认项。

1.2 Rancher 2.x HA 的三条实现路线

Rancher 2.x 从 2.5 开始，官方就明确推荐“在 Kubernetes 集群上部署 Rancher Server”而不是用 Docker 单容器。常见路线有三条，我直接做成对比表：

三条路线的核心差别不在 Rancher 本身，而在“宿主的这套 K8s 集群谁来维护”。如果你的团队已经有成熟的 RKE2/K8s 运维能力，选 RKE2 没问题。如果团队规模不大，我建议直接 K3s，它把 etcd、kubelet、containerd 都打包了，升级一个二进制文件就能搞定。

1.3 我为什么选“三节点 K3s + 前置负载均衡”

这次部署我选的路线是：三台 4C/16G 的虚机组成 K3s server 集群体，Rancher 通过 Helm 以三个副本的 Deployment 方式跑在这三台机器上，前置用一组四层负载均衡器把 443 流量分发到三台节点。

选 K3s 还有一个原因：默认集成 Traefik 作为 ingress controller，Rancher 创建 ingress 后直接就能被 Traefik 接住，不需要我再单独装一套 nginx-ingress。K3s 的安装脚本基于 systemd 管理，节点重启后服务自动拉起，这对生产环境很重要。etcd、flannel、Traefik 全部被 service 托管，单节点故障后的恢复路径非常清晰。相比直接用 RKE2，省掉了不少初始化的体力活，后续排查问题时系统组件也更容易定位。

2. 部署前的核心准备：节点、端口、域名、证书和负载均衡

2.1 节点规划与资源配置

先给一张我这次使用的节点规划表，你可以直接套用：

内存这里多说一句。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 集群内部组件之间要通信，生产环境又往往有防火墙或安全组，端口规划必须提前列清楚。我整理了一份实际用到的端口清单：

配置安全组时最容易漏掉的是 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，容易一起出问题。证书走已有 CA，Rancher 这边只是引用一个 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_fails=3 fail_timeout=5s; server 192.168.10.12:443 max_fails=3 fail_timeout=5s; server 192.168.10.13:443 max_fails=3 fail_timeout=5s; } 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_TOKEN=prod-rancher-ha sh -s - server \ --cluster-init \ --write-kubeconfig-mode=644 \ --data-dir /data/k3s

核心参数我逐一说明。--cluster-init表示以“内嵌 etcd”模式启动，这是 K3s 组成 HA 集群的关键，不加这个参数，后面两个节点根本没法以 server 模式加入。--data-dir /data/k3s把数据目录放到独立数据盘，避免系统盘被 etcd 日志和快照撑爆。--write-kubeconfig-mode=644只是方便后续直接用 kubeconfig 文件操作，生产环境如果对安全要求高，可以不加，但那样后续 kubectl 操作要切 root 用户。

安装完成后，第一件事是看 etcd 是否常见下列健康状态：

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl get nodes kubectl -n kube-system get pods -l component=etcd

启动过程通常需要 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_TOKEN=prod-rancher-ha sh -s - server \ --server https://192.168.10.11:6443 \ --data-dir /data/k3s

注意，这里没有--cluster-init，因为集群已经初始化过了。--server指向第一个节点的 API Server，K3s 会从这个地址读取集群初始化信息。第三个节点同理。等命令跑完后，回到第一台节点，执行：

kubectl get nodes

正常情况下三台节点都会是 Ready，角色列全显示Control Plane。接着检查 etcd 成员：

kubectl -n kube-system get pods -l component=etcd -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，但其他两台节点依然 Ready，etcd 依然有健康成员，业务调度不受影响。接着重启第三台节点的 k3s 服务：

systemctl start k3s

等一两分钟，节点恢复到 Ready，etcd 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-system

Rancher 的所有组件、服务和 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 \ --cert=fullchain.pem \ --key=privkey.pem

Secret 名字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。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 这套方案我已经在不同环境部署过多次，仍然坚持这四条：先备份、再升级、后验证、留回滚。容器平台是运维工具链里的中枢，平稳运行比新颖功能重要得多。希望这篇手顺能帮你少踩几个坑。