一个人扛起AI平台运维：从K8s到监控日志的落地攻略

运维同事提离职那天，给我留了句“服务器列表在共享文档里，中间件密码在Wiki上，遇到问题先看日志”，然后头像一灰，再也没出现过。我接手的是一个部署在几十台裸金属上、上面跑着模型推理、训练任务、向量检索、内部API网关、定时批量作业以及一堆“不知道谁在用”的容器的私有化AI平台。说实话，头两周我的真实状态是：能跑就不敢碰，一报警就手抖。

但三个月过去，这个平台不但没崩，我还能腾出时间把整个运维体系重新捋了一遍。这套接管方案不依赖任何高级职称，核心就是：先把家底盘清楚，再把K8s和容器运行时搞明白，然后用监控、日志、脚本把自己从“人肉告警接收机”里解放出来，最后把单点风险一个个堵上。如果你也遇到类似情况——被迫一个人接管一个还在运行的AI平台，或者想在团队缩编时保住自己的下限，这篇内容应该能给你一套可以直接抄的落地思路。

1. 接手第一周：先把家底盘清楚，再谈扛不扛得住

1.1 离职交接的正确打开方式

同事离职时给的文档，大部分情况下是“回忆录”而不是“操作手册”。写的人觉得一目了然，看的人往往一头雾水。我接手的那个共享文档里，只有服务器IP和十几条“某服务在哪台机器”的说明，但中间件密码存放在公司内部的密码管理工具里，K8s的kubeconfig在离职同事的本地目录，Harbor仓库密码写在另一个文档的复制粘贴记录里。这种东西根本没法用。

我花了一周时间，按下面这个清单去摸底。每一个系统都要能回答：地址是什么、账号在哪、密码在哪、谁来负责、出问题重启方式是什么。

• SSH登录方式：密码还是密钥？密钥文件在哪？
• K8s集群信息：几个Master、几个Worker、kubeconfig在哪、证书什么时候过期
• 容器运行时：是Docker还是containerd，有没有配套的crictl
• 中间件清单：MySQL、Redis、Elasticsearch、etcd、对象存储各自在哪台机器，账号密码在密码管理器里的路径
• 对外入口：Nginx/Ingress/Gateway，域名和证书对应关系
• 定时任务：crontab、K8s CronJob、脚本、依赖哪些环境变量
• 备份情况：有没有备份脚本？备份到哪？上一次成功是什么时候？
• 历史故障记录：群里搜“挂了”“报错”“重启”这些关键词，能捞出大量线索

这个阶段不要急着优化，先做到“任何一台机器出问题，我能在一小时内定位到它在整体架构里的位置”。我把整理结果做成了资产台账，后面所有排障都基于它。

1.2 二次加工：把聊天记录变成可执行台账

离职同事没写进文档的细节，其实都在聊天记录和历史命令里。我翻了一遍工作群和他的终端历史，整理出很多“口口相传”的关键信息。比如某个训练任务跑挂了之后，群里的原话是“重启一下Pod就行”，但我后来看到完整日志才明白，真正的操作是：“先删掉残留的NFS挂载目录，再调整Pod的重试参数，最后再重启。”重启只是表象，完整流程才是知识。

我把这些碎片信息统一整理成表格，字段如下：系统名、IP、用途、端口、账号位置、证书到期时间、重要程度（P0/P1/P2）、重启方式、已知坑。然后同步到一个大家都能访问的Wiki或文档仓库里。这一步很枯燥，但极其值钱。因为一个人运维的时候，最大的敌人不是技术难，而是“想不起来上次是怎么处理的”。

1.3 关键资产清单样例

下面是我梳理台账时用的结构，供你参考。注意IP这类信息脱敏处理：

这个台账花了一个下午弄完，但后续每个排障场景都在复用。而且它让我对平台的依赖关系有了整体感，比如“训练服务挂了，不一定先怀疑训练代码，也可能是因为MinIO的AccessKey过期了”。

