企业官网建设流程全解析

说实话，我第一次正经用 Rancher 搭 k8s 集群的时候，心里是有点抵触的。当时团队里已经有人用 kubeadm 裸跑过一套测试环境，各种证书、apiserver 地址、etcd 备份把人折腾得够呛。后来换成 Rancher，我才意识到问题不是"会不会搭"，而是"搭完以后怎么长期活得好"。Rancher 最大的价值不是帮你把集群建出来，而是把建集群之后的日常运维、认证、权限、监控和升级统一收口到一个平台里。

这篇文章我按自己实战的流程来写，从环境规划、Rancher 初始化、创建下游集群，到集群跑起来之后的认证、存储、监控，再到我踩过的几个典型坑。无论你是第一次接触 Rancher，还是已经搭过几套但想理顺细节，这篇文章都值得你从头到尾看一遍。

1. 为什么我不再直接用 kubeadm 裸搭 k8s

1.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 给我的第一个直接感受是：它把"集群生命周期"做成了产品，而不是一堆零散命令的集合。

具体来说，它替我做掉了三件高频、高风险的事情：

1. 集群创建标准化。RKE（Rancher Kubernetes Engine）把所有组件版本、证书、etcd、插件全部编排好，我只需要在前端勾选节点角色，填几个参数，它就把一个生产级集群拉起来。同样的操作，用 kubeadm 手搓，第一次至少小半天，而且不一定一次成功。

2. 统一认证和权限收口。Rancher 里可以配置本地用户，也可以对接企业的统一认证。集群创建好之后，你可以把某个用户绑定到某个集群的某几个命名空间，让他只看得到自己项目里的资源。我团队里有个平台组和业务组，平台组负责折腾基础设施，业务组只需要在自己项目里部署应用，Rancher 的项目隔离能力正好把这两拨人分得明明白白。

3. 管理端和控制面分离。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 集群，网络上是"管理平台 + 工作集群"的关系。所以第一步要规划两类机器：

我自己的一个典型配置是这样的：3 台 4C/16G 的机器做控制面，5 台 16C/64G 的机器做 Worker，另外单独 1 台 8C/16G 跑 Rancher。这个规模应付一个中等偏上流量的内部系统集群完全够用。

2.2 操作系统基础配置清单

这一步很多人会跳过，但恰恰是后面的坑。主要做四件事：

1. 主机名规划。每台机器用hostnamectl set-hostname，建议机名能体现角色和机房位置，比如k8s-master-01、k8s-worker-02、rancher-node-01。不要用默认随机的 localhost。

2. 系统时间同步。安装并启用 chrony 或 ntp，确保所有节点时间差控制在 1 秒以内。证书校验、etcd 选举、kubelet 心跳都对时间敏感。我见过某次节点 NotReady，根因就是主机时间差了 5 分钟，而 kubelet 证书验证直接失败。

3. 内核参数调整。建议修改/etc/sysctl.conf：

cat <<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 稳定性的影响。

4. 关闭 swap。K8s 在默认情况下不允许节点使用 swap，需要执行swapoff -a并注释掉/etc/fstab里的 swap 行。不关 swap 的话，kubelet 起不来，这个报错很直接。

5. 内核模块：br_netfilter和overlay必须加载，否则容器网络和存储驱动会出问题。

modprobe br_netfilter overlay

顺便加进/etc/modules-load.d/k8s.conf，避免重启后丢失。

2.3 容器运行时：Docker 还是 containerd

Rancher 默认可以帮你把运行时装好，但这里还是要决定用什么容器运行时。如果是从学习成本出发，我建议你直接用 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，我在实际项目里基本在这三者里面选。

我自己的选择是 Calico，原因是生产环境里面网络策略很重要，业务方有权限隔离的需求，RBAC 管的是"谁能操作"，网络策略管的是"谁能访问"，两者得配套。如果你刚开始学习，选 Flannel 也没问题，后面在 Rancher 里可以替换网络插件，只是迁移应用需要些精力，所以一开始就选好比较划算。

3. Rancher 初始化：从一条命令到可用的管理平台

3.1 安装 Docker 并启动 Rancher 容器

Rancher 本身以容器方式运行，官方推荐的启动方式很简单。

先在 Rancher 节点上安装 Docker，然后直接运行：

docker run -d --name rancher \ --restart=unless-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>，会看到一个引导页面。主要做几件事：

1. 设置管理员密码（至少 12 位，建议用密码管理器生成随机密码）。
2. 设置 Rancher Server URL。这里一定要填你之后稳定访问 Rancher 的地址，比如https://rancher.example.com。如果后面改了地址，集群代理和 kubeconfig 里的 server 地址会不匹配，导致连不上集群，这是很多人掉过的坑。
3. 进入主页后，Rancher 会提示你可以"新建集群"或者"导入已有集群"。先不用急着创建，先去设置 → 全局设置里确认几个选项。

在全局设置里，我会顺手做两件事：

