这阵子我把线上好几套自运维的 Kubernetes 集群从 kubeadm 逐步迁到了 RKE2同时统一接到 Rancher 做纳管。整个过程不算轻松踩了节点注册失败、etcd 频繁切主、证书过期把 API Server 拖垮、网络插件状态诡异等不少坑。今天这篇就把 RKE2 线上集群从搭建到深度排错的完整过程整理出来尤其是那些文档里不会写、但生产环境迟早要面对的细节尽量都讲透。如果你正打算把 RKE2 引入公司生产环境或者已经上了 RKE2 但在 Rancher 纳管、节点调度、集群故障转移这几个环节被搞到头疼那么这篇内容应该能帮你少走不少弯路。文章会从为什么选 RKE2 讲起一路覆盖架构规划、Server/Agent 配置、Rancher 高可用接入再到常见的故障场景和排查思路尽量做到每一步都能照着落地。1. 选型逻辑与架构决策为什么是 RKE21.1 RKE2 的定位与核心优势先说说 RKE2 到底是什么。它是 Rancher 主推的新一代 Kubernetes 发行版官方定位叫“安全加固版 Kubernetes”。与 kubeadm 拼装出来的集群相比RKE2 最大的优势在于把 etcd、kubelet、kube-proxy、containerd、网络插件这些组件全部打包并做了合理默认配置安装工具链集成在一条命令里出来的集群几乎是可直接面向生产的。我选择它还有一个很实际的原因它和 Rancher 同出 SUSE 一家集群纳管、认证接入、升级策略完全自洽。用 kubeadm 搭的集群要想接入 Rancher不是不行但你需要单独处理 kubeconfig 权限、cluster-admin 绑定、cattle-cluster-agent 的连通性等等Rancher 对 RKE2 有天然的“原生支持”接入过程中少了很多适配问题。另一个容易被忽略的优势是 RKE2 使用 containerd 而非 Docker插件体系更干净和 CRI 标准对齐更彻底。对于线上集群来说镜像管理、运行时升级、安全扫描都简单不少不像 Docker 时代还要额外维护 dockerd 和 docker-shim 这层兼容逻辑。RKE2 还有一个点我非常喜欢它内置了 etcd 快照备份能力支持定时备份到本地或者 S3 兼容存储。生产环境要做备份恢复演练直接通过rke2 etcd-snapshot命令和配置文件就能搞定不需要额外引入 velero 之外的复杂方案来保护 etcd 数据。提示RKE2 和 K3s 容易搞混。K3s 更多面向边缘、轻量场景压缩了组件规模适合资源受限的机器。RKE2 则是面向数据中心级生产环境的发行版虽然命令风格类似但在安全合规、CNCF 一致性、数据面稳定性上完全不是一个量级。1.2 线上集群的拓扑规划拓扑规划是搭建前最重要的一步很多线上问题归根结底是这一层没想清楚。我这边线上环境采用的标准拓扑是3 个 Server 节点组成 Control Plane 高可用etcd 与 API Server 同节点部署3 个或更多 Worker 节点承载业务负载业务流量入口用云厂商的 LB 或者自建的 Nginx ingress controller。Server 节点数量为什么稳定取 3因为 RKE2 内置的 etcd 需要多数派才能选出 leader。3 节点能容忍 1 台故障5 节点能容忍 2 台故障再往上加边际收益就明显下降。很多团队一上来就搭 5 个 Server 节点实际上中小规模业务 3 个 Server 节点性价比最高etcd 写入性能也不会因为节点过多而受到拖累。Worker 节点规划要关注的是分组和污点。我习惯把需要公网入口能力的节点单独打上node-role.kubernetes.io/ingresstrue:NoSchedule只允许 ingress-controller 一类的负载调度过去避免业务的普通 Pod 把入口节点资源吃满导致流量入口抖动。数据库、消息队列这类有状态组件则尽量固定调度到专用节点池防止集群调度器把 Pod 打散到不同节点上造成网络延迟和状态不一致。注意etcd 对磁盘延迟敏感如果条件允许Server 节点尽量使用 SSD 或高性能云盘。机械盘上跑 etcd 不是不能用但遇到频繁刷盘、fsync 变慢时etcd 会出现大量 leader 切换节点会反复进入投票状态整集群可用性直线下降。2. 从零搭建 RKE2 集群安装、配置与验证2.1 节点初始化与前置条件检查RKE2 对操作系统要求不高主流 Linux 发行版基本都能跑我这边用了 CentOS 7.9 和 Ubuntu 22.04 混部的环境。初始化阶段有几件事必须做对否则后续会频繁踩坑。第一主机名必须规范且互相能解析。etcd 对节点身份识别依赖 hostname如果节点的主机名重复或者解析列表里出现了无法使用的名称Server 节点间同步就会出问题。实践中我会把/etc/hosts里固定写入所有 Server 节点的内网 IP 和主机名映射同时确保hostnamectl set-hostname设置的主机名与 hosts 记录一致。第二内核参数要调整。RKE2 依赖 netfilter 和转发能力以下参数在搭建前建议配置cat EOF /etc/sysctl.conf net.ipv4.ip_forward1 net.bridge.bridge-nf-call-iptables1 net.bridge.bridge-nf-call-ip6tables1 vm.swappiness0 EOF sysctl -p其中net.bridge.bridge-nf-call-iptables如果不打开集群内 Pod 跨节点通信时kube-proxy 的 iptables 规则就不会作用于 bridge 流量导致 Service 访问异常、DNS 解析超时等隐蔽问题。第三关闭交换分区。Kubernetes 官方一直不建议在开启 swap 的环境下运行RKE2 在安装检查时也会对 swap 做校验。用swapoff -a关闭当前会话的交换分区同时在/etc/fstab中注释掉 swap 挂载行保证重启后也不会恢复。前置检查里还有一个容易漏的地方端口。Server 节点需要放通9345RKE2 注册端口、6443Kubernetes API Server、2379/2380etcd 通信、8472VXLAN、10250kubelet等。Agent 节点需要放通9345出方向、8472、10250。云环境下安全组如果不放行这些端口后面 Agent 加入时大概率卡在 “Waiting for node registration” 阶段。2.2 Server 节点安装与核心配置安装 RKE2 Server 非常简单执行官方脚本即可curl -sfL https://get.rke2.io | sh - systemctl enable rke2-server但生产环境不是装完就能用的配置文件/etc/rancher/rke2/config.yaml才是重点。下面是我线上环境的配置模板token: your-shared-cluster-token tls-san: - rke2-api.example.com - 10.0.10.11 - 10.0.10.12 - 10.0.10.13 etcd: snapshot-retention: 7 snapshot-schedule-cron: 0 */6 * * * disable-snapshots: false node-name: rke2-server-01 node-ip: 10.0.10.11token是整个集群通用的共享令牌所有 Server 和 Agent 加入时都必须携带这个 token。强烈建议用openssl rand -base64 32生成一个足够长的随机串不要用弱口令。tls-san是另一个关键项。RKE2 生成的 TLS 证书默认只包含节点自身的主机名和内网 IP如果你希望通过域名访问 API Server或者通过负载均衡器 IP 访问就必须把这些地址写进tls-san。很多人第一次 503、证书报错就是因为漏了这一步证书里没有 LB 的地址。etcd 快照配置建议直接写在 config.yaml 里而不是每次手动执行快照命令。生产环境我设置了每 6 小时一次快照保留最近 7 份。这样即使遇到数据损坏也能恢复到最多 6 小时前的状态。安装完成后通过以下命令验证 Server 状态systemctl status rke2-server /var/lib/rancher/rke2/bin/kubectl get nodes /var/lib/rancher/rke2/bin/kubectl get pods -A如果一切正常你会看到一个 Ready 状态的 Server 节点。这里注意 RKE2 的 kubectl 需要完整路径或者你可以在/etc/profile.d/里加一条环境变量export KUBECONFIG/etc/rancher/rke2/rke2.yaml再把/var/lib/rancher/rke2/bin加入 PATH。2.3 高可用扩展追加 Server 节点单节点 RKE2 只能算功能验证不叫高可用。要扩展成 3 节点 Control Plane在另外两台新机器上执行安装后需要将第一台 Server 的 token 写入它们各自的 config.yamltoken: your-shared-cluster-token server: https://rke2-server-01:9345 node-name: rke2-server-02 node-ip: 10.0.10.12 tls-san: - rke2-api.example.com - 10.0.10.11 - 10.0.10.12 - 10.0.10.13注意第二台和第三台 Server 的server字段要指向第一台 Server 的 9345 端口。RKE2 会自动将新 Server 加入 etcd 集群并以 worker 服务的方式注册到现有集群中。这个阶段最容易遇到的问题是server字段指向的地址证书不被信任因为配置中只写了 IP没有写入 tls-san。解决办法就是在追加节点前先把所有可能的 Server 地址和负载均衡地址都写入首台机器的 tls-san一次性规划好。追加 Server 节点的速度比想象中慢通常要等 2~3 分钟期间 kubelet 和 etcd 都在不断重试。可以通过以下命令观察 etcd 是否已同步/var/lib/rancher/rke2/bin/kubectl get etcd -A如果看到三台 Server 都出现在 etcd 成员列表中control plane 层面的高可用就算到位了。2.4 Agent 节点加入与分组Agent 节点安装时指定INSTALL_RKE2_TYPEagent配置文件更简单server: https://rke2-server-01:9345 token: your-shared-cluster-token node-name: rke2-worker-01 node-ip: 10.0.20.11 node-label: - node-role.kubernetes.io/workertrue - workload-typegeneral注意server字段这里指向的是 9345 端口不是 6443。9345 是 RKE2 自有的注册端口Agent 通过它获取 bootstrap 信息和加入令牌6443 则是正式 Kubernetes API 端口。Agent 节点如果想分组管理可以通过node-label打标签后面配合 Rancher 的节点池和 Pod 调度约束使用。比如我给通用的无状态业务打了workload-typegeneral给需要高性能磁盘的打了workload-typestorage发布业务时就可以通过 nodeSelector 或者节点亲和性精准控制调度目标。加入完成后用kubectl get nodes确认状态。如果节点一直处于 NotReady先别急着重装优先检查两个点一是节点的 kubelet 日志二是节点与 Server 之间的 10250 端口连通性。NotReady 的常见原因我会在后面的排错章节详细展开。3. 接入 Rancher高可用管控与集群纳管3.1 Rancher 版本怎么选才合理Rancher 版本选型是个让很多人纠结的问题。我的原则是选择与 RKE2 兼容矩阵明确匹配的稳定线不要盲目追新也不要死守老版本。像 Rancher 2.6、2.7、2.8、2.9 这几条版本线我都见过生产环境在跑各自对应的 Kubernetes 版本范围不同。具体操作时直接去 Rancher 官网查 Supported Versions 表格找到你正在用的 RKE2 小版本对应的 Rancher 版本区间然后取这条线里最新的 bugfix 版本。这比听别人说“某某版本最稳定”要靠谱得多因为每个团队的插件兼容性、网络环境、业务特性都不一样适合自己的版本线才是最好的。Rancher 2 的 UI 能力和集群管理 day-2 操作在近几个版本已经相当成熟。我实际体验下来的感受是RKE2 集群接入 Rancher 后几乎可以做到创建、升级、回滚、监控配置全流程可视化极大降低了团队维护成本。如果你团队里的人习惯用 Web 管理多套集群这个收益是很明显的。3.2 Rancher Server 高可用部署Rancher 自身也是一个容器化应用高可用部署建议直接跑在已有的 RKE2 集群上形成“嵌套”模式。我这边是把 Rancher 部署在一个单独的 RKE2 管理集群上业务集群再通过 Rancher 导入纳管这样即使某个业务集群挂了管理面的 Rancher 依然是可用的。部署可以用 Helm 完成核心步骤大概如下helm repo add rancher-latest https://releases.rancher.com/server-charts/latest kubectl create namespace cattle-system helm install rancher rancher-latest/rancher \ --namespace cattle-system \ --set hostnamerancher.example.com \ --set bootstrapPasswordadmin_password \ --set replicas3 \ --set ingress.tls.sourceletsEncrypthostname要设置为一个可解析的域名Rancher 和下游集群的 agent 通信都需要通过它。bootstrapPassword是初始化时一次性管理员密码首次登录后要立刻修改。Rancher 前端接入的下游集群需要能够回连 Rancher Server 的 WebSocket 端口默认是 443。如果你有多套集群分布在不同的 VPC 或地域要确保网络策略放行下游集群主动访问 Rancher Server 域名的 443 端口否则下游集群状态会一直停留在 “Pending” 或 “Disconnected”。3.3 将 RKE2 集群导入 Rancher导入已有 RKE2 集群是 Rancher 最常见的用法。在 Rancher UI 中进入 “Cluster Management” 页面选择 “Import Existing”下载导入的 YAML 文件然后在你目标集群的节点上执行kubectl apply -f import.yaml。Rancher 会自动在目标集群中部署 cattle-cluster-agent从而建立管控通道。实际操作中我遇到过一个典型的坑导入命令在 Console 里执行成功但 Rancher 端一直显示集群状态为 “Waiting”。这时候不要反复重复导入优先检查 cattle-cluster-agent 的 Pod 状态和日志kubectl get pods -n cattle-system -o wide kubectl logs -n cattle-system -l appcattle-cluster-agent --tail200日志里通常会出现两类信息一类是 TLS 握手失败说明 Rancher Server 的证书没有被 agent 信任另一类是连接超时说明网络无法回连 Rancher Server 的域名。针对前者确认Import YAML中写入的 server 地址与 Rancher 实际对外域名一致针对后者检查安全组与代理配置。导入完成后Rancher 会同步集群资源节点列表、工作负载、事件都会出现在 UI 里。这个阶段最好确认一下集群的auth模式因为 Rancher 默认会调整集群的认证方式避免后续 kubectl 权限出现异常。4. 深度排错线上 RKE2 集群典型故障实录4.1 节点 NotReady 与 kubelet 异常集群节点 NotReady 是出现频率最高的故障之一。先别急着删节点重建按照以下顺序排查。先看 kubelet 状态systemctl status kubelet journalctl -u kubelet --since10 minutes ago -f注意 RKE2 的 kubelet 不是以 systemd 单进程方式存在的它由 rke2-agent 或 rke2-server 拉起。想在节点上看到 kubelet 日志需要查/var/lib/rancher/rke2/logs/目录下对应服务的输出或者用journalctl -u rke2-server -u rke2-agent来跟踪。kubelet 无法启动的常见根因有两个容器运行时异常和 CNI 插件缺失。RKE2 内置 containerd 和 Canal/Cilium如果在启动前预留了--disable配置导致某个组件没有拉起kubelet 就会一直等待 sandbox 镜像而无法 Ready。检查 containerd 状态crictl --address /run/k8s.io/containerd/containerd.sock ps crictl --address /run/k8s.io/containerd/containerd.sock logs container-id注意 RKE2 的 containerd socket 路径与社区默认配置不同如果不指定--address会连接失败。另一个隐蔽原因是磁盘空间不足。kubelet 会定期做 eviction当节点磁盘使用率超过阈值节点会进入 pressure 状态如果持续恶化就会标记为 NotReady。用kubectl describe node node-name能直接看到 Condition 列表里的 DiskPressure这种问题清理/var/lib和/var/lib/rancher下的无用数据即可。4.2 etcd 异常与数据安全etcd 是 RKE2 集群的核心中的核心它一抖动整个集群都受影响。生产环境我遇到过最棘手的问题是磁盘 IO 延迟升高导致 etcd leader 频繁切换。现象是API Server 偶发超时、节点状态反复刷新、kubectl get nodes经常短暂报错但几秒后又恢复。排查方法journalctl -u rke2-server -f --since30 minutes ago | grep -i etcd如果看到大量etcdserver: request timed out或failed to send out heartbeat基本可以确定是磁盘 IO 延迟超时。RKE2 对 etcd 的性能数据采集会直接体现在 etcd server 的 slow 指标上。此时优先检查节点的磁盘 IO 使用情况用iostat -x 1看%util和await如果 await 持续超过 20ms就要考虑将 etcd 数据目录迁移到更高速的存储上。RKE2 的 etcd 数据目录默认在/var/lib/rancher/rke2/server/db/etcd。不建议直接移动目录正确做法是修改 config.yamletcd: >/var/lib/rancher/rke2/bin/etcdctl \ --cacert/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \ --cert/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \ --key/var/lib/rancher/rke2/server/tls/etcd/server-client.key \ --endpointshttps://127.0.0.1:2379 endpoint health如果某个 etcd 成员处于 unhealthy 状态会直接削弱 etcd 的多数派能力。多数派一旦丢失整个集群会变成只读或者完全不可用。遇到这种情况最快的恢复方式是重建该 Server 节点让它重新以全新成员身份加入。4.3 证书过期与 TLS 问题RKE2 的证书体系比较特殊。默认内置证书有效期是 1 年RKE2 会在到期前自动轮换但前提是 rke2-server 和 rke2-agent 服务没有处于异常状态。如果你遇到“证书过期后 API Server 仍然正常但 agent 无法连接”的现象优先怀疑证书轮换失败。查看证书有效期openssl x509 -enddate -noout -in /var/lib/rancher/rke2/server/tls/server.crtRKE2 提供了手动轮换命令rke2 certificate rotate systemctl restart rke2-server如果发现证书已经过期命令执行后重启服务集群应该会恢复正常。但如果你修改过tls-san一定要在轮换前重新生成证书否则轮换后新证书可能再次缺失 LB 地址。关于tls-san的修改我见过很多团队在集群创建后补加域名然后发现访问始终报证书错误。原因就是 RKE2 不会自动为新加入的 SAN 重新生成证书必须手动执行证书轮换。注意不要随意删除/var/lib/rancher/rke2/server/tls/下的任何文件。有些手册建议“删掉重新生成”但在 RKE2 中很多证书之间存在强引用关系手动删错一个会导致集群无法启动甚至需要从快照恢复。4.4 网络插件与 DNS 故障RKE2 默认使用 Canal后来版本也支持 Cilium。网络插件出现问题时最直观的表现是 Pod 间 IP 通不了、Service 访问超时、CoreDNS 解析失败。排查网络问题我一般分三步。第一步检查 CNI 二进制和配置目录。正常情况下/var/lib/rancher/rke2/agent/etc/cni/net.d/下应当有明确的配置如果为空说明 CNI 插件没有被正确初始化。第二步检查 Pod 是否获得了 IP以及路由是否存在kubectl get pods -n kube-system -l appcanal -o wide ip route | grep 10.42第三步抓取 VXLAN 端口的包流量确认 8472 端口是否双向可达nc -uvz node-ip 8472CoreDNS 解析失败的场景优先看 CoreDNS Pod 是否 Running然后检查上游 DNS 设置。RKE2 默认的 CoreDNS 会读取/etc/resolv.conf如果你的宿主机/etc/resolv.conf中配置了系统本地 DNS但集群内 Pod 无法访问该地址解析就会超时。生产环境我通常会显式把 upstream 配置改为公共 DNS 或自建内网 DNS同时在 CoreDNS ConfigMap 里加上 rewrite 规则避免外部域名的搜索域问题影响内部解析。4.5 集群调度与故障转移集群调度的问题不一定是硬故障但线上业务受影响同样很大。最常见的是某个 Pod 被重复调度到同一个节点或者节点挂了之后 Pod 一直没有被转移。RKE2 集群的故障转移能力取决于 kube-controller-manager 的默认参数。默认情况下kube-controller-manager 会在节点失联 5 分钟后开始驱逐该节点上的 Pod。这个时间对很多业务来说太慢了。我调整过 kube-controller-manager 参数kube-controller-manager-arg: - node-monitor-grace-period40s - node-monitor-period5s - pod-eviction-timeout60s这样配置后单节点宕机最快 40 秒左右就能感知60 秒后开始驱逐 Pod整体故障转移过程控制在 2 分钟以内。但这个参数要结合业务实际情况权衡如果节点经常因为 IO 抖动导致心跳短暂丢失过短的 grace period 反而会引发不必要的驱逐。另外如果某个节点主动维护需要缩容记得先执行kubectl cordon和kubectl drain而不是直接关机。drain 操作会优雅地将节点上的 Pod 迁移到其他节点避免业务流量中断。RKE2 集群通过 Rancher 管理时可以在节点页面直接执行这些操作底层调用的就是同样的逻辑。5. RKE2 运维实战升级、监控与备份恢复5.1 版本升级的正确姿势RKE2 升级最怕跨大版本跳跃。道理很简单etcd 的数据格式和 API Server 的接口版本不一定向前兼容跨大版本容易遇到数据迁移失败。我的经验是严格按官方路线小版本依次升级每次升级前先用一个测试节点验证。RKE2 支持两种升级方式直接升级 rpm/deb 包后重启服务或者使用 Rancher 的自动化升级。我这边采用 Rancher 的 cluster upgrade 功能在 UI 选择目标版本Rancher 会控制升级顺序一个节点一个节点地滚动。这对生产环境比较友好。手动升级时需要注意的是Server 节点升级后要逐个验证 etcd 健康状况确认上一个节点稳定后再升级下一个。如果升级过程中 etcd 出现健康告警立即停止后续节点升级优先排查问题。5.2 备份恢复与容灾演练RKE2 的备份机制以 etcd 快照为中心。配置文件里启用了定时快照后快照会写在/var/lib/rancher/rke2/server/db/snapshots/目录。恢复时用以下命令rke2 server \ --cluster-reset \ --cluster-reset-restore-path/var/lib/rancher/rke2/server/db/snapshots/etcd-snapshot-xxx.db这条命令会在本地重置 etcd 并从快照恢复。但要注意--cluster-reset会把当前 etcd 成员信息清空并强制以单节点模式启动所以这个操作适合灾难恢复而不是日常操作。恢复完成后需要重新将其他节点加入集群。生产环境我建议把快照同步到对象存储避免单节点磁盘故障导致备份数据一起丢失。可以通过以下配置将快照直接上传 S3 兼容存储etcd: s3-enabled: true s3-bucket: my-rke2-backups s3-endpoint: s3.amazonaws.com s3-region: us-east-1 s3-access-key: xxx s3-secret-key: yyy重点提醒上线前一定要做一次真正的恢复演练而不是仅仅看着快照生成成功就觉得万事大吉。我遇到过明明快照目录里有文件但恢复后 etcd 权限异常导致集群起不来的情况后来定位是备份时对目录执行了压缩导致文件属主变化。恢复流程务必定期验证否则灾难发生时才发现备份不可用就晚了。5.3 常见问题速查表故障现象可能原因排查命令/手段解决方法节点加入后一直 NotReady安全组未放行 10250/8472 端口nc -uvz node-ip 8472调整安全组规则kubectl get nodes超时API Server 负载高或 etcd 慢journalctl -u rke2-server检查磁盘 IO 与 etcd 健康Pod 跨节点通信失败BRIDGE 内核模块未加载sysctl net.bridge.bridge-nf-call-iptables加载 br_netfilterCoreDNS 解析超时上游 DNS 不通kubectl edits configmap coredns -n kube-system修改 upstream 地址Rancher 导入后状态 Waitingagent 无法回连 Rancherkubectl logs -n cattle-system检查网络路由与域名解析etcd 频繁 leader 切换磁盘延迟高iostat -x 1迁移 etcd 到高性能磁盘证书过期导致连接失败tls-san变更后未轮换openssl x509 -enddaterke2 certificate rotate节点故障但 Pod 未转移kube-controller-manager 驱逐时间过长kubectl describe pod调整驱逐参数这张表算是线上运维的高频问题合集了基本覆盖了我这半年遇到的大部分故障场景。建议收藏起来遇到类似问题先按表格定位方向再结合具体日志深入排查。最后再分享一个实际运维中的体会RKE2 和 Rancher 这套组合优势在于整链路的一致性尤其是集群生命周期管理、证书轮换、备份恢复这些 day-2 操作比我自己之前手动维护的 kubeadm 集群省心太多。但它不是“装完就完事”的玩具etcd 对存储性能的要求、网络插件的初始化顺序、节点加入时必须保证端口全通这些细节往往决定了集群上线后的稳定性。如果让我给一个最实在的建议那就是在搭建阶段就把tls-san、etcd 快照、节点标签、网络放行这些基础项一次配置到位不要等着集群跑起来后再去补。补配置的过程会牵扯到证书轮换、节点重启甚至可能的服务中断每一步都是风险。线上环境没有捷径前期多花半小时做规划后面能少熬好几个通宵。希望这篇文章能让你避开我踩过的那些坑顺利把 RKE2 集群跑起来、管起来、稳下去。