2. Kubernetes 和 containerd：弄懂这一层，心里就不虚

2.1 kubelet 怎么把任务交给 containerd

AI平台大概率跑在Kubernetes上，而现在的集群基本不再依赖Docker，底层的容器运行时是containerd。刚接手时我对“kubectl和docker命令有什么区别”“为什么crictl ps看不到镜像”这些非常困惑。后来把链路捋清楚，就简单了。

当你执行kubectl apply -f deployment.yaml时，请求发给API Server，控制器把Pod的期望状态写入etcd，调度器选出一个合适的节点，然后该节点上的kubelet会通过CRI（Container Runtime Interface）这个标准接口，调用containerd的gRPC服务去创建容器。containerd会为每个Pod里的容器单独拉起一个containerd-shim进程，再由这个shim调用runc去真正启动容器进程。runc负责Linux命名空间和cgroups的创建，从而隔离权限、文件系统、网络和资源限制。

这一层搞懂以后，排障思路就清晰了：Pod起不来，先看kubelet有没有把Pod调度到节点；容器没起来，看containerd和shim的日志；进程本身报错，才轮到看业务日志。我见过不少人卡了半天，其实问题出在节点上磁盘满了，kubelet同步Pod状态失败，根本和业务代码没关系。

2.2 排障四件套：kubectl、crictl、ctr、journalctl

很多人刚接手机器时习惯找docker ps，但如果节点上只装了containerd，这个命令会直接报错。我的日常排障主要靠下面这四类命令，建议直接收藏：

• kubectl：面向集群，常用kubectl get nodes -o wide、kubectl get pods -A | grep -v Running、kubectl describe pod xxx、kubectl logs -f xxx --tail=200
• crictl：面向节点上的容器，是CRI的标准命令行工具，crictl ps -a看容器状态、crictl logs <containerId>看容器日志、crictl exec -it <containerId> sh进容器、crictl images看镜像
• ctr：面向containerd自身的命令，主要处理镜像导入导出这种底层操作，比如ctr -n k8s.io images export xxx.tar
• journalctl：看系统服务日志，比如journalctl -u kubelet -f，能够看到kubelet向API Server同步状态的详细过程

我记得有一次某个推理服务一直CrashLoopBackOff，kubectl logs看不到任何有效输出，但用crictl logs能看到容器在启动阶段就因为内存不足被内核杀掉，再配合journalctl -k | grep -i oom，很快就定位到是显存分配策略的问题。理解了这套命令链，排障就有了抓手。

2.3 GPU节点的特殊照顾

AI平台和普通业务系统最大的区别，就是GPU资源和显存管理。接手后我重点检查了GPU节点上的两个东西：NVIDIA驱动是否和底层内核版本匹配，以及nvidia-device-plugin这个DaemonSet是否正常工作。

正常情况下，GPU节点安装了NVIDIA驱动之后，再跑一个nvidia-device-plugin的Pod，它会把节点上的GPU数量和型号上报给kubelet，这样你在Pod里就能用resources.limits.nvidia.com/gpu: 1来申请一张卡。我踩过的坑是：升级内核之后驱动模块没重新编译，导致设备插件一直报错，节点上的GPU数量显示为0。

验证GPU是否被正确分配，我的习惯是：kubectl exec -it <pod> -- nvidia-smi。如果能看到显卡信息，说明设备插件正常；如果只能看到一张虚拟卡，说明是MIG切分模式，需要确认推理框架是否支持MIG；如果直接报“NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver”，优先检查宿主机驱动和容器内驱动版本是否兼容。

2.4 多模型服务的隔离与配额

AI平台后面会挂很多团队的不同模型服务，如果每个服务都想用全部资源，早晚会出事。我的做法是：按团队或业务域划分namespace，给每个namespace配置ResourceQuota和LimitRange，并设置好节点的污点与亲和性。

