前段时间帮一家初创公司搭了一套 Rancher2 单机版的 Kubernetes 管理平台从采购机器到跑通第一个测试环境整个过程里有不少值得记录的细节。不少刚起步的团队对 Rancher2 又爱又怕——爱的是它能把 Kubernetes 的多集群管理、权限控制、应用部署都集中到一个界面上怕的是网上搜索到的部署教程大多面向高可用分布式架构一套下来光机器就得好几台一看就头大。实际上单机版部署比很多人想象中简单得多成本也低得多。只要一台 4 核 8G 的机器装好 Docker跑一个容器几分钟就能把 Rancher2 Server 拉起来之后通过界面化的引导创建或导入集群开发环境就能立刻用上。这笔账对初创团队尤其划算不用一上来就追高可用也不用专门养一个 K8s 运维专家先用最低成本跑通业务等有真实流量压力了再平滑演进到生产架构这种路径要健康得多。这篇文章就从“为什么要用单机版”“部署前要准备什么”开始到“具体怎么装”“怎么建第一个集群”“日常运维怎么备份升级”再到“踩过的坑和排查思路”完整走一遍。内容主要面向两类人一是负责基础设施但还没系统性接触过 Rancher2 的开发或运维同学二是初创公司里身兼数职、需要快速把环境搞起来的全栈工程师。看完可以直接照着手顺操作。1. 为什么开发环境和初创公司适合单机版 Rancher21.1 资源开销的账要算清楚很多初创公司会在“要不要上 K8s”这件事上纠结很久。不上担心后面业务扩张回头改造代价大上又听说 K8s 集群至少得三台 master 起步再配几个 worker硬件和人力成本都吃不消。这里要纠正一个常见误解K8s 确实在生产环境建议高可用但开发环境的目标从来不是“高可用”而是“功能对等”。开发和测试同学需要的是一个能完整跑通的 Kubernetes 环境用来验证容器编排、服务发现、配置管理这些能力并不需要同城多活、故障自动切换这些生产级特性。Rancher2 单机版的价值恰恰在这里——Rancher Server 本身只跑一个容器管理平面开销非常小默认安装时占用大约 1GB 内存左右实际运行中 2G 内存就能比较从容地跑起来剩下的资源都可以分给业务集群。还有一种省资源的做法是“单机版 Rancher2 本地集群”。也就是 Rancher Server 用 Docker 容器跑在一台机器上然后在这台机器上继续装 Kubelet 等组件形成一个所谓的 downstream 集群。这个集群的 master 组件由 Rancher2 通过嵌入的 K3s 或者 RKE 启动单台机器既承载管理端也承载业务负载。对开发环境来说这种方式能把成本压到最低——一台 8 核 16G 的机器既管平台又跑业务应付十几个开发同事的日常使用完全够。我们当时就是这么干的一台物理机Rancher2 Server 加上两个测试环境集群跑了大半年内存峰值也就用到 12G 左右。1.2 单机版和高可用版的取舍逻辑Rancher2 的高可用部署方式本质上是把 Rancher Server 自身也纳入到一个 K8s 集群中再用 Helm 把 Rancher 安装进去。这种部署方式需要至少三个节点的 K8s 集群作为底座再加上外置数据库、负载均衡器整套环境搭下来非常重。对初创公司来说最大问题还不是机器成本而是这层的维护复杂度会直接摊薄本就紧张的开发精力——高可用集群的证书轮换、etcd 备份、控制面升级每一项都需要专门的运维知识。高可用版的核心优势是Rancher Server 挂掉一台另外两台照样能提供管理能力不会导致所有下游集群“失联”。但团队要清楚分析一下开发环境的 Rancher 即使短暂宕机影响的只是管理界面登录、部署入口这些操作已经跑起来的业务 Pod 该跑还是跑。业务连续性风险几乎为零因为这个环境本身就不承载线上流量。把这些因素全部列出来再看单机版就是开发环境和初创团队当前阶段的最优解——不是妥协是理性取舍。当然如果团队已经有成熟的 K8s 运维能力或者公司预算宽裕从一开始就用高可用架构也没问题。但对绝大多数资源有限的团队我建议先把单机版跑熟把 K8s 和 Rancher2 的日常操作练熟等业务量起来之后再按官方文档做迁移或重建。健康的技术演进路径是平滑的不是一步到位的。2. 部署前置准备硬件、系统与软件环境2.1 硬件配置怎么选Rancher2 单机版部署最容易被低估的是硬件需求。很多人以为给个 2 核 4G 的机器就行结果装到一半内存不足容器不断 OOM最后只能重来。个人经验给一个起步配置参考使用场景建议配置说明最小验证2 核 4G仅跑 Rancher Server不建本地集群偶尔测试开发团队日常4 核 8GRancher Server 一个小型下游集群开发团队多人使用8 核 16GRancher Server 多个下游集群或较大业务负载这里最关键的资源是内存。Rancher Server 默认会跑很多 controller包括各类 CRD 的 watch、认证授权模块、集群管理 agent 等内存曲线不是一条直线而是随着纳管集群数量的增加逐步上涨。我遇到过从 2G 内存起步纳管第三个集群之后内存飙到 3G 以上的情况。所以在预算允许时内存尽量给到 8G能省掉后面调剂资源的麻烦。磁盘方面系统盘建议至少 50G 空闲空间。Rancher Server 容器本身镜像不大但运行时会缓存大量镜像层而且容器日志如果不做轮转会持续增长。再加上 Docker 本身的一些 overlay 文件系统开销50G 是一个比较稳妥的起步值。有条件的话把 Docker 数据目录放到独立数据盘上避免系统盘被日志和镜像占满。2.2 操作系统与 Docker 安装Rancher2 单机版对操作系统的要求并不苛刻主流的 CentOS 7/8、Ubuntu 18.04/20.04/22.04 都能跑。但有一个隐藏条件是内核版本。Rancher Server 本身是容器运行对内核要求不高但如果要在这台机器上创建本地集群内核版本需要满足 K8s 的要求比如较老的内核可能在网络插件如 Canal、Flannel初始化时报错。建议内核版本至少 3.10 以上Ubuntu 20.04 及以上的默认内核基本没问题CentOS 7 则需要确认内核是否在 3.10.0-1160 之后的版本。Docker 的安装比较常规直接用官方源装即可。这里要注意一个 Rancher2 与 Docker 版本的兼容性问题Rancher2 官方文档对支持的 Docker 版本是有清单的但核心原则是“别用太新的 Docker”。Rancher2 通过 Docker API 与容器运行时交互如果 Docker 升级到太新版本某些内部 API 行为改变可能导致 Rancher Agent 初始化失败。我自己的经验是CentOS 上用 Docker 20.10.xUbuntu 上用 Docker 24.0.x跑 Rancher 2.7/2.8 都没有问题。如果你用的是 Rancher 2.6 或更早版本最好锁定 Docker 20.10这是比较稳妥的组合。装完 Docker 之后建议顺手做三件配置设置 Docker 开机自启systemctl enable docker调整日志驱动为 json-file并限制日志大小{ log-driver: json-file, log-opts: { max-size: 20m, max-file: 3 } }如果服务器有防火墙提前放行 Rancher 需要的端口主要是 80、443 和 6443。2.3 提前想好域名与访问方式很多人部署时忽略了一个细节Rancher2 的访问地址。安装时可以通过-e CATTLE_SERVER_URL或后续设置来指定 Server URL这个地址会写进 Rancher 的证书和集群配置里后续每个下游集群的 agent 都要通过这个地址回连 Rancher Server。所以部署前就要想好团队是通过 IP 访问还是域名访问。如果只是开发环境内部用直接用 IP 也行但后面如果要把 Rancher 暴露给多个协作者还是建议用一个内部域名配合 DNS 解析。这个决定要在部署时一次做对因为中途修改 Server URL会影响所有已纳管集群的连接会引出一堆 agent 重连问题处理起来比较麻烦。3. 核心部署步骤与配置解析3.1 一条命令拉起 Rancher ServerRancher2 单机版部署的核心就是一条 Docker 命令sudo docker run -d --privileged \ --restartunless-stopped \ -p 80:80 -p 443:443 \ -v /opt/rancher:/var/lib/rancher \ --name rancher-server \ registry.cn-hangzhou.aliyuncs.com/rancher/rancher:v2.8.5一行一行拆开解释--privileged这是 Rancher 容器内部需要嵌套运行 Docker 或管理容器网络时要求的特权模式。不加这个参数很多内置功能会直接报错比如创建下游集群时的节点启动失败。这是官方文档明确要求的不要省略。-p 80:80 -p 443:443Rancher2 管理界面默认走 HTTPS443 是访问入口80 端口会用于一些重定向和 Lets Encrypt 证书签发校验。两个端口都要映射出来。-v /opt/rancher:/var/lib/rancher数据持久化。/var/lib/rancher是 Rancher 容器内部的数据目录包含配置、证书、集群状态等。宿主机的/opt/rancher目录可以自己定只要是独立路径就行。这一步是整个单机版部署中最重要的一步——不挂数据卷Rancher Server 容器一删所有纳管集群和管理配置全部丢失比不写备份还可怕。--restartunless-stopped容器异常退出或宿主机重启后自动拉起。对开发环境来说没人会每天盯着容器状态有了这个策略就能少操心很多。镜像地址这里用了国内镜像源的地址原因是直接访问 Docker Hub 或某些境外源在部分网络环境下不稳定国内镜像源拉取速度更快。如果团队网络环境不同也可以使用rancher/rancher:v2.8.5这个官方镜像名。镜像版本方面我建议选择一个长期维护的稳定版本。Rancher2 的版本更新节奏比较快但没必要追求最新。拿 v2.8.x 举例这是 Rancher2 系列中比较成熟的版本界面和 API 都稳定配套文档也多。具体版本号可以从官方发布页确认原则是选择当前渠道中的 stable 版本。3.2 验证启动状态与首次初始化执行完 docker run 命令后不要着急打开浏览器先确认容器真的初始化完成。Rancher Server 启动过程要初始化数据库、生成证书、加载一堆 CRD 定义通常需要 2 到 5 分钟具体时长取决于机器性能和磁盘速度。观察状态的命令有两个docker logs -f rancher-server日志里如果看到类似Rancher API is ready或Listening on的字样说明启动完成。另一个更直接的判断方式docker ps容器状态是Up且不是几分钟内反复重启基本就没问题。可以再配合curl -k https://localhost看一下是否能返回内容能返回说明 HTTP 服务已经起来了。首次打开浏览器访问https://服务器IP时会看到一个设置初始管理员密码的页面。这里有两个关键细节。第一浏览器会提示证书不受信任这是正常的。因为 Rancher2 默认使用自签名证书只是用于内部环境不必担心。后续如果想要更规范的证书可以在 Rancher 里配置 Lets Encrypt 或上传自己的证书。第二初始密码是必须立刻记录好的。首次设置的管理员账号是admin密码自己设定后需要保存到密码管理器里。Rancher2 没有“找回管理员密码”的简单入口如果密码丢失需要在宿主机上通过容器内的命令重置非常麻烦。我们自己就遇到过同事把密码忘了的情况最后是进容器手动重置的绕了不少路。设置完密码之后Rancher2 会弹出一个引导页面让你选择是否要添加集群。这时候先不要急着操作因为 Rancher Server 还需要一点时间完成内部的集群初始化。可以等一两分钟刷新页面再操作。3.3 理解 Rancher2 的核心概念Server 与 Cluster在进入下一步创建集群之前有必要把 Rancher2 的架构和工作原理讲清楚否则后面很多操作会让人困惑。Rancher2 的逻辑分两层。一层是 Rancher Server 本身它负责管理界面、认证授权、多集群管理调度、应用商店这些控制面功能。另一层是被管理的下游集群Downstream Cluster这些集群可以是 Rancher 帮你在界面上创建出来的也可以是接入已有的 Kubernetes 集群。关键点在于Rancher Server 和下游集群之间的通信是通过在每个集群中部署一个个 agent叫做cattle-cluster-agent和cattle-node-agent来完成的。这些 agent 主动向 Rancher Server 发起连接而不是 Rancher Server 去连接集群。这个设计的妙处在于即使下游集群在防火墙后面只要它能访问到 Rancher Server 的地址就能完成注册和管理。理解了这一点就明白为什么 Server URL 必须设置正确——下游集群的 agent 需要通过这个 URL 找到 Rancher Server。如果地址不对、端口不通、证书不匹配agent 会一直处于Waiting状态集群注册就卡住了。单机版场景里Rancher Server 和下游集群如果跑在同一台机器上还有一个“回环”问题需要注意当集群 agent 尝试访问 Server URL 时如果 URL 填的是 localhost 或 127.0.0.1agent 访问的其实是容器内部或者宿主机自己的回环地址这会导致连接混乱。建议 Server URL 直接填宿主机对外 IP 或域名不要填 localhost。4. 快速创建一个可用的本地 Kubernetes 集群4.1 在 Rancher2 UI 中创建集群Rancher2 部署完成后下一步自然是创建自己的第一个 Kubernetes 集群。这是从“装好一个软件”到“真正能用起来”的关键一跃很多前期的坑都是在这一步暴露的。进入 Rancher2 界面后在顶部的菜单栏选择“新建集群”。Rancher2 会给出多个创建方式你可以创建托管在云厂商上的集群针对各云厂商做了集成、导入已有集群、或者自定义集群。对于自建机器、开发环境场景选择“自定义”这一项最合适。自定义创建方式下Rancher2 会展示一组节点角色选项etcd、Control Plane、Worker。这三个角色分别对应 K8s 集群中的三类节点职责。如果当前机器就是一台单机并且不计划再加机器最简单的方式是把三个角色全部选中一条命令就能让这台机器同时充当 etcd、控制面和 worker。对于开发环境这种“全能节点”是可以接受的但在生产环境千万别这么干单点风险太大了。页面下方会生成一条很长的 Docker 命令格式大致是sudo docker run -d --privileged --restartunless-stopped \ --nethost -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run \ rancher/rancher-agent:v2.8.5 \ --server https://Rancher地址 \ --token token字符串 \ --etcd --controlplane --worker这条命令是在要加入集群的节点上执行的。如果 Rancher Server 和这个节点是同一台机器直接在这台机器上执行即可。执行后节点会自动安装 Kubelet、etcd、kube-apiserver 等组件并向 Rancher Server 注册。整个过程需要几分钟到十几分钟不等取决于机器性能和镜像拉取速度。执行完命令后回到 Rancher2 界面能在集群列表里看到这个集群的状态从Provisioning变成Active。如果一直是Provisioning或者报错主要集中在两类问题一是镜像拉不下来二是节点网络不通或端口被防火墙挡了。这里有一个很实用的验证技巧在节点上执行docker ps会看到多个rancher-agent相关容器以及kubelet、kube-controller等容器。如果这些容器都在运行且没有不断重启说明集群初始化大概率成功。如果某些容器反复重启用docker logs 容器名看日志错误信息比 Rancher2 界面上显示的更有参考价值。4.2 如何理清节点角色分配第一次建集群的时候很多同学对 “etcd / Control Plane / Worker” 这三个角色的含义理解不深容易随便勾选。这里用生活化的方式解释一下。etcd 是集群的数据库存的是所有资源对象的状态。想象成一个账本Pod、Service、Deployment 所有的增删改查都要记到这个账本里。一旦账本损坏集群就玩完了。Control Plane 是集群的大脑kube-apiserver、kube-scheduler、kube-controller-manager 都在这一层。所有 API 请求都由这里处理相当于公司的管理层。Worker 是干活的人真正跑应用的节点。生产集群的最佳实践是这三种角色分到不同机器上etcd 用单独的机器因为磁盘 IO 敏感、控制面单独的机器、业务负载走 worker。开发环境没有这个条件就只能一台机器身兼数职。但我建议心里要清楚这是一台“全能测试机型”不是生产架构不要在开发环境里研究高可用也不要把生产标准一刀切套到开发环境上来。开发环境的另一个实操建议是如果公司将来可能扩到多台机器可以在首次建集群时就规划一个合理的主机角色分配。比如 A 机器分配 etcd Control PlaneB 机器分配 Worker。这样后面加机器时只需要在 UI 里编辑集群添加节点不用重新初始化和迁移数据。别嫌麻烦这一步规划和后面省下的事完全不成比例。4.3 验证集群可用性发布第一个测试应用集群状态变成 Active 之后先别急着给同事分发账号。花几分钟部署一个简单的测试应用验证整个链路的可用性。这一步做得越仔细后面团队使用时的返工就越少。在 Rancher2 界面中切换到刚才创建的集群依次进入“工作负载 - 部署”创建一个简单的 Nginx 工作负载名称test-nginx镜像nginx:latest命名空间default端口映射开启 NodePort端口随意比如 30080创建完成后在工作负载列表里会看到这个 Pod 的状态从Starting到Running。然后在浏览器访问http://节点IP:30080如果能打开 Nginx 的欢迎页说明容器调度、网络插件、服务发现、端口映射整条链路都通了。这一步其实暴露问题非常高效。比如常见的 Flannel 网络初始化失败、Canal 的 VXLAN 端口被封、kube-proxy 的 iptables 规则没生效都会导致 NodePort 访问不通。如果访问不通优先在集群的“工作负载”详情页看日志和事件大部分报错信息都会直接展示出来。5. 单机版日常运维备份、升级与资源管理5.1 备份策略数据卷与 etcd 快照单机版最危险的地方在于“所有东西都在一台机器上”所以备份的重要性反而比高可用版更高。高可用版至少有几台机器互相兜底单机版一挂全挂没有备份就只能从头再来。Rancher2 的备份分两个层面。第一个层面是 Rancher Server 自身的数据。前面部署时挂载的/opt/rancher数据卷包含了 Rancher 的配置、证书、用户数据对整个数据卷做定期备份即可。最简单的做法是用 crontab 定时把数据目录打成 tar 包再配合 rsync 同步到另一台机器或对象存储。tar czf /backup/rancher-$(date %F).tar.gz -C /opt rancher第二个层面是下游 Kubernetes 集群自身的状态。开发环境可能觉得不重要但一旦集群里的资源对象被误删、配置被改错就知道 etcd 快照多值钱了。Rancher2 提供了对下游集群的 etcd 快照功能在集群详情页的“快照”选项卡里可以配置。建议开启定期快照频率选择“每天”保留数量设为 3 左右既能覆盖最近几天的历史又不会把磁盘撑爆。有一个容易踩的坑如果下游集群的节点本身就是 Rancher Server 那台机器etcd 快照和 Rancher 数据卷都在同一块磁盘上。这时磁盘空间需要留够否则快照写到一半磁盘满了集群反而被备份操作拖垮。实测下来一个三四节点的开发集群每次 etcd 快照大概几百 MB 到几 GB 不等所以我的建议是给数据盘留出至少 20G 的缓冲空间。5.2 升级 Rancher2 的正确姿势Rancher2 会定期发布新版本修复安全漏洞和 bug。开发环境不是说不升级而是要掌握升级方法避免升级失败导致管理端长时间不可用。单机版的升级本质上就是“起一个新容器替换旧容器”的过程。操作思路备份数据卷拉取新版本镜像stop 并删除旧容器用相同参数同样的数据卷挂载和端口映射启动新版本容器。注意这里有一个操作顺序问题。很多人习惯直接修改容器标签或者先启动新容器再删旧的结果新旧两个容器同时挂载同一个数据卷容易造成端口占用或数据写入冲突。建议严格按“备份 - 停旧 - 删旧 - 起新”的顺序操作哪怕中间有几秒服务空窗也比数据冲突稳妥得多。升级前还要确认升级路径。Rancher2 官方对不同版本之间的大版本跨度有严格限制比如 2.6 到 2.8 不应该直接跳升必须按 2.6 - 2.7 - 2.8 的顺序走。升级前最好去官方发布文档确认版本间的兼容矩阵。这个文档信息很密集但值得花十分钟细读一下。跳过版本直接升级导致数据迁移失败的案例我在社区里看到过不少。5.3 资源监控与告警Rancher2 内置了监控功能可以通过内置的 Prometheus 采集集群和节点的 CPU、内存、磁盘、网络指标。开发环境虽然不要求完备的告警但建议至少在节点和集群两个维度看一下监控数据尤其是磁盘和内存。开发环境里最常见的故障就是内存耗尽导致 Pod 被驱逐或者磁盘满导致镜像拉不下来、容器写不进去。Rancher2 的监控组件默认有一个好处它会自动把 Rancher Server 所在节点和所有下游集群节点加入采集范围不需要为每个集群单独配置抓取目标。但要注意如果节点角色包含了 Worker监控组件的资源消耗也会算在当前节点上。对于 4 核 8G 的机器这套监控的额外开销约占 1G 内存左右需要提前留出。如果资源实在紧张还有一个轻量方案在宿主机上用cAdvisor 简单的脚本定时上报关键指标。但对于大多数团队Rancher2 自带的监控就足够了毕竟是图形化界面对不熟悉 PromQL 的同学也友好。6. 常见问题与排查技巧实录6.1 高频故障与排查速查表现象可能原因排查步骤页面打不开提示 502Rancher Server 容器还在初始化或已异常退出docker ps看容器状态docker logs看日志末尾创建集群后一直 Provisioning节点命令未执行、镜像拉取失败、网络不通检查节点上docker ps是否有 agent 容器检查节点能否访问 Server URLNodePort 访问不通防火墙未放行端口、网络插件异常检查宿主机防火墙和云安全组查看集群内kube-system命名空间的 Pod 状态Rancher2 页面登录后显示集群不可用Rancher Server 地址变更或证书失效确认 Server URL必要时重新生成集群 agent 配置容器不断重启内存不足或磁盘空间不足查看docker logs同时用free -h和df -h确认资源Agent 显示 Waiting 状态Token 过期、agent 版本不匹配复制最新的节点注册命令重新添加节点上述是开发环境部署中最高频的几类问题。失败不可怕可怕的是不知道从哪儿看起。我的经验是凡是容器相关的先看docker logs凡是集群初始化的先看节点上 agent 容器日志凡是网络不通的先排查三层——宿主机防火墙、云平台安全组、容器内网络。6.2 内存瓶颈与容器 OOM 的应对方案Rancher2 单机版的运行过程中内存是最容易出现瓶颈的资源。尤其是一台 4G 内存的机器启动 Rancher Server 后再创建一个本地集群内存很容易触顶。OOM 的表现不只是容器被杀更隐蔽的是某些应用进程自己尝试申请内存失败导致 Rancher UI 报错、API 响应超时但容器状态看起来还是Up。应对思路有几个。第一Docker 层面适当限制容器内存。虽然不建议给 Rancher 容器设一个严格上限它内部组件多内存波动大但可以设置一个软限制比如用-m 4g给它划一个上限避免它把机器内存全部吃掉导致宿主机系统崩溃。这里要注意Rancher 官方文档并没有强制要求限制内存这只是一个在资源紧张情况下可选的手段。第二给 Docker 本身设置资源回收策略。通过sysctl vm.overcommit_memory1可以在内存不足时提前返回错误避免系统进入长时间卡死状态。这个参数在测试环境可以配置生产环境要谨慎。第三也是我一直强调的如果预算允许直接上 8G 内存。省几百块钱可能花掉后面几天排障时间非常不划算。6.3 几个我踩过的隐藏坑再分享几个常规教程不会写到的细节。第一个坑是服务器时间同步。Rancher2 的很多内部组件依赖证书和 token 的时效性判断如果宿主机时间不准证书校验会直接失败表现为所有 agent 连接全部报错。开发机经常休眠、暂停容易积累时间偏差。解决办法是安装 chrony 或 ntp 服务保持时间自动同步。第二个坑是 Docker 数据目录的磁盘空间。Rancher Server 容器运行过程中会缓存大量镜像层和临时文件再加上创建下游集群时要拉取 kubelet、etcd、pause 等镜像这个开销很容易超过预期。建议定期清理无用的镜像和容器docker system prune -af --volumes但要提醒的是--volumes参数会把未被容器引用的数据卷一起删掉如果 Rancher 容器当时正好没运行数据卷会被误删。所以执行前一定要确认 Rancher Server 容器正在运行或者干脆去掉--volumes手动清理/var/lib/docker/volumes下的废弃目录。第三个坑是证书过期问题。Rancher2 默认的自签名证书有效期是固定的临期时管理界面会变慢或出现证书异常。到期的处理方式不是去改证书文件而是在 Rancher2 的“系统设置”中找到cattle.system-default-ca等配置重新生成。这个操作有一定复杂度更推荐的做法是在日常运维计划里加入“证书剩余时间检查”例如用命令定期查看证书有效期openssl x509 -enddate -noout -in /var/lib/rancher/.../证书文件6.4 多团队共用 Rancher2 时的权限规划最后聊一个容易被忽略的点。Rancher2 部署好了团队用起来但如果没有做好权限规划后续很麻烦。Rancher2 支持 RBAC可以为不同用户分配集群成员、项目成员、只读成员等不同角色。初创公司在早期往往全员都有管理员权限图一时方便。但踩过坑之后就会明白权限失控的代价比配置权限的高昂成本高得多——某个同事误删一个 namespace影响的可能是整个开发环境。建议最迟在第三个人使用 Rancher2 之前把权限收敛一下管理员只留给基础设施负责人其他开发人员按项目组划分到一个或多个项目中并给予项目级成员权限限制跨项目操作。这个划分在 Rancher2 里做起来并不复杂。先创建命名空间再将命名空间归入某个项目然后把成员加入这个项目并赋予角色。整个规划过程大概半小时相比后面可能发生的“误删事故”这半小时的投入非常划算。回到最开始的观点。很多团队在技术选型时容易被所谓的“生产标准”“最佳实践”吓住反而忘了当下的核心任务是“快速跑起来、持续可用、成本可控”。Rancher2 单机版的意义不是教大家怎么降级要求而是在正确的阶段选择合适的架构——开发环境就承载开发环境的职责初创阶段就没有必要背上生产级的负担。先把这套流程跑通等团队和业务成长到需要更高可用性的那天自然就知道该往哪个方向演进。