前言
针对服务器异常重启且服务未自动恢复的情况，排查思路需要分为“操作系统/硬件层面”和“K8s/容器层面”两个方向。
一、 排查操作系统为何重启
首先需要弄清楚是掉电/硬件故障，还是系统崩溃，或者是内存不足（OOM）导致的重启。
确认重启准确时间
last reboot # 或者 uptime -s这将帮助你在日志中锁定具体的时间段。
uptime -s 2026-01-04 21:07:45 #可确定具体重启时间接下来去哪里查“是谁重启的”？
既然确定是“被重启”的，你需要找出指令来源：
- 检查谁登录过查看在 21:06 左右谁在线：
last | head -n 20看是否有用户（如 root, oper）在 21:00 ~ 21:06 之间登录并在且仍然在线（或者显示 down）。
- 检查操作历史如果是人为操作，查看 root 或其他用户的命令历史：
history | grep reboot # 或者查看特定用户的历史 cat /home/user/.bash_history | tail -n 20- 检查审计日志如果开启了
auditd，可以查到具体的命令调用：
grep "reboot" /var/log/audit/audit.log grep "shutdown" /var/log/audit/audit.log- 云平台监控如果是阿里云/华为云/腾讯云等云平台，去控制台查看“操作日志” 。
- 如果控制台显示“用户重启实例”，那就是有人点的。
- 如果显示“系统维护重启”，那就是云厂商的问题。
总结
确定服务器是否为“异常”重启，还是被“命令”重启的。这是影响排查方向的 。
检查系统日志（核心步骤）
由于服务器已经重启，当前的dmesg可能看不到之前的信息。你需要查看上一次启动期间的日志。
- 使用systemd日志 (推荐):
# 查看上一次启动周期的日志（即崩溃前的那次） journalctl -b -1 -e # 如果日志太多，可以只看最后几百行，寻找 error, panic, critical 等关键字 journalctl -b -1 -n 500- 如果输出提示 “Data from the specified boot is not available”，说明日志没有持久化配置，只能查
/var/log下的文件。 - 查看传统日志文件:检查
/var/log/messages或/var/log/syslog（取决于你的linux版本）：
grep -i "error" /var/log/messages | tail -n 50 # 或者是 grep -i "error" /var/log/syslog | tail -n 50检查是否因内存不足 (OOM) 被强杀
集群在负载高时容易耗尽内存，导致 Linux 内核触发 OOM Killer，这通常会导致系统卡死重启或关键进程被杀。
# 搜索内存溢出记录 grep -i "Out of memory" /var/log/kern.log # 或者 grep -i "Kill process" /var/log/syslog # 或者 journalctl -k | grep -i "OOM"如果你看到服务或相关容器进程被 Kill，说明你需要升级配置或限制容器资源。
二、排查集群故障根因
在排除“人为 SSH 登录重启”的可能性后，那么，是谁触发了重启？这至关重要。
可能性一：自动化的监控脚本
考虑到 21:00:01 监控开始报错。
场景：服务器上可能运行着一个脚本（crontab 或后台服务）。它检测到某个业务连续报错或端口不通，于是执行了某个脚本命令试图自动修复。或者这个脚本占用了大量资源导致节点资源耗尽。
验证方法：
- 检查计划任务日志：
grep CRON /var/log/cron | grep "21:0"# 或者 grep CRON /var/log/syslog | grep "21:0"
可能性二：K3s/K8s 节点的资源耗尽
当k8s节点的资源耗尽时，节点会进入不可用状态（节点被标记为 NotReady），服务进入卡顿或者不可用状态。通常分为K8s 层面（Kubelet 的反应）和操作系统层面（Linux 内核的反应）两个阶段。
内存耗尽
这是最容易导致服务崩溃的原因。
K8s 层面的反应 (Pod驱逐):
现象：当节点内存低于阈值（默认
memory.available < 100Mi），Kubelet 会触发MemoryPressure状态。后果：Kubelet 开始驱逐Pod。它会根据 QoS 等级（服务质量）来杀 Pod：
- 先杀BestEffort（没设置 limit/request 的 Pod）。
- 再杀Burstable（使用了超过 request 内存的 Pod）。
- 最后才杀Guaranteed（关键业务）。
日志：
kubectl get node显示MemoryPressure，Pod 状态变为Evicted。
操作系统层面的反应:
- 现象：如果内存增长太快，Kubelet 来不及反应，Linux 内核会介入。
- 后果：触发OOMKiller。内核会根据评分（oom_score）强制杀死占用内存最高的进程（通常是 Java 进程、数据库或 K3s Server 本身）。
- 日志：
/var/log/messages或dmesg出现大量Out of memory: Kill process ...。 - 对系统的影响：如果杀掉的是业务进程，业务挂掉；如果杀掉的是 SSHD 或 Systemd，服务器可能会死机或重启。
CPU 耗尽 (CPU Pressure) —— 变慢、假死
CPU 即使跑满 100%，通常也不会直接导致进程被杀，但会引发连锁反应。
现象：Load Average 飙升，系统响应极慢，SSH 登录卡顿或超时。
K8s 的连锁反应：
- 探针失败：业务处理请求变慢，导致 K8s 的Liveness Probe（存活探针）超时。Kubelet 认为容器死锁了，于是重启容器。
- Readiness 失败：业务无法及时响应，Readiness Probe失败，Service 切断流量，导致业务不可访问。
- HPA扩容：如果配置了自动扩容，Pod 数量会增加，反而进一步消耗资源（如果节点资源不足）。
磁盘空间耗尽 (Disk Pressure) —— 写入失败、服务崩溃
K3s/K8s 极其依赖/var/lib/rancher/k3s和/var/lib/docker（或 containerd）。
现象：
- ImageFS Pressure:容器镜像占满了磁盘。Kubelet 会开始删除未使用的镜像和停止的容器。
- NodeFS Pressure:整个文件系统满了。
后果：
- Pod无法启动：无法拉取新镜像 (
ErrImagePull)。 - 日志丢失：
/var/log满了，你看不到报错日志。 - 业务崩溃：数据库（MySQL/Redis）或应用无法写入临时文件或日志，直接报错退出。
- K3s 崩溃：etcd（K3s 自带数据库）如果无法写入磁盘，整个集群会挂掉，kubectl 命令失效。
- Pod无法启动：无法拉取新镜像 (
PID 耗尽 (PID Pressure) —— 无法创建新线程
这种情况常发生在高并发的 Java 应用或遭遇“Fork 炸弹”时。
- 现象：内存还有空余，但无法启动新进程或线程。
- 报错：
Resource temporarily unavailable或Cannot allocate memory(尽管内存够)。 - 后果：Kubelet 报
PIDPressure，开始驱逐 Pod。SSH 甚至可能都登不上去，因为 SSH 登录需要 Fork 一个新进程。
可能性三：K3s/K8s 的某些激进策略 (较少见)
虽然 K8s 通常只会重启 Pod，但在极少数配置下（如节点自愈脚本），如果节点判定自身状态极差，可能会触发节点重启。但概率低于前两者。
可能性四：云平台控制台操作
日志里出现了虚拟机和宿主机（云平台）通信的组件。由于来自云平台控制台重启不会被识别为服务器用户，所有这也是排查方向。
- 场景：操作人员在云平台的控制台上，点击或者误操作了“重启实例”。
- 原理：云平台通过Agent或ACPI信号通知操作系统关机。这种操作不会在
last中留下登录记录，但会触发你在日志里看到的systemd正常关机流程。 - 验证方法：必须去云服务商的网页控制台，查看“操作日志” (Operation Logs)或“事件监控”。查看 1月4日 21:06 分左右是否有“重启实例”的记录。
三、 排查集群为何未自动恢复
正常情况下，服务器重启后，systemd 应该自动启动集群，集群会自动拉起容器。如果存在未自动恢复的情况需要排查。
检查集群服务是否开机自启
如果服务器重启后集群没起来，可能是没有 enable 服务。
#kubelet 自动启动 = 集群自动恢复 如果是k3s请使用k3s替换kubelet查询 systemctl is-enabled kubelet # 如果显示 disabled，请执行： systemctl enable kubelet查看集群服务启动日志
检查 K3s 自身是否有报错：
systemctl status kubelet # 查看 K3s 服务的详细日志 journalctl -u kubelet -e --no-pager检查 Containerd日志
K3s 默认使用 containerd。如果 K3s 起来了但容器没起，可能是运行时的问题。
# 通常日志在 /var/lib/rancher/k3s/agent/containerd/containerd.log# 或者直接看 journal #k3s-agent journalctl -u containerd三、 常见原因总结与对策
根据经验，异常重启通常由以下几个原因导致：
资源耗尽 (OOM):
- 现象:日志里有 “Out of memory: Kill process”。
- 对策:给 Pod 设置 resources limits（资源限制），或者增加服务器 Swap/内存。
云服务商/硬件维护:
- 现象:系统日志里突然中断，没有任何报错，再次启动通过
last reboot能看到时间。 - 对策:去阿里云/腾讯云/AWS 的控制台查看“站内信”或“事件监控”，看是否有物理机迁移或维护重启。
- 现象:系统日志里突然中断，没有任何报错，再次启动通过
磁盘写满:
- 现象:
/var/lib/rancher/k3s所在分区满了，导致组件崩溃。 - 排查:
df -h查看磁盘使用率。
- 现象:
定时任务或者脚本
- 现象:某个脚本命令试图自动修复或者占用了大量资源导致节点资源耗尽。
- 排查:crontab -l查看定时任务或者相关脚本
建议后续操作
为了防止下次重启后服务无法访问，请确保执行以下操作：
- 设置开机自启:
systemctl enable kubelet。 - 检查重启策略:确保你的 Deployment/StatefulSet 的
restartPolicy是Always。 - 持久化日志:确保
/var/log/journal目录存在，以便journalctl能保存重启前的日志。