比如给推理服务所在的namespace设置内存配额上限，防止某个团队把整个节点打满；给训练任务单独划分节点池，用nodeSelector或者nodeAffinity把训练和推理隔离。这是最简单的防互相干扰手段，配置成本很低，但能避免很多“下午三点某团队跑了个大模型批处理任务，晚上所有人服务一起变慢”的尴尬。

3. 从“人肉运维”到“脚本+监控+日志”最小闭环

3.1 先盘清服务启动方式

接手时我发现一个要命的问题：不同的服务用了完全不同的部署方式。有的在K8s里，有的用Docker Compose，有的是裸机启动的Python进程，还有几个靠crontab里挂着的shell脚本重启。这种混乱是历史包袱，但一个人运维时最怕的就是“不知道去哪看服务状态”。

我花了一天时间，把所有服务的启动方式列成了一个速查表：

这件事的意义在于：出问题时，我能在30秒内判断该去哪里看状态，而不是逐个机器试。这也是后面自动化操作的基础——机器都没分清，怎么敢让脚本去重启。

3.2 监控告警：一个人也要有“值班机器人”

一个人不可能24小时盯控制台，所以监控告警必须做。我推荐一个不重但很强的组合：Prometheus + Grafana + Alertmanager，配合node_exporter、kube-state-metrics、cadvisor和dcgm-exporter采集指标。这套方案开源、资料多、一个人也能维护得了。

告警规则我按优先级分了三层：

• P0：节点NotReady、关键服务Pods状态非Running持续5分钟、GPU任务大量失败、磁盘使用率超过85%
• P1：CPU/内存使用率长时间超过85%、证书剩余天数小于30天、备份任务执行失败
• P2：普通服务Pods多次重启、某个命名空间资源使用量接近配额

每个告警都要写清楚“怎么判断、怎么处理”，不然凌晨三点收到短信也是白搭。告警渠道我接入了企业微信和钉钉的Webhook，规则里尽量加for: 5m，避免瞬时抖动导致半夜误报。

3.3 日志：别等出问题时再找日志在哪

AI平台的日志量很大，尤其是推理服务和训练任务，滚动速度惊人。我见过最惨的情况是：容器日志全都写到了宿主机的/var/log/pods目录，没人做轮转，磁盘直接被打满。后来我用Loki + promtail做了一个集中日志方案，每个节点上跑promtail采集Pod日志，Grafana里能按服务名和namespace快速检索。

当然，如果你们已经有EFK（Elasticsearch + Filebeat + Kibana），完全可以沿用。但我个人在一个人运维的场景下，倾向轻量级方案，因为Elasticsearch本身就是个需要照顾的“大象”。日志至少保留7天，关键服务保留30天。日志的价值不只是排查问题，还能做简单的趋势分析，比如某个模型服务的请求量上涨是不是导致了GPU内存增长。

3.4 一键巡检脚本：每天早上省我半小时

每天到工位第一件事，我会跑一遍巡检脚本，把整个平台的关键状态一次性拉出来。脚本是纯bash + kubectl + python写的，输出一个人类可读的报告，核心检查项如下：

• 所有节点状态是否Ready，内存/磁盘/负载是否超阈值
• 所有namespace下是否有非Running的Pod，Pods最近是否有异常重启
• GPU节点是否还能识别到预期数量的显卡
• 证书剩余天数，包括K8s集群证书、Ingress证书、etcd证书
• 备份任务昨天的执行结果
• 镜像仓库、数据库、Redis等关键中间件的连通性

前期我还会在报告里打印出来，群里的负责人看着也放心。但这还不是终点，我会定期把巡检输出结果接入告警，比如某个节点磁盘超过80%就自动发告警，而不是等巡检时才发现。这个思路的核心是：巡检发现的问题，最终都要变成被动监控的一部分，否则每次都是“事后补救”。

4. 接管初期，我踩过的五个真实故障

