企业官网建设流程全解析

专门建设网站的公司,网站建设和发布的一般流程图,手机有些网站打不开怎么解决,帮客户做网站 没签合同咋办前言 针对服务器异常重启且服务未自动恢复的情况#xff0c;排查思路需要分为 “ 操作系统 /硬件层面” 和 “K8s/容器层面” 两个方向。 一、 排查操作系统为何重启 首先需要弄清楚是掉电/硬件故障#xff0c;还是系统崩溃#xff0c;或者是内存不足#xff08;OOM#x…前言针对服务器异常重启且服务未自动恢复的情况排查思路需要分为“操作系统/硬件层面”和“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 100MiKubelet 会触发MemoryPressure状态。后果Kubelet 开始驱逐Pod。它会根据 QoS 等级服务质量来杀 Pod先杀BestEffort没设置 limit/request 的 Pod。再杀Burstable使用了超过 request 内存的 Pod。最后才杀Guaranteed关键业务。日志kubectl get node显示MemoryPressurePod 状态变为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 崩溃etcdK3s 自带数据库如果无法写入磁盘整个集群会挂掉kubectl 命令失效。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能保存重启前的日志。