• 修改默认的语言和主题（Rancher 新版默认有明亮和暗黑两种 UI，按团队喜好来）。
• 在高级设置里把feature-gates里某些不需要的预览功能关掉，比如一些实验性的功能可以默认关闭，以免误用导致不可预期的问题。

3.3 多实例高可用：要不要现在就做

如果你只是测试环境，单节点 Rancher 就够。但生产环境我建议至少给 Rancher 做两个节点，前面挂负载均衡。

高可用方案有两种常见方式：

1. 外置数据库 + 多实例：把 Rancher 的元数据库放到独立数据库，然后多个 Rancher 实例通过负载均衡共享访问。
2. RKE 部署 Rancher：用 Rancher 自己的一套工具部署到 k8s 集群里，让 Rancher 容器本身跑在 k8s 上，这样能利用集群的调度和自愈能力，但前提是你得有一个基础的 k8s 集群。

作为起步，先把单实例跑通，数据卷做定期备份。等确认这套平台确实要长期服务生产业务，再考虑高可用改造。初期不要把复杂度拉太高，先把流程走顺。

4. 在 Rancher 里创建 K8s 集群：角色、网络和组件的组合

4.1 新建集群还是导入已有集群

Rancher 的主界面有两个入口。

• 新建：让 Rancher 通过 RKE/RKE2/K3s 帮你从零创建一个集群，适合机器全新、没有历史包袱的情况。
• 导入：把已经存在的 k8s 集群接入 Rancher，适合你之前已经有集群，只是想统一管理和加一层认证控制层。

我大多数情况都是新建，特别是目标环境比较干净的时候。新建时让 Rancher 把所有组件编排好，比导入后再手动改配置要省事得多。

4.2 自定义节点创建集群的完整流程

Rancher 的"自定义"创建方式是最灵活的，界面配置完以后，Rancher 会生成一条命令，你在每台机器上执行，节点就会被自动纳管。

操作路径：左上角菜单 → 集群管理 → 创建 → 自定义。

进入以后需要配置几个关键项：

1. kubernetes 版本：选择 RKE1 还是 RKE2，我推荐 RKE2，因为它是新架构，更简洁，组件更模块化，etcd 独立出来，升级更平滑。
2. 容器运行时：选择 containerd（RKE2 默认就是 containerd）。
3. 网络插件：在部署集群前选好 Calico。
4. Cloud Provider：如果你的集群跑在裸机或内网环境，选择None即可；如果跑在云上，选择对应的云厂商驱动。

配置完以后，Rancher 会显示注册命令。比如：

sudo docker run -d --privileged \ --restart=unless-stopped \ --net=host \ -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 集群列表里，点开集群后有一个日志标签页。这里面会滚动显示集群初始化的所有关键事件。很多人第一次看到这个页面时会比较懵，其实主要看两类日志：

1. 节点注册日志：能确认 agent 是否连上了 Rancher server。
2. 部署集群组件日志：能看到 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/CD

Rancher 集群详情页的右上角有一个"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 后，业务在部署时只需要在 PVC（PersistentVolumeClaim）里写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。排查步骤：

1. 用kubectl describe pod <pod-name>看事件，看到Insufficient memory就知道是资源问题。
2. kubectl top nodes看节点水位。
3. 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。

正确的做法是：

1. 在 Rancher 的设置 → server-url里改成新的地址。
2. 到下游集群的节点上，编辑/etc/rancher/agent/agent.env（RKE2 用的是/etc/rancher/agent/registries.yaml那一套），找到旧地址并替换。
3. 重启 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 容器设置了--restart=unless-stopped，正常情况下机器重启，容器会跟着起来。但有一次服务器重启之后，Docker 先启了，Rancher 容器却一直 CrashLoopBackOff。

查看日志发现是 etcd 数据目录的文件权限不对，目录所有者变成了 root，容器进程没权限写。排查下来是之前我手动往/opt/rancher目录解压过备份文件，把属主搞乱了。

修复方法：

chown -R 1000:1000 /opt/rancher # 然后重启容器 docker restart rancher

Rancher 容器内部默认用 UID 1000 运行，如果你挂载数据卷后遇到权限类报错，优先检查这个。另外，重启前先确认磁盘空间充足，Rancher 的数据目录时间长了会比较大，磁盘满会导致它完全没法启动。

最后再分享一个我自己很受用的习惯

每次搭完一套 Rancher + k8s 集群，我都会顺手把下面这些信息做成一张表存在项目文档里：Rancher 管理地址、服务器节点 IP 和角色、Rancher 版本、K8s 版本、网络插件版本、存储类名字、证书到期时间。就这么一张简单的表，后面团队接手的时候，能省掉大量摸索时间。

还有一个点，定期备份 Rancher 的数据目录。Rancher 自带"快照"功能，可以设置定时备份到 NFS 或 S3，我建议频率至少一天一次。你可能会觉得 Rancher 本身不会出问题，但真的遇到机器损坏、误删命名空间的时候，这个备份能直接决定你是"虚惊一场"还是"重建一套集群"。记住，Rancher 是管集群的，但它自己的数据也是数据，同样是命脉。