4.1 日志把磁盘塞满，服务全部进入“假死”

第一个大教训来自磁盘。某个下午先是监控报警“节点磁盘使用率92%”，我登录上去看到/var/log目录已经塞满，再往下查发现容器日志文件单个已经几个GB，而且没有轮转。Pod还在写日志，但因为磁盘满了，kubelet同步状态失败，节点被标记为NotReady，上面的服务全在“假死”状态。

处理分两步：第一，先安全释放空间，用truncate -s 0 /var/log/containers/xxx.log而不是rm，因为日志文件被容器进程持有，rm之后空间并不会立即释放，反而可能造成日志丢失。第二，配置日志轮转，在/etc/docker/daemon.json或containerd的配置里设置max-size=100m、max-file=3，同时给journald设置SystemMaxUse=500M。这个配置要提前加，不要等磁盘满了才想起来。

4.2 证书过期引发的集群信任危机

K8s集群内部通信靠证书，etcd、kubelet、kubeconfig都有自己的证书。有一次运维同事走之前，集群证书已经悄悄过期，我执行kubectl get nodes一直报“certificate has expired or is not yet valid”。一开始我以为网络问题，后来排查才发现是kubeadm生成的证书到期了。

处理方法是：备份好/etc/kubernetes目录后，执行kubeadm certs renew all，然后重启kubelet和相关控制面组件（如果证书是apiserver等组件在用，需要滚动重启这些Pod）。之后更新所有节点的kubeconfig文件。这个事最大的教训是：证书管理必须进巡检项。我现在会在所有证书到期前90天就自动告警，而且Ingress的TLS证书也不能漏，很多平台入口出问题都是因为浏览器端证书悄悄过期。

4.3 镜像仓库故障，离线包救命的经过

Harbor仓库是AI平台最关键的中间件之一，因为新服务拉镜像都要经过它。有一次Harbor所在节点的磁盘满了，数据库写入失败，镜像仓库直接变成只读状态，随后模型服务发布失败、新Pod卡在ImagePullBackOff。

我当时的处理是：先重启Harbor服务，把它的日志目录和垃圾回收功能开启，清理掉旧的未引用的镜像，确保磁盘释放。然后我发现一个更深层的问题——只靠一个Harbor仓库，它就是单点。所以我在两个不同机房各起了一个镜像仓库，关键服务的基础镜像在发布前就同步到两个仓库，应用配置里用“仓库域名+镜像标签”的方式，如果主仓库挂了就切换到备仓库。

如果是完全隔离的网络环境，还有一个更稳妥的兜底：把核心镜像定期导出成tar包，存到独立存储里。真到镜像仓库彻底不可恢复的时候，还能用ctr -n k8s.io images import把镜像导回节点。

4.4 GPU服务OOM：显存泄漏的定位方法

推理服务跑着跑着开始频繁重启，kubectl describe pod里看到Last State: Terminated、Reason: OOMKilled。一开始我以为是业务代码问题，后来排了一遍才发现，是某个推理框架在处理长序列时显存占用不断增长，最终触发了容器的内存Limit。

排查思路供参考：先用kubectl top pod看内存趋势，再用dmesg | grep -i kvm看内核有没有报OOM事件，最后登录节点用nvidia-smi检查单个进程的显存占用。如果确认是框架的问题，有两个方向：一是调整推理框架的显存复用策略，比如vLLM的连续批处理和前缀缓存；二是给Pod设一个合理的显存Limit，防止一次爆掉整张卡甚至整个节点。

这事的另一层教训是：很多AI服务的“资源爆炸”不是突然发生的，而是随着请求量缓慢上升。所以只做静态限制不够，我还要做显存和内存的长期趋势监控，比如dcgm-exporter采集GPU显存使用率，连续上升N分钟就告警。

4.5 配置漂移：谁动了我的YAML

