企业官网建设流程全解析

简介：面向容器云运维、平台实施及DevOps工程师的Rancher PaaS平台部署与运维手册，聚焦从零构建高可用容器云平台的核心路径，适合有Docker基础并希望上手Rancher/RKE的读者。内容从环境需求与集群拓扑规划入手，覆盖开发/测试与生产环境差异设计，详细给出Docker安装配置、时钟同步、Harbor私有仓库搭建、项目配置及镜像清理、Rancher部署、RKE集群搭建，以及kubectl和helm工具安装方法，并穿插镜像准备与Dockerfile构建示例，可作为逐章跟做的实施笔记。资源为1个docx文档，共6.16MB，目录层级完整，章节划分清晰，便于按需查阅和培训复用。已有543人学习下载，适合企业容器云建设、个人实验或团队内部培训时参考。

1. Rancher平台部署与运维：把多集群管理从黑匣子变成日常操作

接手过五套以上K8s集群的人大概都有同一个体验——生产环境里的集群不是不够用，而是太多了。测试环境一套、预发一套、生产线两套，再加边缘机房一套，每一套都要配kubectl上下文、盯证书、查Pod调度。真正让人头大的不是K8s本身，而是多集群之间来回切换时那种“每次都要重新记一遍节点和命名空间”的割裂感。Rancher平台部署与运维解决的就是这个问题：它把多集群的认证、授权、监控、告警和升级收拢到一套Web界面上，同时保留kubectl的完整能力。这篇文章写给那些已经建过集群、想用Rancher接管现有基础设施的运维工程师，也写给准备从单集群走向多集群、但还没想清楚管理入口该放在哪里的团队。

2. 先搞清楚Rancher在K8s运维中的定位：为什么需要它

2.1 多集群管理的核心痛点：不是不会用，是工具太散

先别急着部署，想清楚一个问题：你已有的集群，用原生kubectl加一套Prometheus加一套Alertmanager，能不能管起来？能，但成本在于——每次新增集群都要重新配置认证方式，每套集群的监控面板各自独立，权限控制要么全给管理员、要么细分到ServiceAccount。这种散装方案在小规模下还能撑住，集群一多，光维护“谁有权访问哪套集群”这张表就能占掉大量时间。

Rancher在这个场景里的定位不是替代K8s，而是给你的运维体系加一层“控制面之上的控制面”。它做三件原生工具比较难做好的事：第一，统一认证入口，用一套账号体系映射到多个集群的RBAC；第二，把工作负载管理从YAML文件操作变成可视化的项目级操作；第三，提供集群导入功能，让现有集群不重建就能接入管理面。用Rancher的人不是不会写kubectl命令，而是想让日常操作少一点重复劳动。

2.2 单点版、HA版与嵌入式K3s：三种部署形态怎么选

Rancher的部署形态是有讲究的。最常见的是单节点Docker版，一条docker run命令就能拉起Server，适合测试环境、小团队内部工具、或者刚接触Rancher想评估一下的场景。但单节点的问题也很直白：Rancher Server本身挂了，管理面就全停了，虽然被管理的业务集群不受影响，但你在UI上看不到任何状态，告警也没处发。

生产环境比较稳妥的是HA版，Rancher Server跑在一套K8s集群上，后端数据落在etcd里，前端通过负载均衡对外提供服务。这个方案的好处是Rancher的升级、备份、恢复逻辑和它管理的集群一样，你用一套成熟的K8s运维经验就能维护管理面本身。还有一种形态是Rancher内嵌K3s，适合边缘场景，但如果你已经有生产K8s集群，没必要为了用Rancher再维护一套K3s。

选型上我一般这么建议：少于3套集群、管理面短期不做高可用，直接单节点Docker版跑着；超过3套集群、或者Rancher上面挂了生产业务集群，直接上HA。别在单节点上跑久了再迁移，Rancher从单节点迁移到HA虽然支持，但步骤比一开始就搭HA要烦不少。

2.3 Rancher与原生kubectl的分工：谁该用谁

