先把一个最常见的误会摁住：Rancher 不是 Kubernetes，也不是集群本身，它是一层跑在 Kubernetes 之上的管理平台。你在 Rancher 界面上做的每一件事——建集群、加节点、派权限、看容器日志、装应用目录里的组件——本质上都是它替你去调下游集群的 API Server。把这句话刻在脑子里，后面关于纳管方式、agent 链路、权限模型的争论就都能串起来。
这两年接触到的团队里，Rancher 用得拧巴的，八成不是 Rancher 自己的问题，而是开局把两件事搞反了。第一种：把 import 当成 provision 用，把集群导进来之后就指望 Rancher 能替他扩节点、升版本、修证书，结果发现按钮是灰的，于是开始骂工具难用。第二种：把跑 Rancher 自己的那个集群（local cluster）当成业务资源池，往里面塞应用、塞 CI 构建器，最后 Rancher 一抖，业务陪着一起抖。
还有一句实话得说在前面：Rancher 是个强依赖。它挂了不是"管理面暂时看不见"这么轻描淡写——你们的单点登录、权限下发、合规巡检、GitOps 流水线很可能全挂在它上面。所以 Rancher Server 这台机器怎么选，比你一开始以为的重要得多。
本篇要讲清的三条主线：
Rancher Server 本身是一个 Deployment（高可用部署下是三个副本），它跑在一个 Kubernetes 集群里，这个集群就叫 local cluster。local cluster 通常是 Rancher 安装时自带的 K3s，或者是你自己准备的 RKE2 / K3s。下游集群（downstream cluster）是被你纳管进来的业务集群，可以是公有云上的 EKS / GKE / AKS，可以是别人交付给你的标准集群，也可以是 Rancher 自己 provision 出来的那一批。
把两边缝起来的就是 agent：cattle-cluster-agent 跑在下游集群的 cattle-system 命名空间里，通常是两副本的 Deployment；cattle-node-agent 是 DaemonSet，每个节点上一个。后文会逐个拆开讲这两个东西各自干什么、谁挂了会怎样。
import 这条路非常轻。你在 Rancher 界面上选"导入已有集群"，它会给你一条注册命令或者一段要 apply 的 YAML。这段 YAML 里包含的东西大致是：cattle-system 命名空间、一个 ServiceAccount 及其 token、一组权限很高的 ClusterRole 绑定、以及 cattle-cluster-agent 的 Deployment。apply 完之后，agent 起来，连回 Rancher，这个集群就出现在列表里了。
关键点在于：导完之后，你的 apiserver、etcd、controller-manager、scheduler 全都还在原处，一行没动。Rancher 只是拿了一个权限很高的 ServiceAccount token 去调你的 API。反过来说，这份 token 泄露等价于整个集群交出去——注册用的那份 YAML 和它生成的凭证要按密钥级别管理，别随手贴在工单里。
provision 这条路则重得多。Rancher 通过节点驱动或者 RKE2 / K3s 的机器供给机制，SSH 到目标机器上装发行版、配角色（etcd / controlplane / worker）、签发和轮换证书、管理 etcd 成员。好处也很直接：加节点、减节点、升 Kubernetes 版本、做 etcd 快照恢复，都能在界面上点。代价是 Rancher 成了这条集群生命周期的唯一入口，你想脱离它单干，集群还在，但证书轮换和节点编排这摊事你得自己接回去。
判断标准其实很简单。团队的心态如果是"这是我们自己的集群，只是想有个统一视图和统一登录"，走 import；如果是"我们没那么多人手，希望平台把集群这条命也管起来"，走 provision。混合也很常见：公有云上的托管集群 import 进来，自建机房里的走 provision。
有一个必须提前拦住的坑：不少人对同一个集群的心态会从 import 慢慢滑向 provision，看到界面上的"升级 Kubernetes 版本"就手痒想去点。别这么干。对一个 import 进来的集群点它没接管过的东西，结果是未定义行为，取决于你的发行版底层是怎么装的。要么一开始就选定一条路，要么就把集群注释清楚后重新 provision 一遍。
先看 local cluster 上到底跑着什么：Rancher Server 自己、rancher-webhook、provisioning 相关的控制器、Fleet 控制器、备份 operator，如果开了监控还有 monitoring 全家桶。更要命的是，它同时是所有下游集群元信息的存放地——每一条 downstream 的 cluster 对象、node 对象、角色绑定、以及连接用的凭证，全都写在 local cluster 的 etcd 里。也就是说，local cluster 的 etcd 一旦崩掉又没有可用快照，你丢的不是 Rancher 的登录账号，是整个管理平面的全部状态。
为什么不能往里塞业务，理由至少有四条，每一条都足够单独成立：
第一条是 IO 争抢。etcd 对 fsync 延迟极其敏感，官方给的建议是让第 99 百分位的 fsync 保持在个位数毫秒量级。业务的写盘一抖、日志一刷，etcd 心跳超时，local cluster 就开始重新选主，Rancher 在这一小段时间内不可写。你会看到的现象是界面忽好忽坏，但查什么都查不出原因。
第二条是安全边界。local cluster 里躺着所有下游集群的连接凭证、云厂商密钥、节点 SSH 私钥。业务容器跑在同一个集群里，横向移动的风险面被成倍放大，一次应用层漏洞就够你喝一壶。
第三条是故障域耦合。某个业务 Pod 把节点内存吃干，节点上的 Rancher Server 副本一起被 OOM 带走。
第四条是升级窗口被绑死。业务想升 Kubernetes 版本，等于要把 Rancher 一起升；Rancher 想升，又要等业务侧确认。两边的节奏从此锁死。
我自己一般不这么干：local cluster 的节点一律打污点，只允许 cattle-system、fleet-system 这类管理用命名空间调度上去。至于省下来的那台机器的钱，一次事故就赔回去了。
cattle-cluster-agent 干三件事。第一，建立并保活一条到 Rancher Server 的 websocket 长连接。第二，充当 Rancher 访问下游 API Server 的代理通道——Rancher 发过来的请求沿着这条隧道下来，由 agent 用本地的 ServiceAccount token 去调下游 apiserver，再把响应按原路送回去。第三，上报下游集群的状态与资源信息。
第二点里藏着一个很多人不理解的现象：Rancher 界面上看到的部分列表，其实是从 local cluster 的缓存里读出来的，不是每次都实时打下游。这就是为什么 agent 断连之后界面上还能看到一堆旧数据，看起来"还在动"。
cattle-node-agent 则是完全不同的角色。它是节点侧的马仔，负责节点升级时的排水与恢复（drain / cordon / uncordon）、跑操作系统层面的命令、在 Windows 节点场景下做清理。它不参与日常的 API 转发。规模大起来的时候，DaemonSet 的资源也要算进去，每台留几百 MB 内存不为过。
两者的故障表现差异很大：cluster-agent 挂了或连不上了，Rancher 与下游失联，界面上这个集群变灰变红；node-agent 挂了，日常管理基本无感，但你一旦要做节点操作就会被卡住，而且往往卡在一个说不清的地方。
方向是整个纳管环节最容易搞错的一件事。绝大多数自建场景下，Rancher Server 从不主动去连下游集群的 apiserver。真正发起 TCP 连接的是下游的 cattle-cluster-agent：它向 Rancher Server 的 443 端口发起 TLS 握手，然后 upgrade 成 websocket 并保持长连。之后 Rancher 的所有指令都跑在这条已经建立好的连接里。
所以防火墙要开的是这两条：下游集群的出方向允许到 Rancher Server 的 443（80 端口在需要跳转或证书校验时也要留）；Rancher Server 的入方向放行来自下游集群源地址的 443。反过来那条"下游放通 6443 给 Rancher"，多数情况下压根不需要做，这是最高频的配错。
这个设计还有个直接好处：下游集群在 NAT 后面、没有公网 IP，无所谓，因为本来就是你连我。这正是 Rancher 能把机房里只有内网的管理网集群纳管起来的原因。
证书这块有三个坑。第一，agent 启动时要校验 Rancher Server 的 TLS 证书，自签证书需要在注册命令里加不安全选项或者预先把 CA 灌进下游节点的信任链。第二，生产环境别偷懒用自签，老老实实用一个能被信任的证书，内部 CA 也行但要下发到节点。第三，证书忘记续期是每年必来一次的集体翻车——到期那一刻所有 agent 同时失联，界面上整排 Unavailable，而集群本身好得很。
另外，Rancher Server 的 server-url 必须在安装时就写成一个所有下游都能解析且能访问的地址。事后改 hostname 技术上可行，但存量 agent 全都要重新生成注册命令，代价不小。这也是我建议在下单一开始就把域名和网络入口定下来的原因。
界面上那个刺眼的 Unavailable，指的是"Rancher 到这个集群的控制通道断了"，不是"集群死了"。下游集群自己的 apiserver、etcd、控制器、调度器全都还在跑，kubelet 还在拉起容器，Service 的 endpoints 还在更新，Ingress 还在转发流量。用户请求一秒钟都没断。
真正受影响的是管理动作：kubectl 直连下游还能正常干活，但界面上看不了日志、exec 不进去、apply 不了 YAML、通过 Rancher 下发的 RBAC 也不会生效，告警流水线里的部分数据会缺，Fleet 的 GitOps 同步会停摆。
误判的代价在两个极端上都会爆发。一种是新人看到一整排红，立刻开始重启业务容器、切流量，把本来没事的事故搞成真事故；另一种是老油条看到一排红早麻木了，结果某次是真 etcd 崩了，被当成"老毛病"晾了两个小时。
区分方法特别朴素：变红之后，直接拿下游的 kubeconfig 敲一遍 get nodes，或者去看业务监控的 QPS 曲线和错误率。曲线平稳，就是通道问题；曲线塌了，才是集群问题。
配套的告警分层也建议做起来：Rancher 层面的 Cluster Unavailable 只发工单级或群通知；业务侧的 QPS、错误率、时延才配电话呼叫。这两类塞进同一个通道里，值班同事迟早把告警静音。
还有一种常见的假红值得一说：集群本身健康，其它命名空间都健康，唯独 cattle-system 在抽搐，原因是 cluster-agent 的 Pod 被调度到了一个网络策略受限的节点上，只有它自己连不出去。排查这一类问题，第一步永远是去看 cattle-system 里 agent 的日志。
这条 websocket 长连接的技术底座是 Rancher 自己的 remotedialer 库，一个多路复用的反向拨号器。打个比方就清楚了：agent 是打电话的那个人，Rancher Server 是接电话的那个人，电话一旦接通，双方都能说也能听。Rancher 想读下游的容器列表，就在这条已建立的 TCP 连接里再开一条逻辑子连接，让 agent 替它去拨下游的 apiserver，然后把响应沿原路送回来。
于是 NAT、防火墙、私有网络通通不成问题——只要出口能到 Rancher 的 443。这解释了为什么公有云上的 Rancher 能纳管机房里一组只有内网地址的节点。
但这条链路有几个地方需要留意。中间的 NAT 网关或防火墙如果有空闲超时，必须调大，或者依赖 agent 自身的心跳保活，TCP keepalive 和 websocket 层的 ping 都得留着。再者，一条连接上是多路复用的逻辑流，规模大的时候单条连接的吞吐会成为瓶颈，典型表现是界面上某个页面特别慢而其它页面正常。还有就是 session 的概念，Rancher Server 一重启，所有 session 失效，所有 agent 一起往回挤，这就带出下一节的问题。
Rancher Server 每次重启或滚动更新，都会触发一次全量重连。假设你纳管了 60 个集群，每个集群两个 cattle-cluster-agent 副本，再加上 node-agent 的会话，瞬间涌进来的连接是几百条起步，而且集中在几秒之内到达。
Rancher Server 默认配置里对此是有速率与并发保护的，但默认值按中等规模设计。规模上来之后的典型画面是：Server Pod 的 CPU 冲到上限被打节流，内存一路涨到 OOMKilled，界面打不开，然后在最高峰被打掉重启，进入重启—重连—再重启的循环。
能做的事有这几件。给 Server 的 Deployment 明确写上 requests 和 limits，别让它掉到极低值或者 BestEffort。升级排在业务低峰做，不要赶在白天。真正滚动前先把副本数和资源临时拉起来。最重要的一条：找一次机会用 Prometheus 的 Rancher 指标对着 Pod 内存与 CPU 曲线看一遍重连峰值，看一次就有底了。
另外一个成本最低的风控手段是拆分：不要把所有集群都纳管到同一个 Rancher 上，按业务线或者按地域拆开。一个实例出事，影响面就那么大。
估算口径可以给一个粗糙但实用的参考：一个下游集群的日常常驻开销在几十 MB 内存加零点几个核的量级，做线性叠加就能得出个大概。注意这里的单位是"集群"与"节点"，不是 Pod。你纳管一个三节点跑二十个 Pod 的集群，和一个三节点跑两千个 Pod 的集群，对 Rancher 的负担差别很小；真正让负担起飞的是集群数量，是监控、日志、Fleet 这些组件带来的持续数据流。
Rancher 的角色是三层结构。全局角色作用在 Rancher 实例级别，决定你能不能建集群、能不能管用户、能不能改全局设置。集群角色作用在某个具体的下游集群上，决定你在这一个集群里是所有者、普通成员还是只读。项目角色作用在某个 Rancher 项目内的命名空间集合上。
注意这里的命名陷阱：Rancher 的"集群角色"和 Kubernetes 原生的 ClusterRole 是两个概念，混着聊会聊成一锅粥。
Rancher 会把自己的三层翻译成 Kubernetes 原生对象。某个用户被授予了某集群的成员角色，Rancher 会在下游集群里生成对应的 ClusterRoleBinding 或 RoleBinding，把用户的身份绑上去。所以你在界面上点一下授权，到下游敲 get clusterrolebinding，立刻能看到一批带 rancher 前缀的对象。这就是为什么说"权限是同步下去的"。
反过来的顺序要格外小心。直接在下游用 kubectl apply 出来的 RBAC，没有在 Rancher 里登记过， Rancher 的控制器在某些版本的协调循环里会把它当成多余的东西处理掉或者改写。想要稳定，就在 Rancher 里派；一定要两边都管的场景，先确认你那个版本对"外部保留"标注的支持情况。最坏的做法是一边在界面上点、一边在命令行改，两边互相擦。
还有一个高频事故点：Rancher 的全局管理员和某个集群的所有者完全不是一回事。给外部人员权限时，优先给项目级而不是集群级——项目成员只在它那个命名空间集合里有权限，越权面小得多。
接上外部认证之后，最省心的做法永远是把权限授予"组"而不是"个人"。Rancher 支持 LDAP/AD、SAML、OIDC 这几种主流方式。接完之后最容易出问题的地方，我按踩坑频率排一下：
组名与 DN 不一致。AD 里组的 DN、CN 大小写、嵌套组、主组这些细节，能让人配一个下午还是配不上。先拿一个测试组验证通了再铺开，别一上来就把生产组织单元挂进去。
搜索基准太宽或太窄。基准设到整个目录会引起搜索慢甚至超时，设到某个组织单元下面，成员不在那个单元就搜不到。给 Rancher 专门开一个组织单元是最干净的做法。
刷新周期带来的滞后。用户被移出组之后，Rancher 里的权限不会立刻消失，因为组信息刷新有间隔、会话令牌也有有效期。离职、转岗这类要求立即失效的场景，靠自动同步是不够的，必须配上人工复核流程。
OIDC 的唯一性字段选择。用 sub 最稳，用 email 有隐患，邮箱一改，一个人会变成两个身份，历史权限全串。
管理员后门。对接好外部身份源之后，务必先保留一个能登录的本地管理员账号，并且真的验证过能登进去，再去收紧其它登录方式。身份源一挂，你连自家 Rancher 都进不去，这种事真发生过不止一次。
项目是 Rancher 自己造的一层抽象，一个项目下面可以挂若干个命名空间。它的价值有两个：把授权单位从单个命名空间抬到一组命名空间；以及提供一层默认的网络隔离。
具体机制是这样的：Rancher 会给项目内的命名空间打上同一个项目标识标签，并且默认开启项目网络隔离，为每个命名空间生成对应的网络策略，允许同项目内容器互通、默认拒绝跨项目流量。前提是底层 CNI 支持网络策略，Canal、Calico 这类支持，Flannel 不支持。
这个默认开启的隔离是真的事故源。你把 A 业务的命名空间和 B 业务的命名空间放进两个项目，它们之间的容器网络突然不通了，排查半天结果是 Rancher 自动写下的网络策略在挡。同理，如果监控采集组件、Ingress 控制器、日志代理跑在另一个项目的命名空间里，跨项目抓取指标也会被挡住，需要显式加白名单，或者干脆把这些基础设施组件放进同一个项目。
还有一个小麻烦：命名空间创建时如果没有指定项目，会被塞进 Rancher 的默认项目里。默认项目中的系统类命名空间是有专门用途的，别往里塞业务。
| 对比维度 | import 纳管 | provision 自建（RKE2/K3s） | 控制面与数据面归属 | 解绑与迁移代价 | 适配的业务形态 |
|---|---|---|---|---|---|
| 部署动作 | 只在下游 apply 一段 YAML，装 cattle-cluster-agent，约 1–2 分钟 | Rancher SSH 到节点装发行版、编排角色，10–40 分钟/批 | 不变 | 删掉 cattle-system 里的资源即可，10 分钟内撤干净 | 托管集群、别人交付的存量集群 |
| Kubernetes 版本升级 | Rancher 管不了，需自己走发行版流程 | 界面可选版本、分批升级 worker | 升级涉及的控制面仍在你的集群里 | 升级逻辑随 Rancher，脱离后要自建升级流程 | 自建机房、人手少的团队 |
| etcd 与证书 | 由你负责，Rancher 不参与轮换 | Rancher 生成并轮换证书、管理 etcd 成员 | etcd 都在你的节点上，区别只是谁管 | 证书轮换要接回来，最易漏的一步 | 无人值守的边缘/分支站点 |
| 故障时的可用性 | Rancher 挂了业务照跑，只是看不见 | 同上，但无法扩容/修复节点（预估影响 30 分钟以上） | 数据面始终在下游 | import 侧几乎为零 | 两者数据面都不经过 Rancher |
| 对 Rancher Server 的常驻开销 | 约每集群数十 MB 内存 + 零点几核 | 同上，另加机器供给控制器的额外抖动 | 开销与业务 Pod 数关系很小 | 集群数与节点数才是变量 | 规模化时建议分实例拆分纳管 |
| 凭证风险面 | 注册 YAML 里的 token 等同集群管理员密钥 | 节点 SSH 私钥与云凭据存在 local cluster | 两边都要按老密钥级别管理 | 退出后必须轮转一次 | 有合规审计要求的行业 |
单节点方案（单容器或者单节点 K3s 加 Helm）适合的功能是测试、演示、以及纳管不超过五六个小集群的内部环境。它的致命处在于单点：机器一宕、盘一坏，管理面全停，而且这类单容器形态没有可靠的原地迁移路径。它的定位应该是"先把它跑起来"，别让它一路跑进生产。
高可用方案是三个节点跑 RKE2 或 K3s 的控制面与 etcd，Rancher Server 以三副本 Deployment 落在上面。为什么是三个：etcd 走 Raft 一致性算法，能容忍 (n-1)/2 个成员失效，写请求需要多数派应答。一个节点毫无容错；两个节点反而比一个更糟，法定人数是二，挂一个整个集群就废；三个是能容忍单点故障的最小奇数，也是绝大多数场景的性价比甜点。五个能容忍两个故障，通常出于多机房的考虑才会加到五。
磁盘这一项我不建议省钱。etcd 的 WAL 必须落在 SSD/NVMe 上，并且建议实测第 99 百分位的 fsync 延迟保持在个位数毫秒量级。机械盘、 NFS、低性能的共享块存储都别给 etcd 用。
具体规格给一个能落地参考：三节点高可用，每节点 8 核 16G 起步，NVMe 系统盘外加一块独立数据盘专门给 etcd，视纳管规模往上加。纳管二十个以内小集群，这个配置是够用的（预估）；集群数上百、节点总数过千就要重做容量模型。
这里插一句选型建议。架设高可用的时候，#1 一万网络「裸金属 E5-2698v4×2 ¥3999 起」这种双路物理规格跑 etcd 加控制面是相当宽裕的，二十多个物理核留给 Raft 的 fsync 和 TLS 加解密绰绰有余；搭配官网明示的 BGP 多线 + CN2 GIA 回程、7×24 中文工单、工程师 1 对 1 部署这些配套，跨地域维护时沟通成本会低很多。整套三节点高可用的月度预算，粗估在 ¥1.2–2 万的区间（预估，非官方报价，实际以下单时核算为准），差别主要在机房、带宽与是否含 CN2 GIA 回程。
这一节值得单独拎出来讲，因为它直接决定了你浪费多少钱。给 Rancher Server 做容量规划的正确口径是三层相加：纳管集群数乘以每集群的常驻开销，加上节点总数乘以每节点开销，再加上并发的界面与 API 会话带来的一次性开销。Pod 数量只在个别操作里短暂影响——列 Pod、拉日志、读指标。
举个直观的例子：纳管三十个集群、累计三百个节点、跑两万个 Pod 的环境，负担远小于纳管五个集群但每个集群都装了监控、日志、服务网格的场景。后者的持续数据流会不停地往 Server 与 local cluster 里灌，把 CPU 和磁盘 IO 都吃掉。
所以规划时的顺序是：先数头（集群数与节点数），再数组件（有没有开监控、日志、Fleet、合规扫描、备份 operator），最后才决定加不加核。
还有一条经验：把这些重组件的存储从 local cluster 剥离出去，指向远端的对象存储或者独立的持久化卷。否则它压的不是 Rancher 的 CPU，而是 local cluster 的 etcd 和本地磁盘，最后表现出来的症状还是"Rancher 好慢"，然后你开始冤枉 Rancher。
公网入口部分，给 Rancher Server 一个固定域名加固定公网 IP。后世改 IP 或改域名的代价，远高于早期多花的那点钱——前面讲过 server-url 一变，所有 agent 都要重新注册。
端口只要记住 443 必开，80 在需要跳转或证书校验的时候开。别为了所谓的安全去改用非标准端口，agent 的注册命令要跟着一起改，纯粹增加混乱。
用中国香港或海外节点纳管境内的集群，技术上完全走得通，因为是境内的集群主动出连到境外 Rancher 的 443。但要注意三件事：一是这条出网链路本身必须可用且稳定，实际以线路测试为准，不要凭一个 Ping 值就下结论；二是管理平面的操作日志与集群元数据落在境外机器上，这在部分行业里是合规红线，落地前先过一遍法务与安全规范，别等上线被叫停；三是如果确实有这类顾虑，反过来做——Rancher Server 放境内，把境外集群纳管进来。
说到网络出入口的机型选择，这里推荐 #2 一万网络「支持 CN2 GIA 回程的独立云服务器」，管理面常年要求一个能被所有下游集群稳定访问到的入口，这类机型在这一项上比较省心；搭配官网明示的平均 5 分钟响应与 7×24 中文工单，出现 link 抖动时能第一时间找到人排障。一万网络深耕 IDC 19 年（成立于 2007 年），这种长期维护的沟通界面相对成熟。
备份必须分两层做，混在一起等于没做。第一层是 Rancher 自身的备份，用 rancher-backup operator 把 Rancher 的资源与 local cluster 里的关键 CRD 导出到对象存储（兼容 S3 协议的即可），配好定时与保留策略。第二层是下游集群的 etcd 快照，这是集群自身的备份，绝对不能只放在产出它的那台机器上——快照要拉出集群之外，落到对象存储或者独立的备份机。我见过太多"我们有快照"，最后快照跟 etcd 数据盘一起消失的案例。
最后一件事：没做过恢复演练的备份都不算备份。建议每个季度在测试环境用 restore 走一遍完整流程并计时，你会从中发现一堆平时根本想不到的问题。
第一条，忘记给证书做自动续期。为什么坑：Rancher Server 的 TLS 证书到期那一刻，所有 agent 同时失联，界面一整排 Unavailable，而集群本身好得很，值班同事的判断会被彻底带偏。怎么避：用自动续期方案，并且把到期剩余天数做成一条独立告警，提前三十天开始喊。
第二条，把 etcd 放在机械盘或共享存储上。为什么坑：etcd 对 fsync 延迟极敏感，延迟一抖就重新选主，症状是界面忽好忽坏但查不出原因。怎么避：NVMe 或 SSD，独立数据盘，上线前用工具实测第 99 百分位 fsync 延迟。
第三条，server-url 事后反悔。为什么坑：改域名或 IP 会让存量 agent 全部需要重新注册，几十个集群意味着几十次现场操作。怎么避：下单阶段就把域名、公网入口、证书想清楚，一次定死。
第四条，一边在界面派权限一边在命令行改 RBAC。为什么坑：Rancher 的协调循环会把未登记的绑定当作多余对象处理，两边互相擦，权限长期处于不确定状态。怎么避：选定一个入口，真要绕过就先确认当前版本的保留机制。
第五条，忽略项目网络隔离的默认行为。为什么坑：跨项目的采集、抓取、调用会莫名其妙不通，排查方向往往会跑偏到 CNI 上。怎么避：基础设施组件统一放在同一个项目里，跨项目访问显式开白名单。
第六条，把所有集群塞进同一个 Rancher 实例。为什么坑：重连风暴、etcd 抖动、误操作，任何一件事的影响半径都是全量的。怎么避：按业务线或地域拆分实例，宁可多一套管理面。
问一：Rancher Server 挂了，下游集群的业务会不会停？不会停。Rancher 只是控制通道，业务的容器、服务、Ingress 全都不经过它。真正受影响的是管理动作——看不了日志、进不了容器、apply 不了 YAML、新的 RBAC 不会下发、Fleet 的同步暂停。直连下游 kubectl 依然完全可用。所以这个故障的正确处置是修复管理面，而不是去重启业务容器，后者只会把一个"看不见"的问题升级成"真停了"的事故。
问二：为什么我 import 进来的集群，升级按钮不能用？因为 import 模式下 Rancher 只拿到了一个调用 API 的凭证，它不知道你的集群是怎么装出来的，也不知道节点的操作系统、私有镜像仓库、网络插件细节。这些信息只有 provision 模式下它才有。想让界面管版本，就得重走 provision 路线；否则老老实实按你的发行版自己的升级流程走。强行跨模式操作属于未定义行为。
问三：local cluster 到底能不能放一点点业务？我的建议是一点都不要放。哪怕只有一个 Pod，它也意味着你在 etcd 这台机器上赌了一把 IO 与安全边界。如果实在有需要联动的东西，宁可用外部集群加 API 的方式接进来，也不要调度到 local cluster 的节点上。给节点打污点是最省事的强制手段。
问四：纳管要不要给下游开 6443 端口？绝大多数情况下不需要。默认链路是下游的 cattle-cluster-agent 主动连回 Rancher 的 443，方向是出到入。你需要保证的是下游出方向能到 Rancher Server 的 443，以及 Rancher Server 入方向允许来自下游源地址的 443。把 6443 暴露给公网反而会凭空引入一个攻击面。
问五：集群显示 Unavailable，怎么快速判断是通道问题还是集群真挂了？两步。第一步在下游机器上直接用 kubeconfig 敲 get nodes，能返回就是集群活着。第二步看业务监控的 QPS 与错误率曲线，平稳就是通道问题，塌陷才是集群问题。另外去看一眼 cattle-system 里 agent 的日志，很多时候会直接写出是证书校验失败还是网络不可达。
问六：纳管一百个集群，Rancher Server 要多大？先别按 Pod 数算，按集群数与节点数算。一个下游集群的常驻开销在几十 MB 内存加零点几个核的量级，做线性叠加可以得出个大概；真正的不确定性来自监控、日志、Fleet 这些组件带来的持续数据流。粗配的话三节点高可用、每节点 8 核 16G 起步往上加，然后在一次真实的重连过程里对着曲线看峰值，用实测值反推。规模超过百集群量级，优先考虑拆实例。
问七：外部认证挂了，我还能进 Rancher 吗？如果你保留了本地管理员账号并且确认能登录，就能进。这也是我反复强调的那条后门：对接 LDAP/AD 或 OIDC 之后，必须留一个本地管理员并且真的验证过。身份源一旦不可用，没有后门就等于把自己锁在门外，只能走恢复流程，代价高得离谱。
本篇涉及的内容来自 Rancher 官方文档中关于架构、安装要求、agent 与权限模型的公开说明，以及我们在服务器租用与托管场景里实际交付、巡检时积累的运维记录。文中提到的资源开销与预算区间属于工程估算，标注了（预估）的部分不作为报价依据。
官网明示的价格口径：裸金属 E5-2698v4×2 ¥3999 起，一万云 ¥25 起，两者均为起点参考价；实际配置在加内存、加带宽、加 IP、选 CN2 GIA 回程之后会发生变化，具体以签约时最新报价与合同为准。
下单前建议核实这三件事。其一，磁盘介质。确认 etcd 落在 NVMe 或 SSD 上，并且问清楚是否可以提供第 99 百分位 fsync 延迟的实测数据，这一项决定了你的管理面稳不稳。其二，网络入口。确认能提供固定公网 IP 与可长期持有的域名，问清 443 入方向的放行方式与是否支持 CN2 GIA 回程，跨公网纳管时建议先做线路测试，实际以测试结果为准。其三，备份落点。确认对象存储的容量与计费方式，以及是否支持把备份数据拉出本机；这一步不做，前面的高可用只做了一半。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
