有句话得放在前面用 Rancher 搭 K8s 集群和用裸 kubeadm 完全是两种体验。Rancher 最大的价值不是帮你把集群拉起来而是把集群拉起来之后那堆“维护和运营”的活比如多集群管理、RBAC、监控告警、应用商店、日志中心这些东西如果全靠自建工作量直接翻倍。这篇文章我结合自己操作过的完整流程从环境准备、Rancher Server 部署、创建自定义集群、验证应用到踩坑排查原原本本写出来适合刚接触 Rancher 的朋友照着做也适合已经用裸 K8s、想引入 Rancher 做统一管理的团队参考。1. 为什么用 Rancher 而不是直接用 kubeadm1.1 Rancher 解决的是“集群运营”问题先聊一个很实际的问题如果你的目标只是“本地跑一个单节点 K8s 练手”那用 kubeadm 就够了甚至用 kind 或 minikube 更快。但如果你要的是“给团队一套能持续用的生产级 K8s 环境”那么圈层就不一样了。Rancher 解决的核心痛点有三个第一装好集群后的日常管理界面比如部署工作负载、看 Pod 状态、管理 ConfigMap/Secret图形界面比 kubectl 对非核心技术成员友好得多第二统一认证和授权对接企业账号体系权限划分、多团队隔离这种东西手写 RBAC 非常费劲第三集群级运维包括备份恢复、升级、监控告警、日志收集。也就是说Rancher 相当于给 K8s 套了一层“运营层”。它本身不是一个独立的容器编排系统而是把 K8s 集群包装成可以集中管理的对象。理解了这层关系你就知道为什么很多团队搭好集群后还要再装 Rancher——不是为了“搭建”这个动作而是为了后续每天都要做的“维护”。1.2 Rancher 创建集群的几种方式怎么选Rancher 创建集群一共有三种大路径选错容易走弯路先说清楚区别。第一种叫“自定义集群”指的是你自己准备好几台裸服务器物理机或虚拟机然后在 Rancher 界面里填节点信息或生成注册命令让这些节点加入 Rancher 管控的控制面。Rancher 会帮你在这些节点上安装各组件包括 etcd、kube-apiserver、kube-controller-manager、kube-scheduler、kubelet 和网络插件。这种方式最灵活也是我们今天的主线。第二种叫“导入集群”适用于你已经有一个跑起来的 K8s 集群想把它托管到 Rancher 里。导入不会对现有集群做破坏性改动只是装一个 agent 让 Rancher 可以连上它。如果你已经有裸 kubeadm 搭好的集群想马上获得 Rancher 的管理界面这条路径最快半个小时能搞定。第三种是驱动云厂商 API 自动创建节点Rancher 直接调用云服务商接口开虚拟机、装系统、加入集群。这种方式自动化程度最高但需要提前在 Rancher 里配置云厂商访问凭据而且生产环境我一般不建议在 Rancher 里直接管云主机资源安全和计量边界容易混乱。1.3 版本与 license 的现实考量Rancher 目前大致分两个家族旧一点的 v2.5/v2.6/v2.7 系列和新版 v2.8、v2.9、v2.10 系列。注意一点Rancher 的免费版功能其实已经覆盖了大多数中小团队的需求比如多集群管理、RBAC、项目空间、应用商店。对于一些高级功能比如某些全球级的多集群编排特性需要授权但学习环境或中小规模生产环境通常用不到。版本选择上我会优先用当前官方仍在活跃维护的 v2.7 以上版本。不要一上来就装刚发布的大版本除非你看了 release notes 确认没有影响使用的回归问题。我实际操作中见过一次 Rancher 升级到新版本后集群详情页的监控图表出现兼容问题的案例所以稳定版本用起来其实最舒服。2. 环境准备与前置条件2.1 节点规划与角色分配Rancher 创建自定义集群时节点至少要承担三种角色之一etcd、controlplane、worker。这三类角色有明确的分工逻辑etcd负责保存集群所有状态数据。它是整个集群的“数据库”如果它挂了集群只能读不能写严重时直接不可用。etcd 节点需要奇数个最少 1 个但生产环境至少 3 个。controlplane跑 kube-apiserver、controller-manager、scheduler是集群的“大脑”处理所有 API 请求和调度决策。worker跑业务负载是“手脚”。我的建议是学习环境或者资源紧张的小团队3 台机器每台同时承担 etcd controlplane worker 三个角色组成一个三节点集群这种部署最简单也能满足一般业务。如果资源允许最好把 etcd 和 controlplane 放在一起worker 单独拆出来这样业务应用的波动不会直接影响控制面稳定性。千万别只装一个单节点然后把 etcd、controlplane、worker 都塞进去——研发环境玩玩可以生产环境千万别这么干。2.2 服务器配置建议以生产环境标准看controlplane 节点建议至少 2 核 4Getcd 节点建议至少 4 核 8G 或更高磁盘必须是 SSDIOPS 不要低于 1000。worker 节点根据业务定一般起步 4 核 8G数据盘独立挂载。操作系统方面CentOS 7.9、Rocky Linux 8/9、Ubuntu 20.04/22.04 我都跑过都是没问题的。我这里以 Ubuntu 22.04 为例因为它的内核和 Docker 配合更顺滑软件源依赖也更干净。每个节点需要保证主机名唯一不要出现两个节点都叫 node1 的情况。匿名用户核心坑/etc/hosts 里必须写好每个节点的 IP 和主机名映射否则 etcd 成员之间通信经常出现证书域名不匹配的诡异问题。2.3 系统初始化配置在加入 Rancher 之前所有节点要做统一初始化。第一步是关闭 swapK8s 的 kubelet 默认要求 swap 关闭不关的话 kubelet 可能启动失败或行为异常。在 Ubuntu 下执行sudo swapoff -a sudo sed -i /swap/s/^/#/ /etc/fstab第二步是加载内核模块并打开流量转发。cat EOF | sudo tee /etc/modules-load.d/k8s.conf br_netfilter ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack EOF sudo modprobe br_netfilter sudo modprobe ip_vs然后写入内核参数cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sudo sysctl --system第三步是统一时间同步。不校准时间的话证书校验、日志时间戳、etcd 选举都会出问题。sudo apt update sudo apt install -y chrony sudo systemctl enable --now chrony2.4 Docker 安装与 cgroup 驱动Rancher 自定义集群在节点上主要通过 Docker 运行组件所以每个节点都要装 Docker。版本建议使用当前社区仍在维护的版本比如 24.0 或 25.0 之后的稳定版本。安装 Docker 后有一个关键配置cgroup driver 要改成 systemd。原本 Docker 默认使用的是 cgroupfs而 K8s 官方推荐 systemd两者混用会导致节点资源统计数据不一致底层容器容易被误杀。创建/etc/docker/daemon.json{ exec-opts: [native.cgroupdriversystemd], log-driver: json-file, log-opts: { max-size: 100m }, storage-driver: overlay2 }重启 Dockersudo systemctl daemon-reload sudo systemctl restart docker说起这个 cgroupfs 的坑我当初第一次用 Rancher 搭集群时有一台节点反复出现 kubelet 报错看日志发现是 kubelet 与容器运行时 cgroup 驱动不一致把 daemon.json 改完重启之后立马就好了。所以这个配置最好在装完 Docker 后立刻改掉不要等集群报错再来查。2.5 端口提前打开Rancher Server 对外要开 80 和 443自定义集群节点之间要开放以下端口6443kube-apiserver 端口所有节点访问2379etcd 客户端通信2380etcd 集群成员通信8472VXLAN 网络插件封装通信9099Calico 的 felix 健康检查10250kubelet 指标与 exec 端口30000-32767NodePort 服务端口段如果你在云主机上还要注意安全组和防火墙两层都得放行Rancher 节点注册失败的原因里端口不通排第一位。3. 部署 Rancher Server3.1 单节点 Rancher Server 快速启动Rancher Server 自身本身就是一个 K8s 应用但最轻量的部署方式是单机 Docker 容器跑起来。这种方式适合测试、开发、管控节点数量不多的环境。操作命令非常简单sudo docker run -d \ --name rancher \ --restartunless-stopped \ -p 80:80 \ -p 443:443 \ --privileged \ -v /opt/rancher:/var/lib/rancher \ rancher/rancher:v2.9.3这里说明几个参数的含义--privileged是 Rancher 容器内部需要管理 Docker 套接字、创建 iptables 规则等权限不加容易起不来。数据目录挂载在/opt/rancher这样容器重建后数据不丢。端口映射 80 和 443访问时直接https://服务器IP即可。启动后先用docker logs -f rancher观察日志看到类似“Rancher UI is now available on”之类的输出就说明起来了。首次访问会强制要求设置管理员密码密码强度要求不低建议直接生成一个强密码记在密码管理器里。3.2 高可用 Rancher Server 的正规做法单机 Docker 方式跑 Rancher Server最大的问题是 Rancher Server 本身成了单点。Rancher 上管理的集群如果不多单点还能接受但如果管理着几十套集群Rancher Server 挂掉虽然不会直接让被管理集群下线但所有 Web UI、API、认证、日志功能都会中断这显然不可接受。生产环境建议把 Rancher Server 部署在一个独立的 K8s 集群上也就是用 Helm 把 Rancher 装进一套专门跑 Rancher 自身的高可用集群。大概流程是准备三个节点搭建一套 K8s 集群可以用 RKE2 或已有集群。创建 namespace一般叫cattle-system。配置 cert-manager 用于自动管理证书。通过 Helm 安装 Rancher设置 hostname。Helm 安装命令核心参数类似helm repo add rancher-latest https://releases.rancher.com/server-chart/latest helm install rancher rancher-latest/rancher \ --namespace cattle-system \ --create-namespace \ --set hostnamerancher.example.com \ --set bootstrapPasswordAdmin123456 \ --set replicas3这套方案里Rancher 的数据库默认是 etcd由底下的 K8s 集群管。备份思路就是备份 Rancher K8s 集群的 etcd 快照恢复时会比较顺。3.3 设置域名与证书Rancher UI 默认是用自签名证书浏览器会一直警告自己开发测试也就忍了但团队使用一定要配置正式证书。如果你已经申请到证书文件在首次初始化 Rancher 的时候会有一个页面让你选择证书可以选择“已有证书并上传”把 cert 和 key 填进去。如果你暂时没有证书也可以先让 Rancher 自签跑起来后面通过 UI 里的编辑设置换证书只是换了之后所有 agent 和 kubectl 的 kubeconfig 里的证书信息会变化已接入的节点需要重新拉取配置。我踩过这个坑所以建议如果是正式环境第一步就配好域名和证书别临时自签顶着。4. 在 Rancher 中创建第一个 K8s 集群4.1 新建自定义集群浏览器打开 Rancher UI登录后进入全局视角点击“创建集群”在集群类型里选择“自定义”这是最常用的一种方式。集群名称我建议用业务或环境命名比如prod-app、staging-cluster不要用node1-node2这种毫无语义的名字。Kubernetes 版本选择上Rancher 会默认列出一批兼容版本选择官方支持周期内的稳定版本即可当前可能默认就是 v1.28 或 v1.29 系列。网络插件这一步很关键。Rancher 支持的默认选项有 Calico、Flannel、Canal、Cilium 等。插件网络模式适合场景备注FlannelVXLAN/主机网关轻量、简单功能少不支持 NetworkPolicyCalicoBGP/VXLAN生产首选之一支持 NetworkPolicy性能均衡CiliumeBPF追求高性能和可观测性对内核版本要求较高我默认选 Calico。它既能满足多数生产环境的安全策略需求部署也成熟遇到问题资料很多三节点的集群完全跑得动。4.2 节点注册命令生成与执行集群创建好后Rancher 会生成一段节点注册命令看起来像是长串curl ... | sh。它其实是在节点上下载并运行一个 rancher-agent 容器然后 agent 会反过来引导节点上的 kubelet、kube-proxy 等组件。在执行注册命令前先在 Rancher UI 中勾选节点的角色。如果三台机器都要承担所有角色那就三台机器都同时勾选etcd、controlplane、worker。如果你有六台机器可以三台只勾 etcdcontrolplane三台只勾 worker。实际操作时我会采用“先加 etcd/controlplane 节点再加 worker 节点”的顺序。这样控制面先稳定下来再加业务容量过程中可观测性更好。曾经我一次把六台机器全勾上一起注册结果节点同时启动网络插件还没装好部分节点的 Pod 一直 ContainerCreating排查起来比较乱。注册命令在节点上执行时需要等它跑完。看到类似 “Rancher agent is installed” 的日志后回到 UI 刷新节点列表每个节点会经历provisioning → waiting → active的过程时间取决于下载镜像和初始化组件的速度三节点一般五到十分钟。4.3 配置节点标签与污点节点加入集群后趁创建初期给节点打标签和污点是明智的。标签用于业务调度选择比如给某台 worker 打成disktypessd部署 Pod 时就可以通过 nodeSelector 把高 IO 业务固定到它上面。污点机制则是反向排斥。比如你不要让普通业务调度到 controlplane 节点上就给 controlplane 节点打污点kubectl taint nodes node-1 node-role.kubernetes.io/controlplane:NoSchedule打上污点后除非 Pod 声明了对应的容忍否则无法调度到该节点。这样能保证控制面资源不被业务抢占生产环境强烈建议执行这一步。我建议在初始化节点时就把这些规则理清不要等集群跑了几个月后再加污点因为有些已经跑起来的 Pod 不会自动被排斥必须手动删除重建才会重新调度。5. 集群验证与部署首个应用5.1 Rancher UI 检查集群状态节点全部 Active 后点击集群名称进入集群管理页。第一步看左上角的集群状态正常显示应该是绿色 Active。左边栏的节点列表里每台节点 status 都是 Active。然后看“工作负载”页默认 namespace 下面应该已经有cattle-system等 Rancher 自建组件在跑。这些 Pod 的状态都是 Running 或 Completed如果有一直 CrashLoopBackOff 的先看是不是网络插件没起来。也可以点开“仪表盘”页看 CPU、内存、Pod 等指标如果 Rancher 正好装了监控插件这里能直接看到实时的趋势图对新手来说是很好的观测入口。5.2 本地 kubectl 接入集群Rancher UI 虽然是图形界面但很多操作还是用 kubectl 更高效。在集群详情页右上角点“Kubeconfig 文件”会展示一段 kubeconfig 内容里面包含 API Server 地址和证书信息。在本地保存为config文件即可或者直接下载下来放到~/.kube/config。验证没障碍之后以后工作流就变成kubectl get nodes查节点健康kubectl logs -f看 Pod 日志把 UI 当监控和审批入口命令行作为日常操作主力两者结合。5.3 部署一个测试应用为了确认集群完整可用我习惯部署一个带 Service 的简单应用。比如用 UI 里的工作负载页面选择“Deployment”填写名称和镜像比如nginx:1.27副本数设 2。部署完成后进入“服务”页面创建一个 NodePort 或 LoadBalancer 类型的 Service把容器端口 80 暴露出来。等 Service 创建好后就能通过https://任意节点IP:NodePort端口访问 Nginx 的欢迎页了。这个流程如果走通了说明集群的调度、网络、路由都正常后面再上线真实业务就心里有底了。注意访问端口需要在前面 2.5 节提到的安全组里同样放行否则页面打不开。6. 日常运维与高可用实践6.1 备份 Rancher 管理的集群数据K8s 集群最重要的数据是 etcd。Rancher 的 UI 里其实可以直接做 etcd 快照在集群详情页的“工具 → 备份”下面可以设置定期快照也可以手动创建。快照会默认保存在 Rancher 所在的地方如果是自定义集群快照存在对应 etcd 节点的本地磁盘上。除此之外Rancher 本身还有一套专门的备份 CRD用来备份 Rancher 的资源对象包括全局配置、集群定义、RBAC 策略等。如果是生产环境建议两样都做etcd 快照由 Rancher 定时执行Rancher 数据库备份用官方提供的备份应用如 Backup/Restore Operator并放到对象存储或异地存储中。几次实际恢复操作下来我深刻体会到备份不可怕怕的是没人测试恢复流程。建议每三个月至少做一次恢复演练把一个模拟集群从快照里拉起来确认关键业务能恢复再删掉。6.2 升级 Rancher 与集群版本升级路径分为两层Rancher Server 升级和 Kubernetes 集群升级。对于 Docker 单机部署的 Rancher升级方式是停止旧容器拉取新版镜像用同样的参数重新跑一个新容器数据目录保持不变。注意升级前一定先备份/opt/rancher目录升级失败时还能回退。对于 Kubernetes 集群Rancher 提供了“编辑集群 → 升级”入口可以选择目标 K8s 版本。升级时 Rancher 会先升级 controlplane 节点再逐个升级 worker 节点期间部分节点会被置为不可调度。这个过程比较长建议在业务低峰期做且先升级一个非核心集群试验确认没问题再动生产集群。6.3 监控告警建议Rancher 内置了一个监控功能可以按项目安装监控栈版本通常包括 Prometheus 和 Grafana。安装后能看到节点的 CPU、内存、磁盘 IO、网络流量以及 Pod 的资源使用。我要说的是告警规则一定要早配别等出了事故再配。我现在每套集群至少配三类告警节点 CPU 5 分钟持续超过 80%、磁盘根分区使用率超过 85%、Pod 重启次数 10 分钟内超过 5 次。这三个条件覆盖了大多数常见故障触发时通过邮件或 Webhook发出来比事后看监控面板强太多。7. 常见问题与排查技巧7.1 节点注册后一直处于 waiting 状态这类问题出现频率最高。先到节点上执行docker ps看 rancher-agent 容器是否在运行如果容器一直在重启查看日志sudo docker logs rancher-agent --tail 200常见原因之一是端口不通特别是节点到 Rancher Server 的 443 端口不通。可以用nc -vz RancherServerIP 443验证。另一个高频原因是节点上残留了旧集群的配置需要清理/etc/kubernetes和 var 下的相关目录再重新注册。7.2 kubelet 报错 cgroup driver 不匹配报错信息通常类似failed to run Kubelet: misconfiguration: kubelet cgroup driver: systemd is different from docker cgroup driver: cgroupfs。解决思路非常直接修改 Docker 配置让 cgroup driver 变成 systemd就是我前面 2.4 节写的 daemon.json修改后systemctl restart docker。改完之后最好把该节点从集群中删除重新执行注册命令。如果只是改了 Docker 但 kubelet 没重新初始化有时还是报旧状态。7.3 Calico 或 Cilium 的 Pod 一直 CrashLoopBackOff网络插件安装失败通常是因为kubectl get pods -n kube-system里网络组件的 Pod 处于 CrashLoopBackOff。先看日志多数原因是 IP 冲突、主机名解析失败或底层内核模块不全。Calico 对网络接口命名有要求如果主机多处网卡且都配置了 IP可能选错网卡导致网段冲突。解决办法是设置IP_AUTODETECTION_METHODfirst-found或者明确指定网卡名。Cilium 则要求内核 5.10 以上CentOS 7 的老内核跑起来很挣扎所以新集群我推荐直接用 Ubuntu 22.04 并确保内核较新。7.4 Rancher Server 自身失联如果 Rancher UI 打不开先看 Rancher 容器状态和日志。多半是磁盘空间满了导致容器写入失败或者数据中心目录权限被改坏了。不要马上删容器重建先执行df -h查磁盘、docker logs查输出再决定动作。如果 Rancher 的数据库损坏而之前又没有备份恢复起来会非常痛苦。所以我反复强调Rancher Server 的高可用部署和备份方案应该在集群搭建当天就规划好而不是等出了问题再想。8. 最后一点经验用 Rancher 搭 K8s真正顺手的姿势是把它当“控制平面面板”而不是“创建集群工具”。你可以在裸机或云主机上先把节点初始化好通过 Rancher 把它们编排成一个集群然后用它的管理面持续运营。相比纯 kubeadmRancher 能帮你把 RBAC、项目隔离、监控、备份这些日常操作从“命令行脚本堆”变成“图形界面配置”这对小团队来说节省的时间不是一点半点。我个人实测最舒服的搭配是Ubuntu 22.04 Docker 24 Rancher v2.9 Calico。这套组合踩坑最少资料最多出了问题几行命令就能查清楚。以后无论你是要做生产集群还是想带新人练手 K8s都可以从这套流程起步先把集群跑起来再慢慢把监控、告警、备份补齐这才是最稳妥的路径。
有句话得放在前面用 Rancher 搭 K8s 集群和用裸 kubeadm 完全是两种体验。Rancher 最大的价值不是帮你把集群拉起来而是把集群拉起来之后那堆“维护和运营”的活比如多集群管理、RBAC、监控告警、应用商店、日志中心这些东西如果全靠自建工作量直接翻倍。这篇文章我结合自己操作过的完整流程从环境准备、Rancher Server 部署、创建自定义集群、验证应用到踩坑排查原原本本写出来适合刚接触 Rancher 的朋友照着做也适合已经用裸 K8s、想引入 Rancher 做统一管理的团队参考。1. 为什么用 Rancher 而不是直接用 kubeadm1.1 Rancher 解决的是“集群运营”问题先聊一个很实际的问题如果你的目标只是“本地跑一个单节点 K8s 练手”那用 kubeadm 就够了甚至用 kind 或 minikube 更快。但如果你要的是“给团队一套能持续用的生产级 K8s 环境”那么圈层就不一样了。Rancher 解决的核心痛点有三个第一装好集群后的日常管理界面比如部署工作负载、看 Pod 状态、管理 ConfigMap/Secret图形界面比 kubectl 对非核心技术成员友好得多第二统一认证和授权对接企业账号体系权限划分、多团队隔离这种东西手写 RBAC 非常费劲第三集群级运维包括备份恢复、升级、监控告警、日志收集。也就是说Rancher 相当于给 K8s 套了一层“运营层”。它本身不是一个独立的容器编排系统而是把 K8s 集群包装成可以集中管理的对象。理解了这层关系你就知道为什么很多团队搭好集群后还要再装 Rancher——不是为了“搭建”这个动作而是为了后续每天都要做的“维护”。1.2 Rancher 创建集群的几种方式怎么选Rancher 创建集群一共有三种大路径选错容易走弯路先说清楚区别。第一种叫“自定义集群”指的是你自己准备好几台裸服务器物理机或虚拟机然后在 Rancher 界面里填节点信息或生成注册命令让这些节点加入 Rancher 管控的控制面。Rancher 会帮你在这些节点上安装各组件包括 etcd、kube-apiserver、kube-controller-manager、kube-scheduler、kubelet 和网络插件。这种方式最灵活也是我们今天的主线。第二种叫“导入集群”适用于你已经有一个跑起来的 K8s 集群想把它托管到 Rancher 里。导入不会对现有集群做破坏性改动只是装一个 agent 让 Rancher 可以连上它。如果你已经有裸 kubeadm 搭好的集群想马上获得 Rancher 的管理界面这条路径最快半个小时能搞定。第三种是驱动云厂商 API 自动创建节点Rancher 直接调用云服务商接口开虚拟机、装系统、加入集群。这种方式自动化程度最高但需要提前在 Rancher 里配置云厂商访问凭据而且生产环境我一般不建议在 Rancher 里直接管云主机资源安全和计量边界容易混乱。1.3 版本与 license 的现实考量Rancher 目前大致分两个家族旧一点的 v2.5/v2.6/v2.7 系列和新版 v2.8、v2.9、v2.10 系列。注意一点Rancher 的免费版功能其实已经覆盖了大多数中小团队的需求比如多集群管理、RBAC、项目空间、应用商店。对于一些高级功能比如某些全球级的多集群编排特性需要授权但学习环境或中小规模生产环境通常用不到。版本选择上我会优先用当前官方仍在活跃维护的 v2.7 以上版本。不要一上来就装刚发布的大版本除非你看了 release notes 确认没有影响使用的回归问题。我实际操作中见过一次 Rancher 升级到新版本后集群详情页的监控图表出现兼容问题的案例所以稳定版本用起来其实最舒服。2. 环境准备与前置条件2.1 节点规划与角色分配Rancher 创建自定义集群时节点至少要承担三种角色之一etcd、controlplane、worker。这三类角色有明确的分工逻辑etcd负责保存集群所有状态数据。它是整个集群的“数据库”如果它挂了集群只能读不能写严重时直接不可用。etcd 节点需要奇数个最少 1 个但生产环境至少 3 个。controlplane跑 kube-apiserver、controller-manager、scheduler是集群的“大脑”处理所有 API 请求和调度决策。worker跑业务负载是“手脚”。我的建议是学习环境或者资源紧张的小团队3 台机器每台同时承担 etcd controlplane worker 三个角色组成一个三节点集群这种部署最简单也能满足一般业务。如果资源允许最好把 etcd 和 controlplane 放在一起worker 单独拆出来这样业务应用的波动不会直接影响控制面稳定性。千万别只装一个单节点然后把 etcd、controlplane、worker 都塞进去——研发环境玩玩可以生产环境千万别这么干。2.2 服务器配置建议以生产环境标准看controlplane 节点建议至少 2 核 4Getcd 节点建议至少 4 核 8G 或更高磁盘必须是 SSDIOPS 不要低于 1000。worker 节点根据业务定一般起步 4 核 8G数据盘独立挂载。操作系统方面CentOS 7.9、Rocky Linux 8/9、Ubuntu 20.04/22.04 我都跑过都是没问题的。我这里以 Ubuntu 22.04 为例因为它的内核和 Docker 配合更顺滑软件源依赖也更干净。每个节点需要保证主机名唯一不要出现两个节点都叫 node1 的情况。匿名用户核心坑/etc/hosts 里必须写好每个节点的 IP 和主机名映射否则 etcd 成员之间通信经常出现证书域名不匹配的诡异问题。2.3 系统初始化配置在加入 Rancher 之前所有节点要做统一初始化。第一步是关闭 swapK8s 的 kubelet 默认要求 swap 关闭不关的话 kubelet 可能启动失败或行为异常。在 Ubuntu 下执行sudo swapoff -a sudo sed -i /swap/s/^/#/ /etc/fstab第二步是加载内核模块并打开流量转发。cat EOF | sudo tee /etc/modules-load.d/k8s.conf br_netfilter ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack EOF sudo modprobe br_netfilter sudo modprobe ip_vs然后写入内核参数cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sudo sysctl --system第三步是统一时间同步。不校准时间的话证书校验、日志时间戳、etcd 选举都会出问题。sudo apt update sudo apt install -y chrony sudo systemctl enable --now chrony2.4 Docker 安装与 cgroup 驱动Rancher 自定义集群在节点上主要通过 Docker 运行组件所以每个节点都要装 Docker。版本建议使用当前社区仍在维护的版本比如 24.0 或 25.0 之后的稳定版本。安装 Docker 后有一个关键配置cgroup driver 要改成 systemd。原本 Docker 默认使用的是 cgroupfs而 K8s 官方推荐 systemd两者混用会导致节点资源统计数据不一致底层容器容易被误杀。创建/etc/docker/daemon.json{ exec-opts: [native.cgroupdriversystemd], log-driver: json-file, log-opts: { max-size: 100m }, storage-driver: overlay2 }重启 Dockersudo systemctl daemon-reload sudo systemctl restart docker说起这个 cgroupfs 的坑我当初第一次用 Rancher 搭集群时有一台节点反复出现 kubelet 报错看日志发现是 kubelet 与容器运行时 cgroup 驱动不一致把 daemon.json 改完重启之后立马就好了。所以这个配置最好在装完 Docker 后立刻改掉不要等集群报错再来查。2.5 端口提前打开Rancher Server 对外要开 80 和 443自定义集群节点之间要开放以下端口6443kube-apiserver 端口所有节点访问2379etcd 客户端通信2380etcd 集群成员通信8472VXLAN 网络插件封装通信9099Calico 的 felix 健康检查10250kubelet 指标与 exec 端口30000-32767NodePort 服务端口段如果你在云主机上还要注意安全组和防火墙两层都得放行Rancher 节点注册失败的原因里端口不通排第一位。3. 部署 Rancher Server3.1 单节点 Rancher Server 快速启动Rancher Server 自身本身就是一个 K8s 应用但最轻量的部署方式是单机 Docker 容器跑起来。这种方式适合测试、开发、管控节点数量不多的环境。操作命令非常简单sudo docker run -d \ --name rancher \ --restartunless-stopped \ -p 80:80 \ -p 443:443 \ --privileged \ -v /opt/rancher:/var/lib/rancher \ rancher/rancher:v2.9.3这里说明几个参数的含义--privileged是 Rancher 容器内部需要管理 Docker 套接字、创建 iptables 规则等权限不加容易起不来。数据目录挂载在/opt/rancher这样容器重建后数据不丢。端口映射 80 和 443访问时直接https://服务器IP即可。启动后先用docker logs -f rancher观察日志看到类似“Rancher UI is now available on”之类的输出就说明起来了。首次访问会强制要求设置管理员密码密码强度要求不低建议直接生成一个强密码记在密码管理器里。3.2 高可用 Rancher Server 的正规做法单机 Docker 方式跑 Rancher Server最大的问题是 Rancher Server 本身成了单点。Rancher 上管理的集群如果不多单点还能接受但如果管理着几十套集群Rancher Server 挂掉虽然不会直接让被管理集群下线但所有 Web UI、API、认证、日志功能都会中断这显然不可接受。生产环境建议把 Rancher Server 部署在一个独立的 K8s 集群上也就是用 Helm 把 Rancher 装进一套专门跑 Rancher 自身的高可用集群。大概流程是准备三个节点搭建一套 K8s 集群可以用 RKE2 或已有集群。创建 namespace一般叫cattle-system。配置 cert-manager 用于自动管理证书。通过 Helm 安装 Rancher设置 hostname。Helm 安装命令核心参数类似helm repo add rancher-latest https://releases.rancher.com/server-chart/latest helm install rancher rancher-latest/rancher \ --namespace cattle-system \ --create-namespace \ --set hostnamerancher.example.com \ --set bootstrapPasswordAdmin123456 \ --set replicas3这套方案里Rancher 的数据库默认是 etcd由底下的 K8s 集群管。备份思路就是备份 Rancher K8s 集群的 etcd 快照恢复时会比较顺。3.3 设置域名与证书Rancher UI 默认是用自签名证书浏览器会一直警告自己开发测试也就忍了但团队使用一定要配置正式证书。如果你已经申请到证书文件在首次初始化 Rancher 的时候会有一个页面让你选择证书可以选择“已有证书并上传”把 cert 和 key 填进去。如果你暂时没有证书也可以先让 Rancher 自签跑起来后面通过 UI 里的编辑设置换证书只是换了之后所有 agent 和 kubectl 的 kubeconfig 里的证书信息会变化已接入的节点需要重新拉取配置。我踩过这个坑所以建议如果是正式环境第一步就配好域名和证书别临时自签顶着。4. 在 Rancher 中创建第一个 K8s 集群4.1 新建自定义集群浏览器打开 Rancher UI登录后进入全局视角点击“创建集群”在集群类型里选择“自定义”这是最常用的一种方式。集群名称我建议用业务或环境命名比如prod-app、staging-cluster不要用node1-node2这种毫无语义的名字。Kubernetes 版本选择上Rancher 会默认列出一批兼容版本选择官方支持周期内的稳定版本即可当前可能默认就是 v1.28 或 v1.29 系列。网络插件这一步很关键。Rancher 支持的默认选项有 Calico、Flannel、Canal、Cilium 等。插件网络模式适合场景备注FlannelVXLAN/主机网关轻量、简单功能少不支持 NetworkPolicyCalicoBGP/VXLAN生产首选之一支持 NetworkPolicy性能均衡CiliumeBPF追求高性能和可观测性对内核版本要求较高我默认选 Calico。它既能满足多数生产环境的安全策略需求部署也成熟遇到问题资料很多三节点的集群完全跑得动。4.2 节点注册命令生成与执行集群创建好后Rancher 会生成一段节点注册命令看起来像是长串curl ... | sh。它其实是在节点上下载并运行一个 rancher-agent 容器然后 agent 会反过来引导节点上的 kubelet、kube-proxy 等组件。在执行注册命令前先在 Rancher UI 中勾选节点的角色。如果三台机器都要承担所有角色那就三台机器都同时勾选etcd、controlplane、worker。如果你有六台机器可以三台只勾 etcdcontrolplane三台只勾 worker。实际操作时我会采用“先加 etcd/controlplane 节点再加 worker 节点”的顺序。这样控制面先稳定下来再加业务容量过程中可观测性更好。曾经我一次把六台机器全勾上一起注册结果节点同时启动网络插件还没装好部分节点的 Pod 一直 ContainerCreating排查起来比较乱。注册命令在节点上执行时需要等它跑完。看到类似 “Rancher agent is installed” 的日志后回到 UI 刷新节点列表每个节点会经历provisioning → waiting → active的过程时间取决于下载镜像和初始化组件的速度三节点一般五到十分钟。4.3 配置节点标签与污点节点加入集群后趁创建初期给节点打标签和污点是明智的。标签用于业务调度选择比如给某台 worker 打成disktypessd部署 Pod 时就可以通过 nodeSelector 把高 IO 业务固定到它上面。污点机制则是反向排斥。比如你不要让普通业务调度到 controlplane 节点上就给 controlplane 节点打污点kubectl taint nodes node-1 node-role.kubernetes.io/controlplane:NoSchedule打上污点后除非 Pod 声明了对应的容忍否则无法调度到该节点。这样能保证控制面资源不被业务抢占生产环境强烈建议执行这一步。我建议在初始化节点时就把这些规则理清不要等集群跑了几个月后再加污点因为有些已经跑起来的 Pod 不会自动被排斥必须手动删除重建才会重新调度。5. 集群验证与部署首个应用5.1 Rancher UI 检查集群状态节点全部 Active 后点击集群名称进入集群管理页。第一步看左上角的集群状态正常显示应该是绿色 Active。左边栏的节点列表里每台节点 status 都是 Active。然后看“工作负载”页默认 namespace 下面应该已经有cattle-system等 Rancher 自建组件在跑。这些 Pod 的状态都是 Running 或 Completed如果有一直 CrashLoopBackOff 的先看是不是网络插件没起来。也可以点开“仪表盘”页看 CPU、内存、Pod 等指标如果 Rancher 正好装了监控插件这里能直接看到实时的趋势图对新手来说是很好的观测入口。5.2 本地 kubectl 接入集群Rancher UI 虽然是图形界面但很多操作还是用 kubectl 更高效。在集群详情页右上角点“Kubeconfig 文件”会展示一段 kubeconfig 内容里面包含 API Server 地址和证书信息。在本地保存为config文件即可或者直接下载下来放到~/.kube/config。验证没障碍之后以后工作流就变成kubectl get nodes查节点健康kubectl logs -f看 Pod 日志把 UI 当监控和审批入口命令行作为日常操作主力两者结合。5.3 部署一个测试应用为了确认集群完整可用我习惯部署一个带 Service 的简单应用。比如用 UI 里的工作负载页面选择“Deployment”填写名称和镜像比如nginx:1.27副本数设 2。部署完成后进入“服务”页面创建一个 NodePort 或 LoadBalancer 类型的 Service把容器端口 80 暴露出来。等 Service 创建好后就能通过https://任意节点IP:NodePort端口访问 Nginx 的欢迎页了。这个流程如果走通了说明集群的调度、网络、路由都正常后面再上线真实业务就心里有底了。注意访问端口需要在前面 2.5 节提到的安全组里同样放行否则页面打不开。6. 日常运维与高可用实践6.1 备份 Rancher 管理的集群数据K8s 集群最重要的数据是 etcd。Rancher 的 UI 里其实可以直接做 etcd 快照在集群详情页的“工具 → 备份”下面可以设置定期快照也可以手动创建。快照会默认保存在 Rancher 所在的地方如果是自定义集群快照存在对应 etcd 节点的本地磁盘上。除此之外Rancher 本身还有一套专门的备份 CRD用来备份 Rancher 的资源对象包括全局配置、集群定义、RBAC 策略等。如果是生产环境建议两样都做etcd 快照由 Rancher 定时执行Rancher 数据库备份用官方提供的备份应用如 Backup/Restore Operator并放到对象存储或异地存储中。几次实际恢复操作下来我深刻体会到备份不可怕怕的是没人测试恢复流程。建议每三个月至少做一次恢复演练把一个模拟集群从快照里拉起来确认关键业务能恢复再删掉。6.2 升级 Rancher 与集群版本升级路径分为两层Rancher Server 升级和 Kubernetes 集群升级。对于 Docker 单机部署的 Rancher升级方式是停止旧容器拉取新版镜像用同样的参数重新跑一个新容器数据目录保持不变。注意升级前一定先备份/opt/rancher目录升级失败时还能回退。对于 Kubernetes 集群Rancher 提供了“编辑集群 → 升级”入口可以选择目标 K8s 版本。升级时 Rancher 会先升级 controlplane 节点再逐个升级 worker 节点期间部分节点会被置为不可调度。这个过程比较长建议在业务低峰期做且先升级一个非核心集群试验确认没问题再动生产集群。6.3 监控告警建议Rancher 内置了一个监控功能可以按项目安装监控栈版本通常包括 Prometheus 和 Grafana。安装后能看到节点的 CPU、内存、磁盘 IO、网络流量以及 Pod 的资源使用。我要说的是告警规则一定要早配别等出了事故再配。我现在每套集群至少配三类告警节点 CPU 5 分钟持续超过 80%、磁盘根分区使用率超过 85%、Pod 重启次数 10 分钟内超过 5 次。这三个条件覆盖了大多数常见故障触发时通过邮件或 Webhook发出来比事后看监控面板强太多。7. 常见问题与排查技巧7.1 节点注册后一直处于 waiting 状态这类问题出现频率最高。先到节点上执行docker ps看 rancher-agent 容器是否在运行如果容器一直在重启查看日志sudo docker logs rancher-agent --tail 200常见原因之一是端口不通特别是节点到 Rancher Server 的 443 端口不通。可以用nc -vz RancherServerIP 443验证。另一个高频原因是节点上残留了旧集群的配置需要清理/etc/kubernetes和 var 下的相关目录再重新注册。7.2 kubelet 报错 cgroup driver 不匹配报错信息通常类似failed to run Kubelet: misconfiguration: kubelet cgroup driver: systemd is different from docker cgroup driver: cgroupfs。解决思路非常直接修改 Docker 配置让 cgroup driver 变成 systemd就是我前面 2.4 节写的 daemon.json修改后systemctl restart docker。改完之后最好把该节点从集群中删除重新执行注册命令。如果只是改了 Docker 但 kubelet 没重新初始化有时还是报旧状态。7.3 Calico 或 Cilium 的 Pod 一直 CrashLoopBackOff网络插件安装失败通常是因为kubectl get pods -n kube-system里网络组件的 Pod 处于 CrashLoopBackOff。先看日志多数原因是 IP 冲突、主机名解析失败或底层内核模块不全。Calico 对网络接口命名有要求如果主机多处网卡且都配置了 IP可能选错网卡导致网段冲突。解决办法是设置IP_AUTODETECTION_METHODfirst-found或者明确指定网卡名。Cilium 则要求内核 5.10 以上CentOS 7 的老内核跑起来很挣扎所以新集群我推荐直接用 Ubuntu 22.04 并确保内核较新。7.4 Rancher Server 自身失联如果 Rancher UI 打不开先看 Rancher 容器状态和日志。多半是磁盘空间满了导致容器写入失败或者数据中心目录权限被改坏了。不要马上删容器重建先执行df -h查磁盘、docker logs查输出再决定动作。如果 Rancher 的数据库损坏而之前又没有备份恢复起来会非常痛苦。所以我反复强调Rancher Server 的高可用部署和备份方案应该在集群搭建当天就规划好而不是等出了问题再想。8. 最后一点经验用 Rancher 搭 K8s真正顺手的姿势是把它当“控制平面面板”而不是“创建集群工具”。你可以在裸机或云主机上先把节点初始化好通过 Rancher 把它们编排成一个集群然后用它的管理面持续运营。相比纯 kubeadmRancher 能帮你把 RBAC、项目隔离、监控、备份这些日常操作从“命令行脚本堆”变成“图形界面配置”这对小团队来说节省的时间不是一点半点。我个人实测最舒服的搭配是Ubuntu 22.04 Docker 24 Rancher v2.9 Calico。这套组合踩坑最少资料最多出了问题几行命令就能查清楚。以后无论你是要做生产集群还是想带新人练手 K8s都可以从这套流程起步先把集群跑起来再慢慢把监控、告警、备份补齐这才是最稳妥的路径。
优化)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
