简介围绕Rancher部署Kubernetes集群的完整过程面向具备一定Linux与容器基础、希望以可视化管理方式快速搭建生产级K8s环境的技术人员。文档从服务器准备与节点角色规划入手给出至少3台Linux主机、Control Plane/Worker/Etcd节点划分及内网端口开放等前置要求随后分别介绍测试环境Docker快速启动与生产环境高可用两种Rancher Server部署方式并以Custom Cluster为例详细说明集群创建、集群名称与Kubernetes版本选择、网络插件配置、注册命令生成与节点执行等步骤最后通过Dashboard和kubectl完成节点及Pod状态验证。针对实践中的常见问题文档还整理了节点无法加入集群、网络插件故障等典型故障的排查思路以及添加新节点、升级集群、备份恢复等扩展操作。资源为单份docx文档大小仅19KB重点突出、命令可直接复用目前已有541人学习下载适合作为企业或实验环境部署K8s的实操手册。1. 容器编排里为什么偏偏选 Rancher 来管 K8s做过 K8s 集群的人都有这种体会kubeadm 能把集群拉起来但真到日常运维节点状态、证书、etcd 备份、工作负载滚动更新每一项都要去翻文档和 kubectl 命令。容器编排工具 Rancher 的价值就在于它把 K8s 的很多操作从命令行搬到了可视化界面同时保留了 kubectl 的入口。部署层面Rancher 既能在裸机、虚拟机、云主机上拉起一套全新的 K8s 集群也能把已有集群纳管到同一个控制面这对研发环境和生产环境并存、多集群管理的团队来说省掉的不只是敲命令的时间更多是踩坑后摸不清原因的痛苦。本文按从零到一的顺序讲——准备工作、Rancher Server 部署、创建与导入集群、日常管理最后落在一份排查清单和扩展用法。适合手里有几台 Linux 机器、想快速搭一套 K8s 并长期维护的团队。文中所有命令都基于 Rancher 2.6 和 K8s 1.20参数按照常见生产环境习惯给出。2. 准备工作先想清楚节点规划再碰 Docker 和 Rancher Server动手之前最该花时间的是节点规划。很多人栽在集群创建到一半才发现某个节点资源不够或者 Rancher Server 和业务集群挤在同一台机器上互相拖垮。规划做完再按下面的检查项走一遍基本能保证后面部署不顺时能判断是 Rancher 的问题还是 K8s 本身的问题。2.1 资源规划与节点角色控制面、etcd、工作节点怎么放Rancher 创建集群时允许自定义节点角色最常见的是三种角色etcd、controlplane、worker。一台节点可以同时勾选多个角色但生产环境建议把 etcd 和 controlplane 分开。etcd 是 K8s 的存储核心写入性能不好会直接影响整个集群的 API 响应通常单独用一台节点来跑。我的基线方案是这样的生产集群至少 5 台节点etcd 1 台、controlplane 1 台、worker 3 台worker 挂掉一台集群仍能正常调度。测试环境可以 3 台etcd controlplane 合设 1 台worker 2 台。任何节点的磁盘都不能低于 50Getcd 节点建议单独挂一块 SSD。Rancher Server 本身不建议和生产业务集群部署在同一台机器。Rancher Server 要跑 k3s默认或 K8s它还要承担 UI、API、数据存储负载不低。隔离的另一个好处是你在做 Rancher 升级、重启这类操作时不会误伤业务节点。2.2 基础环境检查Docker、防火墙、内核参数逐一确认Rancher 通过 Agent 往目标节点下发 K8s 组件所以每个目标节点都需要能访问 Rancher Server 的端口。最省心的方法是节点上预装 Docker。注意版本Rancher 2.6 对 Docker 版本有校验Docker 20.10 到 23.0 是比较稳妥的区间太旧会导致 K8s 组件启动异常。我一般会在每台机器上执行一段检查脚本确认基本条件# 检查操作系统版本和 Docker cat /etc/os-release | grep PRETTY_NAME docker --version # 检查防火墙状态生产环境必须显式放行端口 systemctl status firewalld firewall-cmd --list-all # 确认节点之间网络连通 ping -c 2 controlplane-ip # 清掉 swapK8s 要求 kubelet 必须能关闭 swap swapoff -a sed -i / swap / s/^/#/ /etc/fstab # 加载内核模块并设置转发参数 modprobe br_netfilter echo net.ipv4.ip_forward 1 /etc/sysctl.conf sysctl -p这里的逻辑分几层swapoff是为了让 kubelet 的--fail-swap-on默认行为不发生冲突不关掉的话节点会一直 NotReadybr_netfilter是 K8s 网络插件Calico 或 Flannel能正确处理桥接流量的前置条件net.ipv4.ip_forward不打开会让节点间 Pod 通信不通。这些步骤通常不会立刻报错但集群部署完你会发现网络完全调度不起来到那时再排查成本就高了。2.3 部署 Rancher Server单节点起服务的最小命令Rancher Server 自身用 Docker 或 Helm 安装。单节点试用、数据量不大时直接docker run最方便但生产环境建议用 Helm 部署在独立的 K3s 集群上。这里先给出单节点的方式因为它最容易验证整个链路# 创建数据目录避免写入容器层导致重启丢配置 mkdir -p /data/rancher docker run -d --name rancher-server \ --restartunless-stopped \ -p 80:80 -p 443:443 \ -v /data/rancher:/var/lib/rancher \ rancher/rancher:stable启动后浏览器访问https://server-ip/首次打开会要求设置管理员密码和 Server URL。Server URL 建议直接填后续要访问的域名或 IP不要在集群创建后再改否则 Agent 和 K8s 的 webhook 地址全都会乱。/data/rancher目录里存的是 Rancher 自身的数据库和证书后续升级和备份都依赖这个目录。一个值得注意的点Rancher 默认会自签证书。如果有现成的合规证书可以在docker run时挂载证书目录替换但自签证书足够让功能链路跑通不必在早期卡在这上面。3. 从 Rancher UI 到 K8s 集群落地的两种路径新建集群与导入集群准备工作的最后一节做完后就能开始创建集群。Rancher 提供两种主流路径一是用 Rancher 内置的节点驱动在现有机器上拉起一套全新的 K8s二是先由 kubeadm 或云厂商部署好 K8s再导入到 Rancher 做集中管理。两种路径的后续操作在 UI 里差异不大但底层逻辑和使用场景完全不同。3.1 路径一Rancher 自动创建自定义集群在 Rancher UI 上点击「创建集群」选择「自定义」节点驱动。给集群命名后会看到一段由 Rancher 生成注册命令格式大致是curl -fsSL https://rancher-server-ip/system-agent-install.sh \ | sudo sh -s - --server https://rancher-server-ip \ --label cattle.io/oslinux \ --etcd --controlplane --worker把这段命令分发到各台节点执行之前先想清楚每台节点承担什么角色。etcd 节点只保留--etcdcontrolplane 节点只保留--controlplane工作节点只保留--worker。如果一台节点需要同时承担 controlplane 和 worker可以把对应参数拼在一起。Rancher 的 system-agent 会把这台节点注册进集群并安装对应的 K8s 组件整个过程大约需要 3 到 5 分钟具体取决于镜像拉取速度。节点执行脚本后回到 UI 的集群列表页面能看到节点状态从 Provisioning 逐步变成 Active。其间要留意两条命令的产物system-agent进程是否在跑以及节点上的 kubelet 日志是否报错。如果节点状态长时间停留在等待优先看journalctl -u k3s或systemctl status kubelet的输出而不是反复重启脚本。创建集群这一步最容易踩的坑是角色参数被重复执行同一台节点同时被传了--etcd和--worker而这个角色混合方式并没有严格按照规划来导致 Rancher 在初始化 etcd 集群时出现仲裁冲突。角色规划一旦确定尽量保证 etcd 节点只运行 etcd 角色。3.2 路径二把已有 K8s 集群导入 Rancher 管理团队里通常已经有一套用 kubeadm 搭起来的集群直接把 Rancher 塞进去不太现实需要通过导入的方式纳管。在 Rancher UI 点击「导入现有集群」给它起个名字Rancher 会生成类似下面的命令kubectl apply -f https://rancher-server-ip/v3/import/token/xxx.yaml在现有集群的 controlplane 节点上执行这段命令Rancher 会在集群里创建 local 命名空间下的 controller 和相关资源把 Rancher Agent 部署进来。之后 Agent 会持续像 Rancher Server 上报集群状态Rancher 这边就能看到节点的 CPU、内存、调度状态以及工作负载信息。导入方式的好处是不影响集群已有的运行配置它只是增加一套 Agent 组件kubectl 照常使用kubeadm 升级也照常走Rancher 不做干预。它适合已经有线上集群、暂时不想迁移的场景。要注意导入的集群在 Rancher 里默认的名称是随机生成的外显名并不影响 K8s 集群的真实名称无需担心混乱。3.3 在 Rancher UI 里验证集群健康的清单无论走哪条路径集群进入 Active 状态后都要做一次系统性的健康检查而不是直接部署业务。我通常会在「集群首页」的 Dashboard 上依次确认以下指标检查项期望结果对应 UI 位置节点状态所有节点 Ready集群 → 节点管理etcd 状态无异常告警所有 etcd 节点为 Active集群 → 集群仪表盘 → etcd系统组件kube-system 下组件全部 Running集群 → 工作负载 → kube-system网络插件Calico / Flannel 的 Pod 正常集群 → 工作负载 → kube-system存储类至少一个 StorageClass 可用集群 → 存储 → StorageClass如果某个检查项不符合预期直接跳到对应命名空间查看 Pod 日志。Rancher UI 的「工作负载」页面可以点击进入 Pod 详情查看日志和事件。这一套检查做完集群才算真正可以交付。4. 集群管理日常节点、工作负载与命名空间的操作路径集群创建只是开始后续的日常管理才是 Rancher 真正替你省时间的部分。Rancher UI 的核心管理对象是工作负载Deployment、服务Service和命名空间Namespace配合节点标签能实现精细的调度控制。这一节把最常用的操作讲透顺带提一下 UI 操作背后都发生了什么。4.1 节点标签与污点控制 Pod 调度到哪台机器一个常见的需求是把数据库类 Pod 固定到有 SSD 的节点上。在 Rancher UI 里点击节点名进入编辑页在「标签」字段中添加disktypessd保存后节点会带上对应 Label。然后在部署工作负载时在调度策略里选择「指定节点标签」并填入disktype: ssd这个 Deployment 的 Pod 就会被调度到该节点上。Rancher 的 UI 操作背后生成的是 Kubernetes 原生调度逻辑。节点标签配合污点Taint能解决更多问题——比如给节点设置污点dedicateddb:NoSchedule那么不主动容忍这个污点的 Pod 就不会调度上去。Rancher 在集群编辑页面提供 Taint 配置位可以直接添加。调用 GPU 的场景也能靠标签管理在 GPU 节点上添加nvidia.com/gputrue标签然后在工作负载的资源限制里填写 GPU 资源。Rancher 的节点内核和驱动检查需要提前在节点上配好 NVIDIA 驱动和 device plugin缺失时 Pod 会拉不起来排查日志时看到nvidia相关错误就直接定位到这里。4.2 部署工作负载镜像拉取策略、滚动更新与回滚在 Rancher UI 的「工作负载」页点击「创建」选择 Deployment填入镜像名和副本数即可。这里有一些必须关注的参数否则生产上很容易翻车参数生产环境建议值说明镜像拉取策略IfNotPresent 或 AlwaysAlways 能在 K8s 节点上拉取到改动后的最新镜像IfNotPresent 则在本地已有镜像时不会重新拉取滚动更新最大不可用25%控制滚动更新时最多允许多少旧的 Pod 被终止滚动更新最大超额25%控制滚动更新时最多多创建多少新 Pod容器资源请求CPU 100m / 内存 128Mi调度依据设置过低会导致节点过载容器资源限制CPU 500m / 内存 512Mi超过限制会被 OOM Kill滚动更新中的经典翻车现场是「新版本镜像起不来但旧 Pod 却被先终止了」从而短时间内丢服务。Rancher 的默认配置其实允许设置maxUnavailable: 0和maxSurge: 1这样新 Pod 起来并 Ready 后才会杀掉旧 Pod。操作路径在「工作负载 → 编辑 → 滚动更新」里调整这两个参数能救你半夜睡不好觉。回滚操作更简单Rancher 在 Deployment 的「版本」标签页保留历史版本点击「回滚」按钮就能恢复到上一个版本。这个功能对应的是kubectl rollout undo命令Rancher 把现场变量保存在 UI 里是真正的「后悔药」。4.3 命名空间与资源配额多人共用一个集群时的隔离手段Rancher 上不同项目天然对应 K8s 命名空间。给每个团队分配一个命名空间并在命名空间上设置ResourceQuota可以避免某个团队的应用把集群资源吃满而导致全局雪崩。Rancher 的「集群管理 → 命名空间」支持创建并配置限额也可以在创建命名空间时直接关联项目。配额设置里比较关键的是「请求限制」和「限制范围」。请求限制管的是 Pod 调度时的预留量限制范围管的是单个 Pod 能用的最大最小资源。如果团队里有人提交了一个自带超大 limit 的 YAMLRancher 会直接拒绝它原因写得很清楚超过命名空间配额。比资源配额更常见的问题是权限管理。Rancher 里可以创建多个用户并把他们绑定到不同项目上绑定后用户只能在对应命名空间操作。生产环境可以禁用管理员直接拉取所有命名空间只授权给运维角色。这样即便某个团队的开发误操作损失也被限制在局部。5. Rancher 部署 K8s 的常见翻车现场现象、原因、解决这一节是全文最可能的拦路虎合集。Rancher 虽然把 K8s 的复杂度藏起来了但在部署和日常使用中仍然有相当一批和官方文档无关的坑。以下是我的实际排障经验每一条都按「现象 → 原因 → 解决」的顺序记录可以直接对照排查。5.1 现象Rancher Server 重启后所有集群页面报错无法访问重启 Rancher Server 所在节点后UI 能打开但所有集群都变成 Unavailable同时浏览器控制台报网络层错误。原因基本是 Rancher Server 使用的自签证书和集群内 Agent 通信的 CA 不匹配。Rancher Server 重启后没有重新加载之前生成好的 CA 证书导致已经注册过的 Agent 无法重新握手。解决方式并不是立刻去改集群 Agent 的 yaml而是先确认 Rancher Server 的持久化数据目录还完整ls /data/rancher能正常列出文件夹说明数据还在。然后重启 Rancher Server 容器等待它完成数据库迁移和证书加载看到日志输出Rancher started successfully后再去 UI 观察集群状态是否恢复。如果依然失联在节点上重新执行集群导入命令会触发 Agent 重新注册操作成本很小。5.2 现象执行注册命令后节点长时间处于 Provisioning 状态Rancher 生成的自定义集群注册脚本执行后节点处于 Provisioning 状态超过 10 分钟。打开节点上的journalctl -u rancher-system-agent能看到大量连接错误或 TLS 错误。这通常意味着节点和 Rancher Server 之间的端口不通最常见是防火墙阻塞了443或8080端口以及服务器上配置的 Rancher Server 地址Server URL与实际地址不一致。解决方式在节点上先排查端口连通性用curl -k https://server-url/healthz看是否返回healthz字样。不通就去防火墙放行端口。如果端口没问题去 Rancher Server 修改全局设置把 Server URL 改正为实际域名或 IP然后重新生成注册命令并再次执行。注意首次部署时千万不要图省事写localhost这个错误几乎是最难排查的一种。5.3 现象集群创建成功后Rancher UI 突然打不开集群创建期间一切正常Ready 之后 Rancher UI 无法访问且 curl 报证书过期或无效。这种情形大多发生在使用自签证书的测试环境。Rancher 自带证书有效期约一年过了期限浏览器就会拒绝连接。生产环境很少有人会遇到但测试环境很容易被遗忘。解决方式是临时在浏览器中允许该站点的异常证书或者直接用docker restart rancher-server让 Rancher 重新加载证书。如果长期使用建议部署时给 Rancher Server 配好受信任证书并设置定时任务续期。我见过太多团队在测试环境被这个坑卡住半天。5.4 现象创建集群时应用卡在 Installing 或 Waiting无法进入 Active遇到这种卡顿先别去反复点击集群名称它会增加 Rancher Server 的计算负担。最直接的排查路径是回到集群列表中点击该集群右侧的「查看日志」观察 agent 和 kube-system 的 Pod 事件。常见的根因是某台工作节点的 Docker 版本过旧或 K8s 组件镜像拉取超时。处理方式优先检查所有节点的磁盘空间df -h能看到某些节点/var/lib/docker目录被占满K8s 组件镜像根本没有空间落盘。清掉无用镜像后Rancher 会自动重试。镜像拉取超时的场景则建议在节点上配好镜像加速器或离线镜像不要指望集群创建阶段的大流量网络肯定通畅。正常情况下节点和 Rancher Server 之间的带宽是集群能否顺利初始化的最大变量。5.5 现象集群已 Active但有个别节点始终 NotReady有时候集群创建成功了节点状态却是个别 NotReady节点上的 K8s 组件实际上在正常跑。排查时记得先看节点上的 kubelet 日志而不是直接去 Rancher 里重装。常见原因是节点的时钟偏移过大K8s 节点要求时钟同步精度较高时间误差超过几秒就会导致节点之间证书校验失败。执行ntpdate -u ntp.aliyun.com校准时间或者配置 chrony 持续同步。其次是检查节点上的磁盘压力journalctl | grep -i pressure能看到系统报磁盘压力过大的错误这类问题多在持续写日志的 worker 节点出现清理日志和扩容磁盘后节点会恢复。这两类原因占据了 NotReady 现场的大头。6. 扩展操作Rancher 把监控和备份接到你现有的体系里集群管理在基础功能落地后更值得做的是把监控和备份接进来否则你仍然只是「能用」而不是「可维护」。Rancher 的监控功能是基于 Prometheus 和 Grafana 实现的开启监控后集群的指标会以插件方式运行在 kube-system 命名空间无需单独部署。去 Rancher UI 的「集群工具」里点击「监控」保持默认参数并启用约两三分钟就能看到 Node 和 Pod 级别的监控面板。备份恢复是 Rancher 官方支持的能力对应的工具是rancher-backupOperator。它能备份整个 Rancher 管理端的数据在升级前做一次快照能避免升级失败后彻底回滚不动的窘境。导入现有集群后同样可以对这个集群做后台快照恢复时 Rancher 会把整个 etcd 数据和配置还原到指定时间点堪称集群层面的后悔药。操作流程大致是安装备份工具 → 创建定时任务 → 指定恢复时机。另一个值得投入的扩展点是把 Rancher 接入到已有的企业统一认证LDAP / AD。Rancher 支持用户通过外部认证系统登录登录后自动成为 Rancher 用户配合项目权限绑定使用比在 UI 上逐个建账号省心得多。切换外部认证的时机放在集群落地完成后两周内比较合适太早容易和本地用户策略冲突太晚用户习惯养成了再改权限反而麻烦。我的个人习惯是每次在 Rancher 上做任何大型操作之前先做一次便宜的备份然后开监控面板看机器的压力曲线。Rancher 这个工具真正让人上手的不是它的界面多漂亮而是点几下按钮就能把一组传统的 K8s 操作流程固化下来。希望这篇指南能帮你把搭建和管理 K8s 这条路走稳妥一些。本文还有配套的精品资源点击获取