说实话我第一次正经用 Rancher 搭 k8s 集群的时候心里是有点抵触的。当时团队里已经有人用 kubeadm 裸跑过一套测试环境各种证书、apiserver 地址、etcd 备份把人折腾得够呛。后来换成 Rancher我才意识到问题不是会不会搭而是搭完以后怎么长期活得好。Rancher 最大的价值不是帮你把集群建出来而是把建集群之后的日常运维、认证、权限、监控和升级统一收口到一个平台里。这篇文章我按自己实战的流程来写从环境规划、Rancher 初始化、创建下游集群到集群跑起来之后的认证、存储、监控再到我踩过的几个典型坑。无论你是第一次接触 Rancher还是已经搭过几套但想理顺细节这篇文章都值得你从头到尾看一遍。1. 为什么我不再直接用 kubeadm 裸搭 k8s1.1 裸搭 k8s 真正让人头疼的不是安装这一步很多教程会给人一个错觉用 kubeadm init 跑一条命令k8s 就起来了。确实单节点、测试环境、一条命令没问题。可一旦你开始认真对待集群这两个字事情就完全不一样了。证书管理apiserver、etcd、kubelet 之间的证书有效期token 过期哪天不小心把/etc/kubernetes/pki删了整个集群直接不可用。高可用单控制节点挂了整个集群管理面就断了。要上 HA就得搞 keepalived haproxy 或者外部负载均衡这套东西配置起来不算难但和 k8s 本身是两套体系出了问题排查链路很长。插件完整性网络插件、ingress controller、metrics-server、dashboard、监控、日志每一个都要单独部署每个都有自己的一堆参数。升级小版本升级还好跨版本升级就是一场赌博。先升哪里、后升哪里、kubelet 和 apiserver 版本差多少这些全靠经验和对文档的理解。权限kubeconfig 在团队里传着用没有 RBAC 的概念谁都拿着管理员权限出问题根本分不清是谁干的。这些不是 kubeadm 的问题而是自建 k8s 本来就要面对的问题。问题是这些问题不会因为你换了一台配置更好的机器就消失。1.2 Rancher 解决的三个核心问题Rancher 给我的第一个直接感受是它把集群生命周期做成了产品而不是一堆零散命令的集合。具体来说它替我做掉了三件高频、高风险的事情集群创建标准化。RKERancher Kubernetes Engine把所有组件版本、证书、etcd、插件全部编排好我只需要在前端勾选节点角色填几个参数它就把一个生产级集群拉起来。同样的操作用 kubeadm 手搓第一次至少小半天而且不一定一次成功。统一认证和权限收口。Rancher 里可以配置本地用户也可以对接企业的统一认证。集群创建好之后你可以把某个用户绑定到某个集群的某几个命名空间让他只看得到自己项目里的资源。我团队里有个平台组和业务组平台组负责折腾基础设施业务组只需要在自己项目里部署应用Rancher 的项目隔离能力正好把这两拨人分得明明白白。管理端和控制面分离。Rancher 是一套独立的应用跑在单独的节点上。它管理下游的 k8s 集群所有 kubeconfig、证书、状态信息都通过 Rancher API 下发。也就是说即使某个下层集群的 API Server 挂了我依然可以通过 Rancher 的控制台看到它的状态甚至从一个界面跨多个集群查看负载均衡、Pod 状态、Event 日志。这在多集群场景下特别爽不用每个集群都切一 kubectl context。1.3 澄清几个常见的误解我见过不少人对 Rancher 的理解有些偏差这里提前说清楚免得后面操作的时候产生疑问。Rancher 不是一个K8s 发行版。你可以把它理解成一套K8s 集群操作系统它的下游集群可以用 RKE 自建也可以是任何标准 k8s 集群——比如你在公有云上买的托管集群也可以接入 Rancher 来统一管理。RKE 和 K3s 是两套不同的实现。RKE 是标准 K8s 集群的部署引擎适合需要多节点、复杂网络、大规模业务的中大型团队K3s 则是轻量级 K8s适合边缘、IoT、资源受限的环境。Rancher 现在对 K3s 的支持也很好如果你只是小规模测试或者边缘节点可以直接在 Rancher 里创建 K3s 集群。Rancher 不会让你的集群性能变慢。它只在创建和管理阶段介入集群跑起来之后你的业务 Pod 不会因为装了 Rancher 就多一层转发或者代理。它更像是个监理和管理后台而不是流量网关。2. 搭建前的机器规划与系统准备2.1 节点角色划分与最小资源配置Rancher 本身和它下游管理的 k8s 集群网络上是管理平台 工作集群的关系。所以第一步要规划两类机器角色用途建议最低配置数量建议Rancher 节点运行 Rancher 管理平台4C/8G 起生产建议 8C/16G1 台起步可用 LB 做高可用下游控制节点etcd Control Plane运行 kube-apiserver、etcd、scheduler、controller-manager4C/8G 起etcd 对磁盘性能敏感生产至少 3 台下游工作节点Worker运行业务 Pod按业务资源需求8C/16G 起到 32C/64G 不等至少 2 台起步我自己的一个典型配置是这样的3 台 4C/16G 的机器做控制面5 台 16C/64G 的机器做 Worker另外单独 1 台 8C/16G 跑 Rancher。这个规模应付一个中等偏上流量的内部系统集群完全够用。2.2 操作系统基础配置清单这一步很多人会跳过但恰恰是后面的坑。主要做四件事主机名规划。每台机器用hostnamectl set-hostname建议机名能体现角色和机房位置比如k8s-master-01、k8s-worker-02、rancher-node-01。不要用默认随机的 localhost。系统时间同步。安装并启用 chrony 或 ntp确保所有节点时间差控制在 1 秒以内。证书校验、etcd 选举、kubelet 心跳都对时间敏感。我见过某次节点 NotReady根因就是主机时间差了 5 分钟而 kubelet 证书验证直接失败。内核参数调整。建议修改/etc/sysctl.confcat EOF /etc/sysctl.d/99-k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 vm.swappiness 0 vm.overcommit_memory 1 EOF sysctl --system这些参数负责让 iptables 能正确处理桥接流量并降低内存交换对 Pod 稳定性的影响。关闭 swap。K8s 在默认情况下不允许节点使用 swap需要执行swapoff -a并注释掉/etc/fstab里的 swap 行。不关 swap 的话kubelet 起不来这个报错很直接。内核模块br_netfilter和overlay必须加载否则容器网络和存储驱动会出问题。modprobe br_netfilter overlay顺便加进/etc/modules-load.d/k8s.conf避免重启后丢失。2.3 容器运行时Docker 还是 containerdRancher 默认可以帮你把运行时装好但这里还是要决定用什么容器运行时。如果是从学习成本出发我建议你直接用 Rancher 默认的配置在创建集群时选择 Docker 或 containerd它会自动处理安装。简单说一下选型思路containerd生产环境下我更推荐。功能够用、性能更好、组件更少k8s 官方对它的支持也最积极。如果你使用 RKE2 或 K3s默认就是 containerd 体系。Docker如果你团队里已经有大量基于 Docker Compose 的脚本或者团队对 Docker 命令更熟可以先用 Docker 过渡。Rancher 早期版本多走 Docker很多老教程都是这个路子但新项目没必要坚持。在 Rancher 的创建集群界面里有一个 Container Runtime 下拉框选containerd就好。后续如果你想调整镜像加速、存储路径可以改对应的配置模板。2.4 网络方案选型网络插件决定了集群内 Pod 与 Pod、Service 与 Pod 之间怎么通信。Rancher 支持 Flannel、Calico 和 Cilium我在实际项目里基本在这三者里面选。插件网络模式优势适合场景FlannelVXLAN/UDPoverlay 网络简单稳定资源占用低小规模集群、快速验证、追求省心CalicoBGP 路由 eBPF 模式支持网络策略性能好、网络策略强、可排查性好中大规模集群、对网络策略有要求的生产环境CiliumeBPF 内核加速性能最好可观测性强支持服务网格加速对性能极致要求、愿意投入学习成本我自己的选择是 Calico原因是生产环境里面网络策略很重要业务方有权限隔离的需求RBAC 管的是谁能操作网络策略管的是谁能访问两者得配套。如果你刚开始学习选 Flannel 也没问题后面在 Rancher 里可以替换网络插件只是迁移应用需要些精力所以一开始就选好比较划算。3. Rancher 初始化从一条命令到可用的管理平台3.1 安装 Docker 并启动 Rancher 容器Rancher 本身以容器方式运行官方推荐的启动方式很简单。先在 Rancher 节点上安装 Docker然后直接运行docker run -d --name rancher \ --restartunless-stopped \ -p 80:80 -p 443:443 \ -v /opt/rancher:/var/lib/rancher \ rancher/rancher:v2.8.5这里有两个细节值得展开说端口80 和 443 是 Rancher UI 的默认入口。如果你自己机器上已经有 nginx 或者其他 Web 服务可以把宿主机端口换掉比如-p 8080:80 -p 8443:443。后续访问的时候用对应端口即可。数据卷/opt/rancher用来保存 Rancher 的数据库、证书和配置。这个目录务必挂到宿主机磁盘上而且最好是在独立数据盘上。容器删了重建数据还在平台就不会崩。日志用docker logs -f rancher跟踪。第一次启动要拉镜像、准备数据库大概一两分钟。看到日志里出现 Rancher UI is accessible 这类信息就可以访问了。提示Rancher 自身存储元数据的 Kubernetes 集群其实是跑在 Rancher 容器里的也就是说 Rancher 内部会用 k8s 来管理它的组件。这个设计很多人第一次可能没注意到但不用太关心它对你透明你只需要知道不要把/var/lib/rancher放容器里裸丢就行了。3.2 首次访问和引导配置浏览器打开https://服务器IP会看到一个引导页面。主要做几件事设置管理员密码至少 12 位建议用密码管理器生成随机密码。设置 Rancher Server URL。这里一定要填你之后稳定访问 Rancher 的地址比如https://rancher.example.com。如果后面改了地址集群代理和 kubeconfig 里的 server 地址会不匹配导致连不上集群这是很多人掉过的坑。进入主页后Rancher 会提示你可以新建集群或者导入已有集群。先不用急着创建先去设置 → 全局设置里确认几个选项。在全局设置里我会顺手做两件事修改默认的语言和主题Rancher 新版默认有明亮和暗黑两种 UI按团队喜好来。在高级设置里把feature-gates里某些不需要的预览功能关掉比如一些实验性的功能可以默认关闭以免误用导致不可预期的问题。3.3 多实例高可用要不要现在就做如果你只是测试环境单节点 Rancher 就够。但生产环境我建议至少给 Rancher 做两个节点前面挂负载均衡。高可用方案有两种常见方式外置数据库 多实例把 Rancher 的元数据库放到独立数据库然后多个 Rancher 实例通过负载均衡共享访问。RKE 部署 Rancher用 Rancher 自己的一套工具部署到 k8s 集群里让 Rancher 容器本身跑在 k8s 上这样能利用集群的调度和自愈能力但前提是你得有一个基础的 k8s 集群。作为起步先把单实例跑通数据卷做定期备份。等确认这套平台确实要长期服务生产业务再考虑高可用改造。初期不要把复杂度拉太高先把流程走顺。4. 在 Rancher 里创建 K8s 集群角色、网络和组件的组合4.1 新建集群还是导入已有集群Rancher 的主界面有两个入口。新建让 Rancher 通过 RKE/RKE2/K3s 帮你从零创建一个集群适合机器全新、没有历史包袱的情况。导入把已经存在的 k8s 集群接入 Rancher适合你之前已经有集群只是想统一管理和加一层认证控制层。我大多数情况都是新建特别是目标环境比较干净的时候。新建时让 Rancher 把所有组件编排好比导入后再手动改配置要省事得多。4.2 自定义节点创建集群的完整流程Rancher 的自定义创建方式是最灵活的界面配置完以后Rancher 会生成一条命令你在每台机器上执行节点就会被自动纳管。操作路径左上角菜单 → 集群管理 → 创建 → 自定义。进入以后需要配置几个关键项kubernetes 版本选择 RKE1 还是 RKE2我推荐 RKE2因为它是新架构更简洁组件更模块化etcd 独立出来升级更平滑。容器运行时选择 containerdRKE2 默认就是 containerd。网络插件在部署集群前选好 Calico。Cloud Provider如果你的集群跑在裸机或内网环境选择None即可如果跑在云上选择对应的云厂商驱动。配置完以后Rancher 会显示注册命令。比如sudo docker run -d --privileged \ --restartunless-stopped \ --nethost \ -v /etc/rancher/node:/etc/rancher/node \ -v /var/lib/rancher:/var/lib/rancher \ rancher/rancher-agent:v2.8.5 \ --server https://rancher.example.com \ --token xxxxx \ --etcd --controlplane --worker注意命令末尾的--etcd --controlplane --worker三个参数这决定了这台机器在集群里扮演什么角色。4.3 节点角色怎么分配Rancher 把 K8s 节点简化为三种角色etcd负责存储集群所有数据。它需要一致、可靠、低延迟的存储所以这个角色的机器磁盘务必用 SSD。Control Plane运行 apiserver、scheduler、controller-manager。它们负责调度与决策。Worker运行业务负载。生产环境建议三种角色分开控制节点至少 3 台工作节点至少 2 台。如果一个节点同时打上所有角色那就是单节点 all-in-one只适合本机学习演示生产千万别这么干。注册命令生成之后先把 3 台控制节点跑起来确认集群控制面起来了再把 Worker 节点加进来。我在实际操作中习惯控制节点一次性全部加入然后观察 5 分钟等所有控制面组件都进入 Running再批量添加 Worker。4.4 创建过程日志怎么看在 Rancher 集群列表里点开集群后有一个日志标签页。这里面会滚动显示集群初始化的所有关键事件。很多人第一次看到这个页面时会比较懵其实主要看两类日志节点注册日志能确认 agent 是否连上了 Rancher server。部署集群组件日志能看到 Calico、CoreDNS、ingress-nginx 有没有正常安装。一个常见现象是节点注册命令跑了但集群一直处于 Provisioning。此刻先看集群日志再看对应节点上的 agent 日志journalctl -u rancher-system-agent -f如果 agent 一直连不上 server大概率是 Rancher Server URL 配置的问题或者是 500 端口/双向 TLS 通信被什么拦截优先排查网络连通性和证书。4.5 创建完成后的验证集群状态变为Active后不要急着部署应用先做三件事在 Rancher 的集群详情里查看节点列表确认所有节点都是 Ready 状态角色标签正确。在工作负载页面随便创建一个nginx测试 Deployment看 Pod 能不能被调度到多个节点。用 Rancher 提供的kubectl shell网页终端执行kubectl get nodes和kubectl get pods -A确认所有系统组件状态正常。如果这些都没问题你这个集群就算是活了。5. 集群跑起来之后的第一批配置认证、存储、监控与扩容5.1 配置 kubeconfig 并接入 CI/CDRancher 集群详情页的右上角有一个Kubeconfig按钮可以直接下载集群的 kubeconfig。下载下来之后配置到开发机和 CI 机器上。这里有一个非常重要的操作不要把管理员账号的 kubeconfig 直接给所有人用。Rancher 里你有很灵活的授权模型在集群详情 → 成员里添加用户并赋予集群成员只读类或集群管理员权限。在项目里创建项目然后给业务组成员绑定项目成员这样他们只能看到自己项目下命名空间的资源。我团队里的做法是运维人员是集群管理员业务组是项目成员测试可以给只读权限。这样出了生产事故第一反应不是谁误删了而是哪个操作需要复核根源上减少冲突。接入 CI/CD 的时候把下载到的 kubeconfig 存到 CI 系统的 Secret 里部署阶段直接kubectl apply或者用 Helm 部署。Rancher 还自带一个持续交付Continuous Delivery功能可以把 Git 仓库里的应用定义自动同步到集群类似 GitOps。如果你团队已经在用 GitLab 或者 GitHub Actions也可以不用 Rancher 的 CD各取所需。5.2 存储从本地卷到动态存储类K8s 集群创建好以后应用跑起来通常会面临一个问题数据放哪里。在 Rancher 里你可以创建存储类StorageClass来简化持久化存储的申请流程。常见做法测试环境直接用local-path存储类把数据存到节点本地目录。Rancher 默认提供local-path存储类适合无状态或可重建的应用不过要注意它不支持跨节点迁移。生产环境如果团队有 NFS/Ceph/GlusterFS可以在 Rancher 里通过存储插件的界面直接创建存储类。以 NFS 为例填上 NFS 服务器地址和挂载路径Rancher 会生成对应的 StorageClass。云环境如果集群跑在公有云直接用云平台自带的存储类即可。创建好 StorageClass 后业务在部署时只需要在 PVCPersistentVolumeClaim里写storageClassName: nfs-client这类字段就能自动创建 PV。比手工创建 PV、PV 与 PVC 手动去关联要干净太多而且多租户场景下Rancher 的项目隔离机制也可以天然地管理 PVC 的权限边界。5.3 开启内置监控与日志Rancher 的监控模块默认是关闭的需要手动启用。路径集群详情 → 工具 → 监控。启用监控之后Rancher 会自动部署 Prometheus 和 Grafana并额外提供一套预置的 Grafana Dashboard包含集群层面、节点层面、Pod 层面的CPU、内存、网络、磁盘等关键指标。这套监控对中小团队来说基本够用不用自己从零搭一套。监控启用的同时我建议顺手打开日志收集。Rancher 集成了日志采集组件可以把集群内容器日志、kubernetes 事件汇聚输出到 Elasticsearch、Splunk 或 Kafka。没有现成日志系统的情况下可以先输出到集群自身等有接入条件再改造。这里给一个非常实际的建议集群事件一定要落一份到外部存储。K8s 的 Event 默认只保留很短时间集群出问题的时候想回头查半小时前一个 Pod 为什么被驱逐没有外部日志就抓瞎。5.4 扩容与升级用 Rancher 把肉的活干了集群跑一段时间之后往往需要扩容。Rancher 的扩容思路是加节点 改节点池。手动扩容直接在节点列表点击编辑勾选新角色然后复制生成的新命令去新机器上执行。节点池Node Pool方式如果你在 Rancher 里配置了云厂商驱动可以设定节点池的伸缩范围和规格Rancher 会调用云 API 自动加机器、加入集群。这在公有云环境特别舒服。升级集群版本时在 Rancher 集群详情页选择升级勾选目标版本Rancher 会按照策略逐个升级控制面和 Worker。因为它是组件编排平台所以升级过程会处理 taint、cordon、drain 这些步骤比手工一条条命令操作安全得多。我试过一次从旧版本跨两个小版本升级整个流程大概二十几分钟中间只出现过一批 Worker 节点被标记为不可调度Rancher 会自动处理完再调回业务影响比我想象中小很多。6. 踩坑记录我在实际搭建中遇到的最常见的 5 个问题6.1 节点注册上了但是 Pod 一直 Pending这个问题最常见的根因是资源不足。我们当时有台 Worker 节点内存只有 8G但节点池里kube-system的组件占了 3G业务一上来就把内存打满小 Pod 一直处于 Pending。排查步骤用kubectl describe pod pod-name看事件看到Insufficient memory就知道是资源问题。kubectl top nodes看节点水位。Rancher 的监控面板上能看到所有节点的资源使用曲线一目了然。解决办法要么加节点要么调整 Deployment 的 resource requests/limits把请求量压到一个合理值。Rancher 里可以直接编辑工作负载的资源配额。6.2 节点 NotReady根因是服务器时间漂移另一套集群出现过一个诡异现象所有节点都是 Ready但是有一个节点隔一会就 NotReady然后又自动恢复。Rancher 事件日志里能看到 kubelet 报错证书相关。最后排查发现那台宿主机的时间源配置有问题系统时间慢了几分钟。kubelet 与 apiserver 之间的双向 TLS 客户端证书校验会校验时间时间差超过一定阈值证书就被认为是无效的。解决办法很简单重新配置 chrony强制同步systemctl restart chronyd chronyc makestep然后再观察节点状态。从此以后我把确认时间同步列进了所有服务器的初始化清单再没出过第二次。6.3 Rancher Server URL 改过导致下游集群无法连接这是 Rancher 特有的坑。如果你安装后改过 Rancher Server 的访问域名或者 IP下游集群里的 agent 还是拿着旧地址去连接 Rancher结果自然是连接不上集群显示 Unavailable。正确的做法是在 Rancher 的设置 → server-url里改成新的地址。到下游集群的节点上编辑/etc/rancher/agent/agent.envRKE2 用的是/etc/rancher/agent/registries.yaml那一套找到旧地址并替换。重启 rancher-system-agent 服务systemctl restart rancher-system-agent。操作完以后节点会重新向新地址发起注册连接。所以一开始安装 Rancher 时强烈建议你就把 server-url 固定成最终要用的域名不要随便改。6.4 网络插件冲突用了两套网络方案有一段时间我在集群里想试试网络策略先装了 Calico后面又同时装了 Flannel。结果 Pod 之间的连通性时好时坏节点偶尔还会误报冲突 IP。这种事在 Rancher 里特别容易发生因为在创建集群时选网络插件它是在集群层面统一装的。如果你在已有 Flannel 集群里再去手动部署 Calico会导致两台 CNI 插件抢着配置同一个 Pod 的网卡、路由表和 iptables 规则。遇到这种情况建议走最省心的路径备份好业务清单重新创建一个新集群网络插件选好以后不要再动。我有一次为了图省事想直接在原集群上切网络结果花了两天时间还没有重建来得快。6.5 Rancher 节点重启后起不来Rancher 容器设置了--restartunless-stopped正常情况下机器重启容器会跟着起来。但有一次服务器重启之后Docker 先启了Rancher 容器却一直 CrashLoopBackOff。查看日志发现是 etcd 数据目录的文件权限不对目录所有者变成了 root容器进程没权限写。排查下来是之前我手动往/opt/rancher目录解压过备份文件把属主搞乱了。修复方法chown -R 1000:1000 /opt/rancher # 然后重启容器 docker restart rancherRancher 容器内部默认用 UID 1000 运行如果你挂载数据卷后遇到权限类报错优先检查这个。另外重启前先确认磁盘空间充足Rancher 的数据目录时间长了会比较大磁盘满会导致它完全没法启动。最后再分享一个我自己很受用的习惯每次搭完一套 Rancher k8s 集群我都会顺手把下面这些信息做成一张表存在项目文档里Rancher 管理地址、服务器节点 IP 和角色、Rancher 版本、K8s 版本、网络插件版本、存储类名字、证书到期时间。就这么一张简单的表后面团队接手的时候能省掉大量摸索时间。还有一个点定期备份 Rancher 的数据目录。Rancher 自带快照功能可以设置定时备份到 NFS 或 S3我建议频率至少一天一次。你可能会觉得 Rancher 本身不会出问题但真的遇到机器损坏、误删命名空间的时候这个备份能直接决定你是虚惊一场还是重建一套集群。记住Rancher 是管集群的但它自己的数据也是数据同样是命脉。