很多新手会误以为用了Rancher就不碰kubectl了，这是理解偏了。Rancher的UI覆盖的是高频操作：看Pod状态、改Deployment副本数、看日志、配Ingress、对接到监控告警。但涉及CRD、Operator、自定义资源这类东西，UI往往没有合适入口，最终还是得用kubectl。Rancher的做法是把集群的kubeconfig交到你手里——在“集群管理”页面里可以直接下载某套集群的kubeconfig，配置好之后在本地用kubectl操作，和直接连集群没有区别。

所以合理的分工是：日常巡检、权限管理、多集群对比用Rancher UI；深度排障、修改CRD、调优调度参数用kubectl；批量操作服务器、初始化节点用Ansible这类自动化工具。三者不是替代关系，是各管一段。Rancher能在后端把kubectl执行的变更实时同步到UI，这点很重要，意味着你平时用顺手工具做的操作，在Rancher上看也是可见的。

3. 部署Rancher：从单节点到HA的落地路径

3.1 用Docker快速拉起Rancher Server：最小命令与参数解释

先跑通一个最小环境，后面所有运维操作都建立在Server可用这个前提下。单节点部署最直接的方式是用Docker：

# 在准备好的Linux主机上执行，建议至少4核8G sudo docker run -d --name rancher-server \ --restart=unless-stopped \ -p 80:80 -p 443:443 \ --privileged \ rancher/rancher:latest

这条命令的逻辑很直观：-d让容器在后台运行，--restart=unless-stopped保证主机重启后Rancher自动拉起，-p把宿主机的80和443端口映射到容器内。这里有两个参数值得留意，一个是--privileged，Rancher容器需要操作iptables和挂载文件系统，不加上会在创建集群时出各种权限错误；另一个是镜像标签，用latest跑测试没毛病，但生产环境一定要锁定具体版本号，否则哪天latest变了，docker pull拉下来的镜像和你的数据版本不一致，UI会出现版本不对齐的提示。

启动后浏览器访问https://<服务器IP>，首次打开会要求设置admin密码和Rancher Server地址。这里有个安全提示：如果Server是内网地址，Rancher会用它生成证书和Agent连接地址；如果填错了，后续接入集群的节点会连不上Server。首次安装页面填的那个地址，后面在“系统设置”里还能改，但改完要重启相关的Agent才能生效，所以第一次就填准确的域名或固定IP。

3.2 用Helm在K8s集群上部署HA版：三节点etcd与负载均衡

生产环境建议直接HA。做法是先有一套独立的K8s集群作为Rancher Server的运行底座，这套集群建议单独规划，不要和业务集群混用。在三台节点上分别安装RKE2或K3s，形成一个三节点的etcd集群，然后在这套集群上用Helm部署Rancher：

# 添加Helm仓库并创建命名空间 helm repo add rancher-latest https://releases.rancher.com/server-charts/latest kubectl create namespace cattle-system # 安装Rancher，cert-manager负责证书签发 helm install rancher rancher-latest/rancher \ --namespace cattle-system \ --set hostname=rancher.example.com \ --set replicas=3 \ --set bootstrapPassword=admin123456 \ --set ingress.tls.source=letsEncrypt \ --set letsEncrypt.email=ops@example.com

这段安装命令有几个参数要在意：hostname是你对外访问Rancher的域名，它会被写进证书和Agent连接地址里，务必是规划好的固定域名；replicas=3决定Rancher Pod的副本数，和底层K8s节点数对齐；bootstrapPassword是首次初始化admin账号的密码，后续在UI里还能改。证书来源用letsEncrypt需要外网访问能力，如果环境是纯内网，改成ingress.tls.source=privateCA并上传自签CA证书。

HA版部署完成后，前面还要挂一个负载均衡器，把443流量转发到Rancher Pod所在节点。常见做法是直接用云厂商的LB指向三个节点的443端口，或者用nginx代理到ingress-nginx的Service。这一步撸不清的话，后面Agent连接Server时的证书校验很容易出问题——Agent连接的是hostname对应的地址，如果LB到后端节点之间没有保持HTTPS协议，TLS握手会从头错到尾。

3.3 高可用部署必须调好的参数与策略

