Rancher 多服务启动失败复盘：从 Docker 未自启、18 万条历史重试，到回滚实例 IP 冲突-北京尧图网络

故障复盘日期2026-11-03 · 适用范围Rancher 1.x / Cattle · 全文已脱敏管理页面能够打开服务器也能通过 SSH 登录但生产环境的认证、网关、注册中心、缓存和大屏服务却大量停在Activating、Waiting: container starting或Rolling Back。这类问题容易被误判为“镜像坏了”或“Java 应用启动慢”。这次现场真正需要恢复的是从节点运行时、控制面状态机、托管网络到应用依赖的完整链路。结论先行本次存在三个有证据的故障点一个遗漏生产节点的 Docker 未运行且未开机自启Rancher 网络与 DNS 基础容器停止业务启动出现获取 IP 超时历史卷映射删除任务持续重试明显拖慢控制面恢复。恢复期间又出现一次二次故障人工启动的旧认证实例与平台回滚新建的正式实例同时使用同一内部 IP。最终恢复四台节点和应运行的业务服务保留用户指定的三项原有停止 / 取消升级状态。本文的证据边界未取得最初停止基础容器的操作者记录也没有证明 Docker 自启是何时、因何被关闭。因此本文不把某次断电、某个人的操作、Docker 版本或某一条缓存锁等待写成已证实的最初根因。历史任务暂缓是一次可回退的应急处置不等于 13 万条历史资源已全部清理。发布说明IP、主机名、业务应用名、注册中心别名、管理库名、容器 ID、目录中的业务标识均使用示例。保留标准产品名、Rancher 标准表名及关键错误文本以便读者理解机制。未嵌入原始生产截图、原始日志、账号密码、Token 或访问密钥。阅读路线背景与约束 → Rancher 与 Docker → 数据模型 / ERD → Troubleshooting / RCA → 恢复实现 → 验证与后续治理01 · 背景与问题页面在服务却起不来用户最初提供了三台服务器。排查后发现Rancher 资源清单中还登记着第四台生产节点它并未退役而且 SSH 可以连接。这一信息改变了调查方向缺失的节点不是可以直接删除的历史主机而是需要恢复的现役节点。示例节点现场角色观察到的状态10.20.30.11运维环境节点Docker / Agent 运行运维环境基础服务停止10.20.30.12生产节点承载 Rancher 管理容器与镜像仓库等Docker / 管理容器运行生产基础服务异常10.20.30.21主要业务节点业务和基础容器大量退出Agent 持续报告获取 IP 超时10.20.30.22后续补齐的生产节点SSH 可连接Docker 未运行且自启 disabledAgent 断连这些主机由同一个 Rancher Server 管理但分属不同 Rancher 环境。不能把运维环境和生产环境简单画成一个共享的托管网络。故障表现相似需要分别确认各环境的基础服务与实例状态。可见症状当时能确认什么仍不能确认什么Rancher 页面能打开UI / API 至少部分可访问节点、任务线程池、网络和应用依赖是否正常SSH 可以登录宿主机操作系统和 SSH 服务可用Docker Engine 与 Rancher Agent 是否可用容器显示 Up容器主进程仍在运行CNI 配置、内部 DNS、注册中心连接和业务健康是否正常大量服务同时 Activating服务状态没有完成收敛不能直接归因于全部镜像或应用代码同时出错02 · 目标与约束恢复四台现役节点的 Docker / Agent 连通性以及各环境应运行的网络、DNS、调度和健康检查服务。保留业务数据和镜像涉及管理库变更之前建立完整备份、精确目标快照和回滚依据。遵循平台期望状态。最终按用户要求保留job-admin、nginx-secondary的 inactive 状态以及auth-secondary的 canceled-upgrade 状态。通过真实应用健康响应和前端入口验证恢复单次 200、容器 Up、平台绿色状态都只作为证据的一部分。对积压任务只做已核实范围内的可回退处置不把本次恢复扩大为全库清理或存储目录删除。03 · Rancher 和 Docker 到底是什么关系3.1 Docker 管理单机容器运行Rancher 协调跨节点期望状态在本案的 Rancher 1.x / Cattle 架构中Docker Engine 位于每台宿主机负责镜像、容器进程、命名空间、挂载及容器生命周期操作。Rancher Server 接收服务配置和期望副本数保存资源关系并驱动状态机节点上的 Rancher Agent 接收操作、调用本地 Docker并回报实际状态。Rancher Server 和 Agent 自身也以 Docker 容器形式部署。[1]层次核心职责本案中的故障或误区Linux / systemd主机启动、服务启停、内核网络能力SSH 正常但 docker.service 可以仍然停止或未启用自启Docker Engine在单机创建和运行容器管理本机镜像与挂载Engine 没启动时Agent 和业务容器都无法工作Rancher Agent连接控制面把远程操作转成本地运行时操作连接断开时远程资源清理可能反复等待响应Rancher Server / Cattle服务编排、资源状态机、任务调度、健康与期望状态收敛历史重试负载会影响正常任务的及时推进Rancher 基础服务托管网络、metadata / DNS、IPsec、调度与健康检查基础容器停止会使多个应用共同失去网络前提应用依赖与业务层注册发现、缓存访问、数据库连接、HTTP 功能容器进程启动后仍可能因 Nacos 或 Redis 异常而不健康3.2 三层“自启动”必须分别核对第一层是 systemd 是否在主机启动后拉起 Docker第二层是 Docker 的容器 restart policy第三层是 Rancher 根据服务期望状态进行的协调。第一层没有起来后两层就无从工作。本案部分 Rancher 托管容器没有 Docker 自动重启策略其恢复依赖平台协调因此不能把“没有 always”直接写成配置错误更不能对整机所有容器无差别设置 always。Docker 对容器重启策略的定义可参考官方文档。[2]# 只读核对宿主机服务与容器策略 systemctl is-active docker systemctl is-enabled docker docker inspect -f {{.Name}} {{json .HostConfig.RestartPolicy}} container # 经确认后修复本案遗漏节点的 Docker 开机自启 systemctl enable --now docker3.3 本文不是 Rancher 2.x / Kubernetes 恢复教程现场出现rancher/server、rancher/agent:v1.2.11、Cattle 管理表以及 IPsec / metadata 基础服务符合 Rancher 1.x / Cattle 的架构特征。没有从未固定的镜像标签中确认 Server 的精确补丁版本不能把 Agent 版本当成 Server 版本。Rancher 2.x 的 Kubernetes 管理架构与此不同本文的表结构、状态机和应急 SQL 不应直接套用到 RKE2、K3s 或现代 Kubernetes 集群。04 · 系统架构与核心设计图 1 · 控制面、Docker 节点及环境边界。地址均为示例。平台保存的是“应当运行什么、运行多少副本、资源如何关联”节点承载的是“当前实际上运行了什么”。两者通过 Agent 事件异步收敛。恢复动作既要确认本地容器进程也要确认该实例是否仍然属于平台当前管理的部署单元。另一个关键设计是基础网络容器也运行在 Docker 中。Docker 能运行容器不代表 Rancher 托管网络已经建立。本案应用使用 CNI 管理的网络依赖 network-manager、metadata / DNS 和 IPsec 共同完成地址、名称解析与跨主机通信。官方历史文档也说明托管 IP 不一定呈现在 Docker 的网络元数据中docker inspect的 IPAddress 为空不能单独作为“无网络”的判据。[3]关于链路本地 DNS 地址日志中的169.254.169.250:53是本案例 Rancher 内部 DNS 的技术地址保留它有助于复现排查逻辑它不是对外暴露的业务服务器地址。应结合平台配置识别服务用途不要与其他平台的元数据端点混为一谈。05 · 数据流和执行流程图 2 · 管理操作的数据流与实际业务请求的数据流。用户在管理页面执行启动操作后Rancher 更新期望状态驱动任务对资源、网络、存储和容器逐步操作节点回报事件后管理库中的状态才可能最终变成 active / healthy。业务流量则通过 Nginx / 网关访问应用及依赖并不要求每个请求都经过 Rancher Server。图 3 · 抽象启动时序从状态机派发到依赖就绪。因此container started与“服务可用”之间还有一段距离。现场 Agent 已能启动部分进程但在等待托管 IP 时超时基础网络恢复后应用又因跨主机 Nacos 连接未就绪而退出。这两个阶段的错误文本不同不能用一次应用重启去替代网络层恢复。06 · 数据模型为什么一条卷删除任务会卡住多年这次排查读取了管理库的状态机与资源关联表。数据库名在文中统一写作orchestrator_meta下列是 Rancher 标准表名。它们是平台元数据不是订单、用户、商品或门店业务表。现场 SQL 关联、状态值和执行日志是本节依据ERD 只覆盖与此次故障相关的关系子集。图 4 · 管理库核心 ERD。业务关联键、可选关联和资源类型边界单独注明。表职责关键键及关系host / agent主机登记及节点通信身份各自 id 为主键host.agent_id 关联 agent.id。主机存在与 Agent 在线是两个判断。service服务期望状态与副本配置id 为主键account_id 区分环境environment_id 对应旧模型中的 Stack。instance平台实例对象及其运行状态id / uuid 标识平台实例Docker 容器 ID 属于另一套外部标识一个平台 ID 不能直接当 Docker ID 使用。service_expose_map服务与实例关联service_id / instance_id 分别关联服务和实例从模型上可表示多对多managed / upgrade 用来判断当前管理及升级保留关系。volume平台中的卷或容器文件系统对象id 为主键instance_id、image_id 可以为空具体含义必须结合关联对象、kind 和挂载判断。storage_pool执行存储操作的存储池id 为主键agent_id 关联执行节点 Agent不能仅凭存储池 active 判断 Agent 可响应。volume_storage_pool_map卷与存储池的映射volume_id / storage_pool_id 分别关联两端卷与存储池可通过此表形成多对多本次卡在 removing。mount容器与卷的挂载关系volume_id / instance_id 关联卷和实例卷可被多个实例挂载实例也可挂载多个卷。process_instance状态机过程与重试调度id 为主键resource_type resource_id 共同定位资源process_name 决定动作end_time、run_after、phase、execution_count 描述执行状态。process_execution同一任务多次执行的详细轨迹process_instance_id 关联 process_instance.id一条任务可对应多次执行日志可能比任务主表大得多。6.1 ID 映射先确认类型再关联业务资源键在本次volumestoragepoolmap.remove过程中process_instance.resource_id指向的是volume_storage_pool_map.id而不是 volume.id、instance.id 或 Docker 容器 ID。它是字符串资源键并不是可无条件连接任意资源表的通用外键。必须限定过程名及资源类型再按实际版本的 schema 关联。-- 只读诊断示例先用 DESCRIBE / EXPLAIN 验证目标版本 SELECT p.id AS process_id, p.resource_type, p.resource_id, m.id AS mapping_id, m.state AS mapping_state, v.id AS volume_id, v.state AS volume_state, v.removed, sp.agent_id, a.state AS agent_state FROM process_instance p STRAIGHT_JOIN volume_storage_pool_map m ON m.id CAST(p.resource_id AS UNSIGNED) STRAIGHT_JOIN volume v ON v.id m.volume_id STRAIGHT_JOIN storage_pool sp ON sp.id m.storage_pool_id STRAIGHT_JOIN agent a ON a.id sp.agent_id WHERE p.end_time IS NULL AND p.process_name volumestoragepoolmap.remove ORDER BY p.id LIMIT 50;示例保留了显式 CAST避免把不同类型 ID 的隐式转换当成业务关系。现场还通过 EXPLAIN 核对了关联执行路径。STRAIGHT_JOIN 只体现当次诊断时控制关联顺序的选择不是所有版本、所有数据分布都必须使用的优化结论。6.2 写入先后顺序与跨系统一致性从本次可观察的状态机机制看平台先持有资源对象和关系再记录待执行的过程远程操作经 Agent / Docker 执行响应返回后更新阶段和完成状态失败则保留重试信息。该描述用于解释本案并不宣称所有内部 SQL 的精确调用顺序均已逐行审计。管理库事务无法把远程 Docker 操作包进同一个原子事务。节点离线、请求超时或反馈延迟会产生“平台记录已进入下一生命周期但某个关联删除过程还没完成”的中间状态。具体到本案volume 已是 purged而映射仍是 removing过程仍反复调用远程 Agent 并超时。这是必须处理的跨系统一致性问题。两个不能互相替代的事实volume.statepurged证明平台元数据进入了该状态不等于我们已独立验证所有物理文件都不存在同样卷不再关联运行实例也不足以直接授权删除宿主机目录。需要继续核对挂载、实际存储对象和平台清理语义。07 · 证据、指标与故障时间线证据观察值解释边界资源使用初查节点可用内存充足磁盘与 inode 未耗尽排除了“当前整体资源耗尽”作为共同解释不能据此否认历史 OOM 日志。网络错误AgentTimeout getting IP address应用内部 DNS UDP 超时属于网络初始化和解析链路的直接证据。历史过程初查未完成卷映射删除任务 181,457 条是一次查询快照不能与后续剩余数直接当作同一时刻数据比较。重试次数抽样历史任务执行次数约 75 万次是抽样任务的累计次数不代表 18 万条任务每一条都达到该次数。控制面负载Rancher 容器 CPU 单次采样约 866%MySQL 出现 query cache lock 等待容器 CPU 统计可超过 100%866% 大致表示消耗约 8.66 个逻辑 CPU 的计算量仍需结合采样窗口。最终核查当前可执行积压为 0暂缓任务仍为 130,363 条CPU 后续约 1%2%可执行队列归零不等于历史未完成记录归零CPU 值为现场采样。阶段按现场顺序操作与结果初步诊断浏览器自动化无法可靠读取当前页面转用 SSH、Docker 日志和管理库只读查询。完整拓扑确认从管理资源中补齐第四台现役生产节点确认 Docker 停止、自启 disabled。备份尝试调整尝试暂停 Rancher 管理进程时触发整容器自动重启随后改用在线事务一致性备份。节点与网络恢复启用遗漏节点 Docker逐层启动 CNI、metadata、network-manager、DNS、IPsec、调度和健康检查。依赖服务恢复Redis 就绪Nacos 报告启动成功MinIO 启动随后验证跨主机 Nacos 健康接口返回 200。控制面减压完整备份校验通过保存候选任务快照将当时仍未完成的 130,363 条目标任务延期再重启管理容器。平台状态收敛四台 Agent 均 active应运行的基础和业务服务回到 active / healthy平台创建新的替代实例。应用层复查认证接口一度报告 nacosDiscoveryDOWN定位到旧实例与回滚实例使用同一内部 IP。最终恢复及清理停止旧认证实例、重启当前实例连续健康检查 UP旧实例归档后删除当前正式实例继续运行。时间线采用操作顺序描述没有把不同节点上的本地时钟拼接成毫秒级因果链。数据库时间、容器日志中的 UTC 时间与主机本地时间应在正式审计时统一时区并检查时间同步。08 · 故障链与方案取舍图 5 · 直接故障、恢复阻塞和二次问题的分层关系。方案为什么当时没有直接采用最终取舍只重启业务应用CNI、DNS 与隧道没有恢复应用还会继续获取 IP 超时或注册失败先验证基础网络再恢复依赖与应用。一次性启动全部退出容器退出列表可能包含升级保留实例和被用户主动停止的服务只恢复已确认的目标平台回滚后重新检查实例归属。等待全部历史任务自然跑完节点接回后部分任务确实完成但巨大积压仍影响恢复速度保留完整备份和筛选快照仅延期已核实的剩余目标任务。批量 DELETE process_instance会丢失状态机依据映射与执行日志还可能残留不能代表物理清理完成使用可回退的 run_after 调整应急减压历史治理另立任务。重装或升级 Docker / Rancher现场没有证明版本兼容性是本次根因直接升级会扩大变更范围保留运行环境先修复当前状态并记录版本混用现象。修改所有容器 restart policy可能与 Rancher 的副本、升级和回滚协调同时作用修复宿主机 Docker 自启保留平台对服务生命周期的管理。09 · Troubleshooting按六步展开四个关键问题9.1 SSH 可登录为什么 Rancher Agent 仍离线步骤现场调查与解释Symptoms主机存在、SSH 可连接Rancher 中 Agent 却是 disconnected / reconnecting关联任务持续超时。Investigation核查 systemctl、Docker socket、docker ps、Agent 进程遗漏节点上 docker.service 未运行开机自启为 disabled。Root Cause操作系统与 SSH 的启动不依赖 Docker。Docker 未运行使 Agent 容器无法运行也就无法执行控制面派发的远程操作。自启关闭的历史原因尚未证实。Resolution确认节点仍为现役执行 systemctl enable --now docker检查既有 Agent 容器恢复连接而不是删除该主机重新注册。VerificationDocker active / enabledAgent 连接建立最终四台现役节点均为 active。Lessons Learned资产清单要从平台资源反向核对监控应分别覆盖主机、Docker、Agent不能只监测 SSH 或 Ping。9.2 为什么多个服务共同卡在 container starting步骤现场调查与解释Symptoms网关、认证、注册中心、缓存等共同等待启动Agent 报 Timeout getting IP address应用内部 DNS 超时。Investigation检查基础服务容器和网络日志确认 CNI、network-manager、metadata / DNS 等停止检查网桥、IP、路由和跨主机连接。Root CauseRancher 托管网络初始化前提没有满足。节点 Docker 可以创建进程但 Agent 等不到可用托管 IPDNS 和 IPsec 未就绪又使服务名解析及跨主机依赖连接失败。基础容器最初为何停止仍待审计。Resolution按依赖恢复 CNI / metadata、network-manager、DNS、IPsec 及相关健康服务之后恢复 Redis / Nacos / MinIO 和应用。Verification网桥恢复 10.42 网段CNI 日志报告成功分配 IP容器内解析服务名成功跨主机 Nacos readiness 返回 200。Lessons Learned对每一层使用独立退出条件。看见“分配 IP 成功”后仍应继续验证 DNS、跨主机访问与应用注册。9.3 十多万条历史删除任务如何影响恢复步骤现场调查与解释Symptoms控制面高 CPU、API 及任务超时基础服务的启动过程长期没有完成收敛。Investigation按 process_name / phase 聚合未完成过程追踪 resource_id → 卷映射 → 卷 → 存储池 → Agent读取执行日志里的 RemoteAgent 调用超时。Root Cause历史卷映射删除长期面向不可响应的 Agent 重试对应卷已有 purged / removed 状态而映射仍 removing清理过程与资源生命周期没有完成一致性收敛。历史任务的长期保留、重试机制和缺少积压治理共同促成恢复负载。Resolution接回现役节点让一部分任务正常完成完成全库备份及精确快照后延期仍未结束且已核实目标重启管理容器清除旧执行上下文。Verification用户应运行的服务收敛当前到期可执行积压为 0CPU 从高负载采样降到低个位数130,363 条延期任务仍可追溯。Lessons Learned同时监控积压量、最老任务年龄、重试次数和任务类型。减压结果支持历史重试是重要恢复阻塞但组合操作并非单变量实验不能宣称量化了每个因素的独立贡献。9.4 为什么平台绿色了认证健康却一度 DOWN步骤现场调查与解释SymptomsRancher 显示认证 active / healthy但应用健康接口出现 503nacosDiscoveryDOWN日志出现 UnknownHostException 和 Redis PING 异常。Investigation对比两个同名认证实例的实例 ID、UUID、部署单元、内部 IP 和 service_expose_map旧实例 managed0 / upgrade1新实例 managed1 / upgrade0期望副本数为 1。Root Cause恢复过程中人工启动了旧实例控制面恢复后Rancher 回滚又创建当前实例同一部署单元复用了内部 IP。旧实例脱离管理后仍运行形成地址冲突和连接不稳定。Resolution停止旧实例重启当前正式实例以重新建立连接健康稳定后对旧实例配置、文件系统和日志归档再仅删除旧容器。Verification正式实例持续运行旧实例从平台标记 removed认证、后台和大屏应用健康均为 UP认证重复采样均为 200。Lessons Learned人工从运行时启动容器可能与平台协调并发。恢复后必须复核管理关系与 IP 唯一性而不是依靠同名或相同镜像判断实例有效性。图 6 · 本次恢复过程中出现的认证实例 IP 冲突及其修复。10 · 根因分析与 5 Whys这次故障不适合用一个“根因”覆盖全部现象。更准确的结论是已证实的基础设施故障、历史状态机债务和恢复期间的状态竞争共同作用。应把最初触发、直接失效机制、恢复阻塞和二次故障分开记录。层级结论证据强度最初触发基础容器为何在此前退出、何人关闭遗漏节点自启未完成审计未证实不做责任归因节点层故障一台现役生产节点 Docker 停止且 disabled导致 Agent 无法运行直接观察与恢复结果支持共同失效机制托管网络 / DNS / 跨主机隧道未就绪阻断容器初始化及应用依赖日志、网络检查与接口验证支持恢复阻塞因素历史卷映射删除重试形成大量负载控制面状态推进迟缓任务关联、超时堆栈与减压前后观察支持恢复期间二次故障旧实例人工启动与平台回滚替代实例并存同一部署单元 IP 复用两条实例记录、映射标记及相同 IP 已核对5 Whys A为什么业务服务无法完成启动为什么页面一直等待容器启动——Agent 在等待托管 IP 或应用在等待内部依赖。为什么网络和依赖不可用——CNI / DNS / IPsec 等基础服务停止或尚未就绪。为什么基础服务没有顺利自动恢复——存在断连节点控制面还在执行大量历史超时重试。为什么历史重试长期保留——跨系统清理没有收敛缺少针对老任务和失联 Agent 的有效治理。为什么这类债务没有提前暴露——当时的运维关注点未形成对资产完整性、节点运行时、任务年龄与应用依赖的统一验收。此项属于从现象提出的流程改进不等于已审计所有既有监控配置。5 Whys B为什么认证恢复后又出现连接异常为什么同一服务连接不稳定——两个实例同时使用相同内部 IP。为什么有两个实例——旧实例被人工拉起平台自动回滚又创建当前实例。为什么旧实例没有被同等管理——服务关联已是 managed0 / upgrade1属于回滚保留对象。为什么人工恢复会与平台竞争——恢复初期直接依据容器退出状态启动未在平台重新收敛后立即完成实例归属核对。以后如何避免——先恢复控制面再优先使用服务级操作任何必要的底层应急启动都登记清单平台恢复后逐项复核副本、部署单元和 IP。11 · 关键实现可回退地解除历史任务阻塞图 7 · 本次恢复路径与各阶段的验证关口。11.1 管理库备份事务一致性、完整性与恢复能力是三件事现场使用 all-in-one 管理容器尝试停止内部管理进程时触发了整个容器的自动重启因此改变方案保留 MySQL 运行使用mysqldump --single-transaction --quick导出 InnoDB 管理表并压缩归档。备份完成后执行 gzip 完整性校验和 SHA-256。未在本次窗口做隔离环境恢复演练因此不能把压缩校验成功表述为“已经验证可完整恢复”。# 示例在管理节点执行备份目录使用受限权限 umask 077 mkdir -p /data/orchestrator-recovery set -o pipefail docker exec rancher-server-container mysqldump --defaults-extra-file/run/secure/admin.cnf --single-transaction --quick --routines --triggers --events --hex-blob --databases orchestrator_meta | gzip -1 /data/orchestrator-recovery/management-full.sql.gz gzip -t /data/orchestrator-recovery/management-full.sql.gz sha256sum /data/orchestrator-recovery/management-full.sql.gz /data/orchestrator-recovery/SHA256SUMS命令是脱敏后的操作模式不包含现场认证信息。/run/secure/admin.cnf需由操作者预先安全准备备份期间应避免并发 DDL并核对是否存在非事务表。管理库、容器持久化目录和卷数据的备份范围也要分别记录。11.2 目标筛选与快照不按“表很大”执行清理实际筛选条件包括过程未完成、过程名确为卷映射删除、所属目标存储池 Agent 已核对、卷已 purged、removed 早于本次故障。先把候选过程完整复制到独立恢复库导出快照再按主键对仍未完成的记录调整 run_after。现场候选快照为 143,756 条操作期间部分任务继续正常完成真正延期的剩余记录是 130,363 条。管理库 SQL 的适用范围下面是基于本次已核实旧版 schema 的应急模式用于说明筛选、快照、事务和回滚。应优先使用平台支持的服务操作或维护方式直接修改内部任务表属于有版本约束的应急措施不能复制到未知生产库直接运行。示例没有提供全库 DELETE。-- 应急模式示例只在完成备份、字段核对和只读审计后使用 CREATE DATABASE recovery_example; CREATE TABLE recovery_example.deferred_tasks LIKE orchestrator_meta.process_instance; -- 将已审计的精确目标行保存目标清单应先独立复核 INSERT INTO recovery_example.deferred_tasks SELECT p.* FROM orchestrator_meta.process_instance p JOIN recovery_example.approved_task_ids t ON t.id p.id WHERE p.end_time IS NULL AND p.process_name volumestoragepoolmap.remove; -- 导出上述快照并校验后在短事务中延期 START TRANSACTION; UPDATE orchestrator_meta.process_instance p JOIN recovery_example.deferred_tasks b ON b.id p.id SET p.run_after 2036-11-03 00:00:00 WHERE p.end_time IS NULL AND p.process_name volumestoragepoolmap.remove; SELECT ROW_COUNT() AS deferred_rows; COMMIT;示例中的approved_task_ids是需要自行建立并审计的白名单不是 Rancher 原生表。现场使用已核实的关系条件建立了独立目标快照。2036 年的 run_after 是这次应急中显式设置的远期保留时间表示等待人工治理它不是推荐的常规调度策略也不应无人认领地保留十年。-- 回退模式只恢复本次标记且仍未完成的任务 START TRANSACTION; UPDATE orchestrator_meta.process_instance p JOIN recovery_example.deferred_tasks b ON b.id p.id SET p.run_after b.run_after WHERE p.end_time IS NULL AND p.run_after 2036-11-03 00:00:00; COMMIT;这次变更只调整任务调度时间没有把未完成过程伪装成成功也没有删除卷或修改业务表。备份和快照建立后执行短事务并检查影响行数再重启管理容器让仍保留在旧执行上下文中的工作重新按持久化状态协调。由于控制面和内置 MySQL 同处一个容器重启窗口也包含该内置管理库的短暂不可用宿主机上其他独立容器不会因该操作一起重启。11.3 计数要把“总未完成”和“当前可执行”分开-- 只读当前已到期、可以被执行的过程 SELECT process_name, COUNT(*) AS runnable FROM process_instance WHERE end_time IS NULL AND (run_after IS NULL OR run_after NOW()) GROUP BY process_name; -- 只读本次被远期保留的过程 SELECT COUNT(*) AS deferred FROM process_instance WHERE end_time IS NULL AND run_after 2036-11-03 00:00:00;最终第一项统计为 0第二项为 130,363。这两个数字同时成立。博客、工单和监控中若只写“积压归零”会错误暗示历史资源已被全部清理。12 · 13 万条历史任务到底在清理什么恢复后能否删除剩余数量已核实的分类处理边界130,359现役生产节点上的旧容器根文件系统存储关联对应卷已 purged可设计受控批次恢复平台清理先确认无运行实例与有效挂载引用。3仍断连测试节点上的旧容器存储关联需要单独确认节点状态与资源归属不能当作现役生产节点任务一起处理。1示例 /var/log/example-app 目录卷的关联目录卷与容器文件系统不同必须单独核查没有执行宿主机目录删除。对这批已暂缓对象再次核查其关联实例及挂载没有发现仍由运行容器引用的卷。但这是元数据层的审计结果不等于完成了所有物理存储验证。记录里只有 purged / removed 标记并不能证明宿主机路径永远不再被其他对象复用。服务恢复后可以开展后续清理推荐让平台按经核实的资源关系分批完成原有生命周期操作并观察任务耗时、节点 I/O、控制面负载和业务健康。测试节点的三条记录和目录卷的一条记录应单列避免误清。执行日志归档、元数据保留期限和物理数据删除也应分别治理。本次没有完成的事项130,363 条目标任务目前仍是延期保留状态没有批量 DELETE 任务表没有把映射统一改成 removed也没有删除关联目录。后续批次清理尚未执行其安全性和性能效果不能在本文中写成已验证。13 · 旧认证实例为什么可以删删除时保存了什么删除依据来自完整证据链服务期望副本数为 1正式实例关联 managed1 / upgrade0旧实例关联 managed0 / upgrade1两者属于同一部署单元、使用同一内部 IP旧实例停止后正式实例与应用健康稳定。由此可以判断旧实例是回滚保留对象无证据表明它是“测试服务”。同名、同镜像或运行时间短任何一个条件单独都不够。-- 只读示例把平台实例与服务关联一起看 SELECT i.id, i.uuid, i.name, i.state, e.service_id, e.managed 0 AS managed, e.upgrade 0 AS retained_for_upgrade FROM instance i JOIN service_expose_map e ON e.instance_id i.id WHERE i.id IN (old_instance_id, current_instance_id) AND e.removed IS NULL;归档保存了旧容器 inspect 配置、标准输出日志、导出的容器文件系统及 SHA-256校验成功后仅执行针对旧容器的docker rm old-auth-container没有附加 -v也没有删除镜像或共享数据卷。平台随后把旧实例标记 removed正式实例继续运行。需要说明备份范围docker export不包含挂载卷中的内容因此导出容器文件系统不能替代数据卷备份。本次已核查旧实例挂载仅包含只读 Rancher CNI 工具卷仍保留该共享卷。导出归档与 inspect 也不是一条命令即可自动恢复的完整部署包后续恢复要重新核对运行参数和网络归属。[4]14 · 验证过程从平台状态到真实依赖层次检查方式现场结果与限制节点运行时四台现役节点 systemctl、Docker 和 Agent 状态Docker 均 active / enabledAgent 均 active。基础服务按环境检查 CNI、network-manager、metadata / DNS、IPsec、调度及健康检查应运行的基础服务最终均 active / healthy。内部网络容器内解析服务名检查 CNI 日志与跨主机 Nacos readiness域名解析成功跨主机健康接口 200未进行完整性能压测。应用启动认证、网关、HR、移动端、工业数据、大屏应用启动日志均观察到应用启动成功启动日志仍需与健康接口共同判断。依赖健康/auth/actuator/health、/admin/actuator/health、/screen/actuator/health最终返回 HTTP 200 / statusUP认证额外连续采样三次均 UP约 0.050.07 秒。用户入口/web/ 与 /dp/HTML 入口均返回 200。未使用业务用户账号完成真实登录或业务写入操作。控制面到期任务数量与容器 CPU 采样到期可执行积压 0延期保留 130,363后续 CPU 低个位数。停止项逐项核查用户指令job-admin、nginx-secondary 保持 inactiveauth-secondary 保持 canceled-upgrade任务注册相关告警可能仍由主动停止的 job-admin 引起。Rancher 的 healthy 与 Spring Boot Actuator 的 UP 不是同一个信号。认证故障就是反例平台显示 healthy 时应用依赖健康仍可以是 DOWN。最终验证采用多层证据并明确没有执行端到端业务交易、全量历史任务清理、故障重演和主机重启演练。15 · Lessons Learned这次真正改变了什么资产清单必须闭环。用户最初给出的三台服务器是调查入口Rancher 中的第四台现役节点改变了因果判断。以后应让平台清单、主机清单和部署清单自动对账。判断必须分层。SSH、Docker、Agent、基础网络、容器进程、注册发现和业务接口各有自己的健康信号。恢复顺序比重启次数重要。先把基础设施恢复到可工作的状态再启动依赖和应用避免把同一个网络错误扩散成多个应用启动失败。人工底层操作要登记并在平台重新收敛后复核。此次旧认证实例的人工启动确实造成了后续冲突应纳入复盘而不是从成功叙事中省略。状态机债务需要专门治理。重试实现了失败后的继续尝试却也会放大多年未收敛的资源状态老任务年龄和重试次数应成为一等监控指标。数据清理必须依赖关系驱动。卷、映射、实例、挂载和执行记录各有生命周期删除一张表不等于完成清理。证据要保留不确定性。当前没有审计证据证明最初停止基础服务的触发事件不应把猜测升级为结论。16 · 后续优化从应急恢复到长期治理优先级优化项可验证的验收标准P0建立四台现役节点的主机 / Docker / Agent 联合监控分别告警节点不可达、Docker 不运行、Agent 断连维护完整资源清单。P0收口延期任务治理指定负责人、处理窗口和回退流程130,359 条根文件系统关联按审计批次推进其余 4 条单独跟踪不把 2036 远期时间当成完成日期。P0建立备份恢复演练在隔离环境还原管理库验证表关系、实例清单与版本依赖补齐卷数据、配置和权限的备份范围。P1控制任务重试和积压风险按过程类型统计数量、年龄、失败原因与重试次数评估该旧版本可支持的退避、并发和人工终止机制避免未经验证的内部参数变更。P1升级 / 回滚后做实例归属审计检查期望副本、managed / upgrade、当前部署单元及内部 IP发现运行中的保留旧实例及时隔离。P1监测 DNS 与跨主机链路从容器内部解析服务名并请求远端依赖健康端点对 IPsec 隧道与基础容器建立持续检查。P1统一版本与镜像标识记录 Server / Agent / Docker 精确版本和镜像 digest针对现场 Docker 19.x 与 23.x 混用现象制定验证计划不把混用直接当成本次根因。P2评估平台演进与迁移梳理旧 Cattle 网络、卷、服务与外部依赖再规划隔离测试和迁移路线本次未执行生产升级。17 · 可迁移的排查清单# 1. 先确认节点运行时不凭 SSH 判断 Docker 可用 systemctl is-active docker systemctl is-enabled docker docker ps -a --format {{.ID}} {{.Names}} {{.Status}} # 2. 取有限、近期日志避免把历史应用日志当作当前失败原因 docker logs --since 10m --tail 120 rancher-agent docker inspect -f {{.Name}} {{json .State}} target-container # 3. 检查基础网络与实际容器内部解析 ip -4 addr show docker0 sysctl net.ipv4.ip_forward docker exec running-business-container getent hosts registry-service-name # 4. 在隔离的终端中读取必要日志发布前移除凭据 # Agent / IPsec 日志可能含认证参数不要复制原始完整输出到公开文章 # 5. 应用层逐项验证并检查 HTTP 状态和 JSON 内容 curl --max-time 10 -i http://frontend-host/auth/actuator/health curl --max-time 10 -i http://frontend-host/admin/actuator/health curl --max-time 10 -i http://frontend-host/screen/actuator/health检查到主机在线但 Docker 停止就先处理运行时检查到多个服务共同获取 IP 超时就先检查基础网络检查到大量旧任务远程超时就沿资源关联追到执行 Agent平台恢复后出现单个服务间歇异常就检查实例归属、地址复用和应用依赖。每一步都先缩小故障层次再选择最小恢复动作。18 · 总结这次恢复把“服务器能登录”“容器能运行”“平台能协调”“网络能通信”和“应用能提供服务”拆成了独立证据。Docker 未自启解释了一个现役节点为何离线基础网络缺失解释了多个服务为何共同卡在启动历史任务重试解释了控制面为何难以快速收敛恢复期间的旧实例复活则解释了认证为何在平台绿色后仍然不稳定。最终恢复应运行的服务并保留明确的停止项和历史治理边界。可以迁移到类似场景的做法是完整拓扑、分层验证、依赖顺序、精确备份、关系驱动清理以及对人工恢复和平台自动协调之间竞争的持续复核。19 · 参考资料与适用性说明本次诊断数字、状态、关联关系和恢复结果来自现场 SSH、Docker、管理库与健康接口的观察下列官方资料用于解释产品机制。历史文档可能重定向或更新引用的是与本案旧版 Cattle 架构对应的内容。[1] Rancher 1.6Installing Rancher Server。Server / Agent 以 Docker 容器部署的历史架构。[2] DockerStart containers automatically。容器重启策略及其边界。[3] Rancher 历史 CNI 网络说明与 1.6 排障 FAQ。CNI 托管 IP 与 Docker 网络元数据的区别与本案一致的历史网络模型。[4] Dockerdocker container export。导出不包含挂载卷内容。补充Rancher 1.6 Troubleshooting FAQsCattle 官方代码仓库Docker Volumes。内部表操作须以实际部署版本和 schema 为准。全文为脱敏后的真实工程复盘。图中地址与业务名均为示例保留问题机制、资源关系、数据统计和实际恢复边界。正文和图表均在本 HTML 文件内无外部脚本、字体或图片依赖。

Rancher 多服务启动失败复盘：从 Docker 未自启、18 万条历史重试，到回滚实例 IP 冲突

相关推荐

国内有哪些靠谱的商用AI数据集平台？

AI Prompting for Everyone 课程笔记 - P03 联网搜索 Web Search

AI Prompting for Everyone 课程笔记 - P04 联网搜索资源 Web Search Sources

更多资讯

2KB SRAM Arduino多任务：SCoop协作式调度实战

研究生查文献总漏关键论文？我更建议用 NNScholar 接着做引文追踪

VMware安装CentOS 7全流程指南与优化技巧

Remix IDE与Polkadot Hub智能合约部署指南

纯电动车节能车速规划：时空建模与动态调整策略

数据清洗技术演进：从批处理到智能化的实践历程

今日更新

多智能体协作系统架构设计与实践优化

大模型系统性入门实战指南：从原理到部署微调的全链路路线

鸿蒙文件系统沙箱机制解析与开发实践

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？