有一台GPU节点的内核参数被改成和集群其他节点不一致，导致调度到这台机器上的Pod总是性能异常。我查了一圈，发现是之前某位同学在排查问题时临时动过sysctl配置，但没记录。再一看，很多节点的配置文件里都有一些小差异，比如cgroup版本、预留内存大小、GPU驱动版本，这些差异平时看不出来，一到高负载就集体爆发。

我后来做的调整：把节点配置纳入版本管理，用一套自动化脚本统一初始化参数；所有配置变更必须记录变更人、时间和原因；每周巡检时对关键配置文件做一次MD5校验，谁改过一眼就能看出来。一个人运维，最怕的不是犯错，而是犯错之后不知道谁改了什么。配置漂移控制越早做越好，否则后面每个节点都变成“独特的孤岛”。

5. 工具选型：一个人的团队，别引入你养不起的系统

5.1 命令行不是没有价值，但要合理解放自己

很多刚接手的人会陷入一个误区：觉得自动化就是搭一堆可视化平台，然后什么都点点点。但真实环境是，命令行和脚本依然是最高效的排障手段，尤其是当问题出在容器运行时、内核、网络栈这些底层时，可视化平台往往帮不上忙。

我的决策原则很简单：一次性的紧急排障，直接用命令行；重复执行两次以上的操作，必须写成脚本；脚本再配合定时调度变成自动化任务；自动化任务的结果接入告警和报告。命令行、脚本、监控平台这三者的关系不是替代，而是递进。

5.2 可视化工具只选“轻量能干活的”

一个人运维，最大的限制是精力。我踩过坑，比如照着教程搭了一套很全面的“运维中台”，结果部署完发现根本没人用，还得每天照顾它自己。后来我收敛方案：Web终端类工具解决“在浏览器里能快速登录服务器”的问题；简单的任务面板负责展示巡检结果、告警历史和定时任务状态；其他能力则直接复用Prometheus、Grafana、Alertmanager这些成熟的生态。

关于“桌面运维助手”这类工具，我现在看到很多人在讨论。我的建议是：如果是完全内网环境，优先选择开源、能看源代码、能导出数据的方案，不要把核心资产绑定在一个你无法控制的黑盒上。轻和简单是两个关键词，不要让工具本身成为新的负担。

5.3 备份与恢复：先保证能回到昨天

一个人扛整个平台，最怕的不是服务挂了，而是挂了之后数据丢了。所以备份必须优先做。我的备份范围包括：

• K8s集群元数据：etcd快照，可以支撑集群重建
• 业务数据库：MySQL用mysqldump或物理备份，Redis做RDB持久化
• 配置文件包：所有节点的关键配置、Helm values、Nginx/Ingress配置、环境变量
• 模型权重和镜像清单：模型文件存对象存储，镜像导出成tar文件
• 对象存储自身：如果是MinIO，要有跨存储节点冗余策略

我写了一个backup.sh，把上面这些任务统一调度，每天凌晨跑一次，备份文件传到独立的备份存储节点，并且保留最近7天和每月的归档。最关键的经验是：备份一定要做恢复演练。我试过发现自己“以为的备份”根本没法恢复——比如etcd快照没带证书、数据库dump文件不完整。从那之后，我每个月会在测试环境完整演练一次恢复流程。

5.4 知识库：让判断和执行可复制

一个人运维，你的价值不止是“会修”，而是“能记录下为什么会坏、怎么修、下次怎么防”。我给自己建了一个简单的知识库，每个故障都按下面这个模板记录：

• 问题是什么
• 现象是什么（包括监控截图、日志片段）
• 排查过程（按时间线记录做了哪些操作）
• 根因是什么
• 解决方案是什么
• 预防措施是什么（是否要加告警、是否要改配置、是否要更新文档）

这个模板帮我避免了很多重复劳动。比如有一次模型服务又出现和上次一样的重启问题，我直接在知识库里搜到上次的完整排查过程，十分钟就定位了，而不是再从零开始看日志。这也是我推荐的“离职保险”——就算哪天我也要离开，这套文档能让下一个人少走一半弯路。