HA版跑起来之后，有三个东西要提前设好，不然上线之后再去补都比较折腾。

第一个是etcd的自动快照。Rancher部署在K8s上之后，它自身的配置数据存在这套集群的etcd里。用RKE2搭的集群默认有snapshot机制，但保留时间和备份目的地不一定符合你的要求。常见做法是配置crontab定期把etcd快照文件拷贝到独立存储，比如对象存储或另一台机器，保留7天。Rancher的配置数据一旦丢失，所有集群纳管关系都会断，重建的成本比恢复快照高得多。

第二个是Rancher自身的cattle-cluster-agent和cattle-system命名空间的资源限制。Rancher默认不限制Pod资源，管理集群规模一大，比如纳管了5套各有几十个节点的集群，Server的内存和CPU占用会明显上升。建议在Helm安装时加上resources.requests和resources.limits，不然到了告警阈值才发现内存快耗尽，排起来比较被动。

第三个是UI的session过期策略和审计日志。这两个在“全局设置”里都能配。审计日志尤其重要——Rancher作为管理入口，所有集群的kubeconfig下发都经过它，出了问题要能回溯是谁在什么时间做了什么操作。把审计日志的级别从0调成1以上，日志会记录API请求的细节，这对合规要求严格的团队是必选项。

4. 集群接管与日常运维：把业务集群纳入Rancher管理

4.1 导入已有集群：kubeconfig与clusterID的配合

Rancher最实用的功能之一是导入已有集群，不需要重建业务集群就能接入管理面。操作路径是“集群管理”->“导入已有集群”，选择“通用”类型，Rancher会生成一段curl命令和一个clusterID。这段命令要在目标集群的控制节点上执行，它的作用是在目标集群里创建cattle-system命名空间，并启动cattle-cluster-agent，让集群主动向Rancher Server建立连接。

命令执行后，Rancher侧会显示“等待注册”，正常情况下几分钟内变为“活跃”。如果一直停留在“等待注册”，先看Rancher Server能不能访问到目标集群的API Server地址；再看目标集群上cattle-cluster-agent这个Deployment的Pod日志，大概率是连不上Server、证书校验失败或集群地址填错了。

导入完成之后，可以下载这套集群的kubeconfig，在本地用kubectl操作。这里有个小技巧：Rancher生成的kubeconfig里，server字段指向的是Rancher Server的地址，而不是目标集群的地址——所有请求先经过Rancher认证，再由Rancher转发。所以这套kubeconfig是带着Rancher的访问权限的，别把它直接发给没有Rancher权限的人。

4.2 用项目-命名空间-工作负载三层模型做资源规划

Rancher对多集群的资源管理建立在“项目”这个概念上。一个项目可以跨多个命名空间，也可以跨集群。日常规划时，我建议按业务线建项目，比如“订单中心”“用户中心”“数据平台”，然后把每个业务线涉及的命名空间挂到对应项目下。这样做的直接好处是资源配额可以按项目设置，而不是按命名空间一个个配。

创建项目之后，在项目里添加命名空间，再部署工作负载。工作负载的类型支持Deployment、DaemonSet、StatefulSet等，UI上可以直接设置镜像地址、副本数、环境变量、健康检查。对新手来说，这个模型比直接写YAML要好理解——创建Deployment时，Rancher会自动生成对应的YAML，你在UI上的每一次改动都能看到底层的配置变化，相当于边操作边学。

对已经习惯写YAML的工程师，Rancher也不会碍事。右上角有“编辑YAML”按钮，直接改完提交即可。Rancher会在后端做校验，格式错了会直接报错，不会把坏配置下发到集群里。

4.3 日常运维必看的5个指标与告警规则

Rancher自带的监控功能是v2.5之后内置的，基于Prometheus。部署监控组件时，它会自动在每个集群里装好NodeExporter、KubeStateMetrics和Alertmanager。日常巡检我一般盯五个指标：节点CPU和内存使用率、Pod重启次数、磁盘使用率、Ingress的5xx比例、etcd的leader稳定性。

