简介面向容器云平台实施与运维人员的 Rancher 部署运维文档定位于帮助读者从零规划并落地一套可用的容器管理平台。内容先介绍 Rancher PaaS 平台定位随后梳理硬件、操作系统、软件、网络与主机名等环境要求并给出开发测试与生产环境的集群拓扑建议。部署部分按实际操作链路推进覆盖 Docker 安装与开机自启配置、时钟同步、Harbor 私有镜像仓库部署及项目与镜像清理策略、Rancher 服务部署、基于 RKE 的 Kubernetes 集群搭建以及 kubectl 和 helm 工具安装文末还补充 Dockerfile 示例、镜像构建与推送说明。资源为单份 docx 文档大小 6.16MB章节结构清晰适合作为实施手册对照查阅。目前已有 543 人学习适合正在规划或维护 Rancher 容器云平台的运维、架构及技术支持人员参考。1. Rancher 部署与运维不是又一个 K8s 发行版而是把多云集群收口到一套 UI一线环境里最常见的局面是Kubernetes 集群已经跑起来了但 kubectl、监控、日志、权限散落在不同工具链里排障时要开四五个页面来回比对。Rancher 做的事情就是把「部署与运维」这件事收口——无论是自建的 RKE 集群、托管的 GKE/EKS/AKS还是内网物理机上的裸金属集群都能在一套界面里完成认证、权限、监控、告警和应用发布。我最早接触 Rancher 是帮客户搭私有化 PaaS那时最打动我的不是多集群纳管而是它对 Rancher ServerK8s 之上再跑编排层这套体系做了封装团队不需要每个人都是 K8s 专家就能上手运维。这套文档适合两类人正在做容器云选型的技术负责人以及要独立撑起一套 Rancher 环境的运维工程师。2. 环境基线与集群拓扑硬件要求、主机名规则和 etcd 单点/多点的取舍2.1 硬件与操作系统要求别在资源上抠门etcd 吃的是 IO部署 Rancher 之前先回答一个基础问题这台机器够不够格跑控制面。Rancher 2.5.x 及之后的版本每个节点的内存建议不低于 8GB2.5.x 之前的版本 4GB 起步也能跑但只适用于演示环境。CPU 方面 4 核是底线如果同一个节点要同时承担 Rancher Server 和 RKE 集群的 Control 角色建议直接按生产标准上 8 核起步。磁盘这块是最容易被低估的。etcd 的性能决定了整个集群的上限官方建议用 SSD机械盘在 etcd 频繁写入时会出现明显的读写延迟症状是 apiserver 响应变慢、节点心跳超时。还有一个 K8s 默认行为要特别注意kubelet 默认把主机磁盘的 85% 作为可用上限一旦超过这个阈值节点上的容器会被批量驱逐服务器直接「摘出集群」。如果这台机器还部署了 Harbor、Jenkins 这类吃磁盘的应用Docker 数据目录要单独预留空间别等镜像把磁盘塞满再回头清理。2.2 软件要求与网络配置防火墙、SELinux 和静态 IP操作系统推荐 CentOS 7.8 及以上拿到机器先做两个动作关防火墙、关 SELinux。systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config这段命令的逻辑很简单Rancher 和 RKE 安装时会动态生成 iptables 规则和网络策略firewalld 参与进来会跟容器网络冲突SELinux 在 enforcing 模式下会拦截容器对文件系统的访问你会在日志里看到诡异权限报错但查不出原因。setenforce 0是临时关闭改/etc/selinux/config是永久关闭两条都要执行否则重启后 SELinux 又回来了。网络方面有一个硬性要求每个节点配置静态 IP。如果用了 DHCP一定要做 DHCP 预留保证节点每次拿到的 IP 一致。Rancher 会把节点 IP 写进证书和 apiserver 的地址绑定IP 一变节点直接失联这是很多环境重启后集群挂掉的隐藏原因。2.3 主机名规则与时钟同步两个容易被忽略的坑主机名是 K8s 集群里的大坑。K8s 的主机名只支持-和.两种特殊符号下划线、大写字母、中文都会导致 节点注册失败或证书不匹配。集群内主机名不能重复这个要求在生产环境尤其容易被忽略——两台机器都叫localhostkubelet 注册时互相覆盖表现是节点状态反复 NotReady。hostnamectl set-hostname k8s-master-01设置完用hostnamectl验证。与主机名同样重要的是时间同步etcd 对时钟偏移极其敏感节点间时间差超过几百毫秒就可能出现 leader 频繁切换。常规做法是写一个对时脚本每小时跑一次cat /usr/local/runntpdate.sh EOF #!/bin/bash /usr/sbin/ntpdate 192.168.66.40 /var/log/ntpdate.log hwclock -w exit 0 EOF chmod x /usr/local/runntpdate.sh crontab -e 00 * * * * sh /usr/local/runntpdate.sh这段脚本里192.168.66.40是内网 NTP 服务器实际部署时替换成你们自己的时钟源。hwclock -w作用是把系统时间写回硬件时钟避免重启后时间倒退。2.4 集群拓扑单 etcd 与多 etcd 的分界线开发测试环境和生产环境的拓扑差异本质上是「省钱」和「保命」的区别。单主机模式把 Rancher UI、RKE 的 etcd、Control、Worker 全部压在一台机器上适合 POC 演示多主机模式把 Rancher UI 单独放一台RKE 集群的 etcd、Control、Worker 可以混部适合测试环境。生产环境必须多 etcd、多 Control 节点且节点数要求是单数——因为 etcd 和 RKE 的 Control 平面都用 Raft 协议选主偶数节点在分区故障时容易打成平手无法选出 leader。以三 etcd、三 Control 的拓扑为例etcd 集群容忍一台节点故障Control 平面同样保证了高可用。我踩过的教训是别为了省机器把两个生产环境集群的 etcd 混部在一批物理机上一旦物理机批量宕机两个集群同时瘫痪排障时要面对双倍告警心态直接崩。3. Docker 与 Harbor容器运行时配置和私有镜像仓库落地3.1 Docker 安装联网与离线两种模式Rancher 依赖 Docker 承载自身和基础设施服务。可联网环境直接用 yum 源安装先把 yum 源换成阿里云或内网源再添加 docker-ce 仓库yum install -y yum-utils yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo yum -y install docker-ce docker version离线环境是生产内网最常见的场景——没有外网但服务器上有内网源。把 docker-ce 的 rpm 包连同依赖一起下载好上传到服务器后执行cd /data/docker-rpm rpm -ivh *.rpm docker versionrpm -ivh *.rpm会把目录下所有 rpm 包一起装关键点是依赖必须齐全否则会报缺依赖错误。装完必须验证docker version能正常输出 Client 和 Server 两端信息只输出 Client 说明 daemon 没起来。3.2 配置 Docker数据目录和日志上限一次性设好Docker 默认数据目录在/var/lib/docker如果系统盘不大早晚会被镜像和容器层塞满。我一般会在一开始就把数据目录挪到单独的数据盘同时限制容器日志的大小防止日志把磁盘吃光。mkdir -p /data/docker-data cat /etc/docker/daemon.json EOF { data-root: /data/docker-data, log-driver: json-file, log-opts: {max-size: 500m, max-file: 3} } EOF systemctl daemon-reload systemctl start docker systemctl enable docker这段配置的含义拆开看>curl -L https://github.com/docker/compose/releases/download/1.8.1/docker-compose-Linux-x86_64 /usr/bin/docker-compose chmod x /usr/bin/docker-compose离线环境直接把 docker-compose 二进制文件上传到服务器chmod x后移动到/usr/bin即可。Harbor 本体用离线包安装解压后修改harbor.ymlcd /data tar -xvf harbor-offline-installer-v2.2.1.tgz mkdir -p /data/harbor-data cd /data/harbor cp harbor.yml.tmpl harbor.ymlharbor.yml里有几个决定性配置hostname必须改成 Harbor 服务所在主机的内网 IP不能用127.0.0.1因为 K8s 集群里的 Pod 要通过这个地址访问镜像仓库内网环境直接注释掉 https 段落否则安装脚本会强制校验证书路径harbor_admin_password是初始密码data_volume指向刚才创建的/data/harbor-data。修改完执行./install.shHarbor 会用 docker-compose 拉起全套组件。装好后浏览器访问http://harbor-ip用 admin 登录先建项目再推送镜像。这里有个真实场景K8s 节点拉镜像走的是 HTTPDocker daemon 必须配置insecure-registries否则会报http: server gave HTTP response to HTTPS client。这也是内网环境最常见的第一道坎。3.4 Harbor 项目配置与镜像清理不给磁盘留隐患Harbor 项目建议按「应用名」或「团队名」命名一个项目对应一类镜像在项目里配置机器人账号给 CI/CD 用避免把 admin 密码到处发。镜像清理要主动配置规则Harbor 2.x 支持在「清理规则」里设置策略参数参数推荐值说明保留最近版本数10防止回滚时找不到历史版本清理超过天数的镜像30按镜像最后推送时间计算过滤条件repository按项目名匹配避免误清理触发器建议选「每日定时」执行时间放在凌晨避免白天清理影响 CI/CD 拉取。4. Rancher 与 RKE 集群从镜像准备到集群创建的关键步骤4.1 镜像准备内网环境先把镜像推到 HarborRancher 部署第一步是准备镜像。在线环境直接docker pull rancher/rancher:stable就能拿到最新稳定版内网环境需要把镜像先拉到一台能联网的机器上再 push 到 Harbor。docker pull rancher/rancher:v2.6.9 docker tag rancher/rancher:v2.6.9 harbor.local/library/rancher:v2.6.9 docker push harbor.local/library/rancher:v2.6.9这里的关键点是 tag 要明确到具体版本不要用latest。Rancher 升级时如果镜像 tag 指向 latest重新拉取后版本漂移UI 显示的版本和实际运行的版本不一致排障时会造成误导。内网环境还需要把 RKE 用到的基础镜像etcd、nginx-ingress、kubelet、kube-apiserver 等一次性同步到 Harbor这一步做得越完整后面 RKE 集群创建时越省心。4.2 部署 Rancher Serverdocker run 的参数含义Rancher Server 本身以容器方式运行最直接的部署方式是用 docker run 启动docker run -d --privileged \ --restartunless-stopped \ -p 80:80 -p 443:443 \ -v /opt/rancher:/var/lib/rancher \ harbor.local/library/rancher:v2.6.9参数逐个说--privileged是 Rancher 必需的原因——它要在容器内部管理 Docker socket、配置 iptables没有特权模式很多基础设施容器起不来--restartunless-stopped保证物理机重启后 Rancher 自动恢复-p 80:80 -p 443:443暴露 Web UI 和 API 入口生产环境前面一般再挂一层 LB-v /opt/rancher:/var/lib/rancher把 Rancher 数据持久化到宿主机服务器挂了换机器时可以直接迁移数据目录。启动后访问http://server-ip首次访问会要求设置管理员密码和 server URL。这里 URL 不要用 localhost填节点 IP 或 LB 域名因为后续所有集群回调都走这个地址——填错了会导致下游集群 agent 连不上 server这是个「填完就改不回来」的坑血泪教训。4.3 用 RKE 搭建集群cluster.yml 的写法与参数说明Rancher Server 起来之后下一步是创建下游 K8s 集群。用 RKE 命令行工具建集群需要写一个cluster.yml文件nodes: - address: 192.168.1.11 hostname_override: k8s-master-01 user: root role: [controlplane, etcd, worker] - address: 192.168.1.12 hostname_override: k8s-master-02 user: root role: [controlplane, etcd, worker] - address: 192.168.1.13 hostname_override: k8s-master-03 user: root role: [controlplane, etcd, worker] services: etcd: backup_config: interval_hours: 12 retention: 6roles数组决定节点角色示例是把三个节点全部配上 controlplane、etcd、worker 混合角色这是生产环境少机器时的常见折中如果机器充足推荐把 etcd 和 controlplane 分别独立。backup_config是 RKE 自带的 etcd 定时快照建议生产环境必须开。执行rke up --config cluster.yml后RKE 会依次在节点上部署 etcd、kube-apiserver、kube-controller-manager、kube-scheduler、kubelet 和 kube-proxy。整个过程是黑盒化的失败时看节点上的容器状态RKE 的日志会把每一阶段的输出打印出来出错关键词一般是 SSH 连接失败、镜像拉取失败或内核模块缺失。拿到 kubeconfig 文件后用 Rancher UI 的「导入集群」功能把 RKE 集群纳管进来。这里注意导入集群必须填 API Server 地址端口默认 6443Rancher UI 会自动生成一个 agent 部署清单下游集群的节点能联网访问 Rancher Server 才行。4.4 kubectl 与 helm运维工具的安装和验证集群建完运维工具要配上。kubectl 和 helm 是排障时最常用的两个命令版本要与集群版本匹配差距过大会出现 API 解析失败报server doesnt have a resource type实际上就是版本不兼容。curl -LO https://dl.k8s.io/release/v1.24.3/bin/linux/amd64/kubectl chmod x kubectl mv kubectl /usr/local/bin/ kubectl version --clienthelm 安装同理装完后确认helm version能输出正常。kubectl 连不上集群时先确认 kubeconfig 文件里的 server 地址和 cluster 证书再用kubectl cluster-info验证这个命令能快速区分是网络问题还是证书问题。4.5 Dockerfile 与镜像构建把应用接进 PaaS 的最后一步平台搭好后业务镜像的构建规范要有沉淀。常见做法是做一个基础 Dockerfile 模板FROM harbor.local/library/openjdk:8u232 WORKDIR /app COPY target/app.jar app.jar ENV JAVA_OPTS-Xms512m -Xmx1024m EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]构建和推送用一套固定流程docker build时打上harbor.local/library/project:tag的 tagdocker push到对应项目。这里最容易犯的错是 tag 用日期或latest导致发布后无法快速定位线上运行的是哪个版本。我习惯强制要求 tag 格式为应用名-分支-构建序号例如order-service-master-20241018-01推送后把镜像 tag 记录到发布单里回滚时直接指定上一个 tag。5. 运维避坑Pod Failed、NodePort 访问异常和证书过期5.1 同一工作负载多个 Failed 状态的 Pod先看 Events 再猜原因现象是工作负载页面上多个 Pod 显示 Failed重启后依然失败。常见原因有两个镜像拉取失败私有仓库地址错、认证失败、tag 不存在和启动命令出错。排查时用kubectl describe pod看 Events拉到镜像失败会看到ImagePullBackOff或ErrImagePull如果是启动命令出错Events 里会显示Back-off restarting failed container。解决思路按优先级走先看镜像地址能不能从节点上手动拉取再看启动参数是否正确最后检查资源限制是否太低导致容器被 OOM Kill。有一点容易被忽略多个 Pod Failed 且集中在同一个节点上时优先怀疑节点资源问题看看磁盘是不是又被日志塞满了。5.2 多个工作负载出现 Unknown 状态的 Pod节点心跳丢了Unknown 状态比 Failed 更危险它表示 apiserver 已经收不到 kubelet 的心跳。先查节点状态大概率是 NotReady。原因可能是网络分区、kubelet 进程退出、或者 Docker daemon 假死。登录节点执行systemctl status kubelet和docker ps检查核心进程kubelet 日志里常见的关键报错是Failed to connect to apiserver这说明是新节点证书过期或 apiserver 地址变更。这类问题我最深的体会是在 console 上看 Pod 状态只能定位到「哪个 Pod 挂了」真正的原因要登录节点看 agent 和 kubelet 服务状态。处理完恢复后不要急着把 Pod 全部重启先观察 5 分钟确认节点状态回到 Ready再让工作负载自行恢复避免同时重启造成雪崩。5.3 NodePort 服务只能通过 Pod 所在主机 IP 访问externalTrafficPolicy 惹的祸现象是 NodePort 服务在部分节点上能访问在另外一些节点不能。原因是 Service 的externalTrafficPolicy默认值为Cluster理论上所有节点都能转发如果手动改成了Local流量只会转发到当前运行 Pod 的节点其他节点访问自然失败。解决方法是把externalTrafficPolicy改回Cluster或保持默认。另一种情况是某个节点 IP 完全无法访问但该节点上的 Pod 一切正常。优先检查节点的 kube-proxy 和 iptables 规则用iptables -L -n | grep port确认规则存在如果规则存在但访问失败看节点安全组或防火墙是否对该端口放行。注意这里要排除掉我们最开始就关掉的 firewalld如果某个节点后来被重新启动过防火墙可能自动打开这也是为什么初始化时要同时执行 disable 操作。5.4 Rancher 证书过期UI 打不开的主角视角Rancher Server 的证书有效期默认为一年到期后 UI 会直接打不开或者报证书错误。内网环境没有自动续签机制必须手动处理。常规做法是重新执行生成自签名证书的命令覆盖旧的证书文件后重启 Rancher 容器。docker exec -it rancher-container-id bash curl -k https://localhost:443/v3这一步的难点在于 Rancher 的多个组件cattle-system、agent之间互信都基于这套证书证书重建后 agent 需要重新注册。处理顺序有讲究先备份 Rancher 数据目录再重建证书重启容器最后检查下游集群的 agent 是否恢复连接。如果你发现 UI 里集群状态一直显示 Active 但实际上连不上多半就是 agent 回连证书校验出了问题。5.5 新主机加入集群异常节点清理没做干净新主机加入 Rancher 集群时最常见的问题是节点上残留了之前的 K8s 组件。Rancher agent 加入时会检测节点上是否已有 kubelet、etcd 等进程如果有它会拒绝初始化日志里能看到Host is already configured with kubernetes。解决方法是先把节点清理干净停止并移除 kubelet、kube-proxy、calico、flannel 等残留容器删除/etc/kubernetes、/var/lib/etcd、/var/lib/kubelet目录再重新加入。还有一个隐蔽坑是内核版本过低导致 calico-node 组件反复重启——Rancher 对内核有最低版本要求CentOS 7 默认 3.10 内核在跑 calico 的 BPF 模式时会有兼容性问题解决方法是升级内核到 4.18 或更高版本或者把 calico 的网络模式改为 VXLAN。6. 备份恢复与集群迁移最后一手后悔药要提前备好6.1 etcd 备份与恢复RKE 自带快照的正确用法etcd 是整个集群的数据中枢所有 K8s 资源对象都存在里面。RKE 创建集群时如果开了backup_config会自动按间隔执行快照快照文件存在节点本地。手动备份的常规做法是rke etcd snapshot-save --name pre-upgrade-snapshot --config cluster.yml恢复备份同样用 RKE 命令rke etcd snapshot-restore会停止集群组件、恢复数据、再重启。注意恢复操作会回滚到快照时间点的状态之后创建的资源全部会消失所以操作前务必沟通确认。这是真正的后悔药——每次大版本升级前强制做一次快照恢复时再看是不是要回滚别到升级完才发现问题再临时找备份。6.2 Rancher Server 数据备份与集群迁移Rancher Server 的数据都存在/var/lib/rancher下备份最简单的方式是打包这个目录。恢复时把备份拷到新机器启动新的 Rancher 容器并挂载恢复的数据目录。迁移 K8s 集群时etcd 快照是核心新集群的cluster.yml要与原集群保持一致特别是节点角色、网络插件这种关键参数迁移后才能无缝恢复。6.3 验证恢复结果的检查清单恢复完成后不要急着宣布成功。我的习惯是逐项验证先确认 Rancher UI 能正常登录再检查集群状态是否显示 Active接着创建测试工作负载验证调度正常最后检查监控数据是否恢复。监控和告警别为了省事跳过——Rancher 内置监控能直观反映集群健康状态告警规则建议至少覆盖节点 NotReady、Pod 重启次数过高、磁盘使用率超过 80% 这三条。从那以后我每次动集群前都强制走一遍「备份 → 变更 → 验证 → 观察」的流程时间长了变成肌肉记忆故障恢复效率提升了一大截。希望帮到你。本文还有配套的精品资源点击获取