进容器查故障，连 ls 都没了怎么破？
今天被一个线上告警折腾得够呛，想吐槽一下现在搞云原生架构的。大模型推理节点突发算力波动，我怀疑撞了温度墙。火急火燎 docker exec 进 dcgm-exporter 容器，想去改底层的 GPU 降频指标（这玩意儿默认不开）。习惯性敲了个 ls 找文件，结果屏幕直接弹出：bash: ls: command not found我愣了，心想装个包吧，敲 apk add vim，结果连 apk 都给我拔得一干二净！😂好家伙，传说中的 Distroless 极度纯净镜像。平时看着挺高级，一出故障想进去找个文件，简直像进了毛坯房。不过骂归骂，线上容器绝对不能乱装工具，那是大忌。老油条只能硬着头皮破局：✅ 第一招：纯原生 Bash 查询。不用外部依赖，直接用 Bash 自带的机制展开目录，敲一个：echo * 就完美解决了没 ls 的尴尬。✅ 第二招：写精准告警。很多人监控降频直接写数值 > 0，结果天天被正常的功耗墙报警轰炸。我反手写了组规则，用状态码精准捕捉（见图3）。避开无意义的功耗墙，专门抓温度（2）和供电（4）引起的真故障。✅ 第三招：外围降维打击。其实压根不用进容器死磕。退回宿主机，直接 curl 抓宿主机 9400 端口，看底层的降频状态码（见图5、图6）。踩过坑才明白，平时背那么多命令没用，遇到极端环境，还得靠底层原理来保命。大家遇过哪些让人哭笑不得的“纯净”镜像？评论区吐吐槽👇运维 踩坑日记 gpu kubernetes 云原生 Docker linux运维 程序员吐槽