Rancher的告警规则默认覆盖了节点不可用、Pod频繁重启等基础项，但业务层指标需要自己加。比如想在订单服务5xx比例超过10%时收到通知，可以在监控页面新建一条PromQL规则，告警渠道支持邮件、Slack和Webhook。对国内团队来说，Webhook直接打到企业微信或钉钉机器人比较省事。

这里要提醒一点：Rancher监控组件本身会占用一定资源，每个集群大约需要1核CPU和1GB内存。如果管理面资源紧张，可以只在生产集群上开启监控，测试环境用轻量方案，或者用外部Prometheus拉取指标，不必每套集群都装一套完整监控。

5. Rancher运维中的5个常见坑：现象、原因、解决

5.1 证书过期导致UI变空白、API全部503

现象：某天早上访问Rancher UI，页面白屏或提示Internal Server Error；用API查询集群状态，返回503 Service Unavailable；查看Rancher Server Pod日志，大量x509: certificate has expired or is not yet valid。

原因：Rancher默认使用自签证书，有效期为一年。很多团队部署时图省事没接正规证书签发流程，过期之后就不声不响地挂了。

解决：如果Rancher是单节点Docker跑的，先停容器，备份/var/lib/rancher目录，然后重新启动Rancher容器并等待它自动生成新证书。重启之后UI能访问，但之前生成的集群Agent证书可能还是旧的，需要在每个纳管集群里手动重启cattle-cluster-agent的Deployment。如果接了自己管理的证书，在UI的“全局设置”里换掉cattle-roots-ca对应的Secret，再滚动重启Rancher Server Pod。别让证书裸奔，有条件就上自动化证书管理，比如cert-manager自签续期，省得每年为同一件事熬夜。

5.2 导入集群时worker节点反复出现“等待注册”

现象：新集群执行完Rancher生成的注册命令，集群状态一直是“等待注册”，或者节点列表里个别worker节点显示Waiting to register，过一会儿变成Active，然后又掉回Waiting。

原因：cattle-cluster-agent和cattle-node-agent需要从Rancher Server拉取配置，而节点向Server注册时要回连Server地址。常见是两种：一是Server地址填的是内网IP，worker节点访问不到；二是防火墙没放行TCP 443端口，注册请求被丢弃。

解决：先确认Rancher Server的地址从worker节点能访问，用curl -k https://<rancher-server>/v3测试。能通的话，再查cattle-node-agent的Pod日志，看它连接哪个地址失败。经常是安装时填了临时IP，后面换了固定IP导致的，这种情况下更新“系统设置”里的server-url，重启所有纳管集群的Agent。记住一点：改了Server地址，旧的Agent连接全要重来一遍，所以第一个地址就填固定域名是血泪经验。

5.3 升级Rancher后旧集群的cattle-cluster-agent一直CrashLoopBackOff

现象：Rancher Server升级到新版本后，某套近期未上线的新集群正常，但老集群的Pod反复重启，日志报failed to call leader election或者证书校验错误。

原因：Rancher升级后，新版本的Agent和Server之间的通信协议或认证方式有变化，旧集群里还没有同步更新Agent镜像。

解决：在Rancher UI里进入这套集群的“系统组件”页面，手动升级cattle-cluster-agent和cattle-node-agent。如果UI升级按钮不灵，直接在这套集群上执行kubectl rollout restart deployment cattle-cluster-agent -n cattle-system，重启后会拉取新镜像。升级Rancher之前，建议先看一下升级路径的文档，跨大版本升级不像小版本平滑，中间可能需要先升级到某个中间版本，直接从v2.6跳到v2.8很容易踩这个坑。

5.4 本地存储卷在节点重建后数据丢失

现象：某套集群的节点重启后，StatefulSet里挂载的本地数据卷变成Lost状态，数据全没了。

原因：用hostPath或者Rancher自带的local-path-provisioner时，数据存在节点本地磁盘上。节点宕机、被驱逐或者重装系统之后，数据和Pod一起没了。