6. 单点风险治理：防止下次再被离职“坑”一次

6.1 账号权限与密钥：离职前我没拿到的，现在都要有

接管一个月后，我做了一次彻底的账号和密钥盘点。首先要处理离职同事遗留的SSH密钥，确保它从所有节点的~/.ssh/authorized_keys和K8s管理员权限中移除。同时，所有核心系统的密码——数据库、Redis、Harbor、对象存储、密码管理器本身——全部轮换一遍，确保旧账号不再具备访问能力。

其次是权限边界。很多内部系统当初为了方便，给了所有人最高权限，但对一个有AI平台的团队来说，这是巨大的风险。我按“最小可用权限”原则重新划分：运维和管理员账号能操作K8s的整个集群；开发和算法团队只给它们自己namespace的只读权限或少量操作权限；业务系统之间通过ServiceAccount互通，尽量不给长期有效的kubeconfig导出。

6.2 账号权限矩阵：明确到什么程度才算安全

我维护了一个权限矩阵表格，记录每个系统/平台谁有管理员、谁有普通用户、谁只能只读。权限调整记录同步保存。这听起来很“管理”，但对一个人运维的场景帮助极大——因为当你需要排查“谁改了这个配置”的时候，没有权限矩阵就是大海捞针。

另外，我强烈建议把所有密码从Excel和微信聊天里搬到一个受控的密码管理器里。因为安全性不只是“不能泄露”，更重要的是“一个人突然不在的时候，其他人能不能接管”。密码管理器可以配置紧急访问机制，比存在个人笔记里安全得多。

6.3 自动化率自查：重复两次的操作必须脚本化

每个月我会做一次“自动化率自查”，把过去一个月里手动操作过的服务器命令全部翻一遍，凡是出现两次以上的操作，立即考虑脚本化。比如：“重启某个状态异常Pod”“清理某个目录下的旧日志”“检查某个服务证书剩余天数”，这些全部可以写成函数、脚本或者Ansible Playbook。

我做了一个简单的评估表，帮助自己判断哪些该优先自动化：

目标很简单：把重复性的、机械的、容易出错的劳动量降到零，把精力留给架构优化和真正的故障处理。

6.4 故障复盘模板：让每次事故都成为资产

每次故障处理完，我都会写复盘。这个习惯在最忙的时候也被我保留了，因为AI平台的服务链很长，一个问题往往涉及多个环节，不记下来下次遇到可能还是从头排查。我用的复盘模板并不复杂：发生了什么、影响范围、根因、恢复动作、改进项。

改进项是重点。每条改进项尽量写成可执行的任务，比如“添加磁盘使用率超过80%的告警”“将Harbor备份加入每日备份任务”“将XX服务的资源限额改为显存上限的1.5倍”而不是“加强监控”“提升稳定性”这种空话。一段时间之后再回看，这些改进项就是平台稳定性逐步上升的过程记录。

6.5 一些个人体会

接管这个AI平台三个月，我发现最值钱的东西不在于我掌握了多少K8s或GPU细节，而在于我能不能让整个平台在“只依赖我”的前提下稳定运转。从焦虑到从容，靠的是三件事：可回滚的备份、看得见的监控、写下来的知识。有一句话我一直记着：“运维的安全感不是来自你有多能修，而是来自你知道所有东西在哪、怎么备份、怎么恢复。”

如果你也正在经历一个人扛起整个平台的状态，我的建议是：第一周别急着做任何激进优化，先把“暂停键”找到——也就是知道每个服务在哪、怎么停、怎么启动、数据在哪；第二步做最小闭环的监控和备份，保证出事后能回到昨天；最后才是优化、自动化和架构调整。有些弯路我替你走过了，希望这套方案能让你少慌几周。