解决：这是存储选型问题。Rancher本身不提供分布式存储方案，它只是把存储类透传给你。对这种数据可靠性要求高的服务，要么在应用层做多副本，要么接外部存储比如NFS、Ceph或者云厂商的块存储。如果你在小规模环境中确实只能靠本地存储，至少给节点打上标签，让StatefulSet的Pod调度到固定节点上，同时做好备份。这类问题在测试环境没人发现，生产上出了就是事故，处理方式是先用Rancher UI导出工作负载的YAML，再换存储类重新部署。

5.5 etcd快照恢复后集群状态不一致

现象：某套集群的etcd节点损坏，运维根据文档做了快照恢复，恢复完成之后集群节点是Ready的，但Rancher侧显示部分命名空间和Deployment丢失。

原因：etcd快照恢复的是etcd里的数据，但不是所有K8s资源都存在etcd里，比如一些由Agent上报的运行时状态、节点心跳信息、CRD的status字段。恢复后这些信息和快照时刻不一致是正常的，通常会在一段时间后自愈。

解决：恢复前先确认快照文件和当前集群的K8s版本匹配，跨小版本恢复问题不大，跨大版本就可能出现API字段不兼容。恢复后重点检查每个节点上的kubelet和容器运行时是否正常，再在Rancher里逐个确认集群的“节点”列表有没有异常。如果快照恢复后仍然有一些Workload卡在Pending，最常见的原因是节点的标签或污点丢了，在节点详情里重新调整调度策略即可。别把快照恢复当成万能后悔药，Rancher的多集群场景下，定期备份业务配置到版本仓库，比依赖etcd快照更稳妥。

6. 把Rancher的升级和多集群降级策略变成日常习惯

6.1 升级前的状态检查清单

Rancher升级是运维里最容易翻车的环节，但也是可以标准化的事。我习惯在每次升级前过一遍固定清单：第一，检查Rancher当前版本是否在目标版本的升级路径里；第二，确认所有纳管集群状态是Active，没有正在进行的任务；第三，对Rancher所在集群的etcd做一次快照，并把快照文件复制到独立位置；第四，给Rancher所在的命名空间再做一次资源导出，保存所有Deployment的YAML；第五，提前在测试环境或同一版本的其他集群上演练一次升级。这五步走完，再执行Helm升级。

6.2 用kubectl直接操作Rancher的几个高频命令

Rancher自身也是跑在K8s上的，直接操作它比UI操作快得多。查看Rancher版本：

# 查看当前Rancher镜像版本和Pod状态 kubectl get deployment rancher -n cattle-system -o wide kubectl get pods -n cattle-system | grep rancher

滚动重启Rancher Server Pod：

# 在对证书或配置做调整后，让Rancher Pod重新加载 kubectl rollout restart deployment rancher -n cattle-system

查看Rancher日志定位问题：

# 只看最近半小时的日志，过滤异常级别 kubectl logs -n cattle-system deployment/rancher --tail=200 --since=30m | grep -E "error|panic|fatal"

这些命令的意义在于：当UI都打不开的时候，这是最后的排障入口。Rancher的Pod日志里会明确写出启动失败、证书异常或数据库连接失败的原因。我看到很多运维同事遇到Rancher出问题就想着重装，其实先看日志能省掉一半不必要的折腾。

6.3 验证升级成功的三个信号

升级完成后别急着宣布成功，等三个信号同时出现再松气：第一，Rancher Pod全部变成Running，且版本号已经更新；第二，所有纳管集群在Rancher UI里显示为Active，没有报错；第三，随便进一个集群的工作负载页面，能看到Pod列表正常刷新，而不是持续转圈。第三个信号特别能说明问题——Rancher的API和集群Agent之间的通道恢复没恢复，看列表刷不刷新最直接。

这篇内容是基于Rancher做多集群运维时踩过的路和看别人踩过的路整理的。Rancher的价值不在于界面好看，而在于它把“多集群到底跑没跑好”这件事变成了一个能每天看、能告警、能追溯的系统。如果你正准备从单集群走向多集群，先去部署一个最小Rancher环境，导入一套测试集群走一遍全流程，再决定生产怎么落地。希望帮到你。

本文还有配套的精品资源，点击获取