春招运维面试题拆解：Linux、Shell、Kubernetes 排障复习路径

简介这份PDF面向备战技术岗春季招聘的运维工程师求职者尤其适合具备一定工作经验与技术基础的候选人用于系统梳理高频考点、查漏补缺并提升面试应答能力。内容按Linux系统管理与Shell脚本、TCP/IP协议栈与安全防护、自动化工具与监控设计、Docker与Kubernetes云原生运维、综合故障排查与开放性问题五大模块组织每道题均附参考答案与延伸思考如日志清理命令、服务监控脚本、SSH防暴力破解、CPU飙升定位、Deployment滚动更新与回滚等实战场景。资源包共1个PDF文件约867KB轻量便于随时查阅。目前已有74人学习。读者可借此掌握常见运维技能结合动手实验与模拟面试强化记忆并针对开放性问题先独立思考再对照答案锻炼独立排障与方案设计能力。1. 春招运维岗面试题拆解从 PDF 目录到能答出细节的复习路径春招投运维工程师很多人手里都会拿到一份「高频面试题附参考答案」的 PDF翻两页就发现一个尴尬题目看着都眼熟Linux 常用命令、Shell 脚本、Kubernetes 集群可真被追问一句「为什么这么写」「线上出问题你怎么查」答案立刻塌掉。这份 PDF 的价值不在背答案而在于它其实是一张能力地图——把运维工程师面试题按 Linux、Shell、Kubernetes 三条主线铺开每道题背后都对应一个真实排障场景。这篇笔记不逐题抄答案而是把这份 PDF 拆成可复现的复习路径哪些题必须动手敲一遍、哪些参数面试官一定会追问、哪些「标准答案」其实是坑。适合正在准备春招的应届生和转岗运维的开发者也适合工作一两年想系统补基础的人。读完你应该能自己判断这道题我到底是「背过」还是「会做」。2. Linux 高频题从命令背诵到排障思维Linux 面试题是运维岗占比最大的一块也是最容易露馅的一块。面试官问「查看端口占用」不是想听你背netstat -tunlp而是想看你会不会在容器里发现 netstat 根本没装、然后换成ss或读/proc。这一章把 PDF 里最高频的几类 Linux 题拆成「命令 → 原理 → 追问」三层每层都给出可以直接在虚拟机上复现的操作。2.1 进程、端口、负载三道必考题的动手验证先看进程和端口。面试常问「怎么查某个端口被谁占用」标准回答是lsof -i:8080或ss -lntp | grep 8080。但真正拉开差距的是追问如果这两个命令都没有呢在精简镜像里常见做法是直接读/proc/net/tcp把十六进制端口换算回来。下面这段脚本演示了不依赖任何额外工具定位端口占用的思路。# 不依赖 lsof/ss直接解析 /proc 找监听端口 # 8080 的十六进制是 1F90/proc/net/tcp 里端口字段是大端十六进制 target_hex$(printf %04X 8080) awk -v port$target_hex NR1 $40A { # 0A 表示 LISTEN 状态 split($2, local, :) if (local[2]port) { print inode:, $10 # 第 10 列是 socket inode } } /proc/net/tcp # 拿到 inode 后去 /proc/*/fd 里反查属于哪个进程这段脚本的关键参数是$40A0A是/proc/net/tcp中 LISTEN 状态的编码很多人第一次看会以为是端口。$2是本地地址格式是IP:PORT端口用十六进制表示所以要先printf %04X转换。拿到 inode 后用ls -l /proc/*/fd 2/dev/null | grep inode就能定位进程。这套流程在容器排障里非常实用因为生产镜像经常连ps都是裁剪过的。再看负载。面试问「load average 高怎么办」背「看 CPU 核数」只是入门。真正要答的是load 包含运行态和不可中断睡眠态D 状态进程所以 IO 卡住时 load 也会飙高但 CPU 是闲的。验证方法是vmstat 1看r列运行队列和b列阻塞进程。如果b列持续大于 0 而ussy不高基本可以判定是 IO 或锁等待而不是 CPU 不够。这个判断在面试里说出来比背定义强得多。2.2 磁盘与内存df 和 du 不一致时怎么查「磁盘满了但du找不到大文件」是运维面试的经典陷阱题也是线上真实会翻车的地方。现象是df -h显示某个分区 100%但du -sh /*加起来对不上。原因通常是文件被删除但进程还持有句柄空间没释放。排查命令是# 找出已删除但仍被进程占用的文件 lsof L1 2/dev/null | awk $5REG $7 ~ /^[0-9]$/ {print $1, $2, $7, $9} # 或者用 /proc 直接看 for pid in /proc/[0-9]*; do ls -l $pid/fd 2/dev/null | grep deleted donelsof L1里的L1表示 link count 小于 1也就是已经被 unlink 但还有引用的文件。输出里第 7 列是文件大小第 9 列是路径通常带(deleted)。解决办法不是删文件而是重启或 reload 持有句柄的进程。这个坑在日志场景特别常见日志被rm了但写日志的进程没重启磁盘一直不释放。面试时能讲清「df 看的是文件系统块du 看的是目录树两者视角不同」基本就过关了。内存题同理。free -h里available和free的区别是高频追问点。free是完全未使用的内存available是估算的「还能给新进程用多少」包含了可回收的 page cache。所以看到free很小不用慌看available才有意义。验证方法是cat /proc/meminfo重点看MemAvailable和Cached两行。2.3 权限与提权sudo 配置和 SUID 的边界权限题在春招里出现频率不低尤其是「普通用户怎么执行需要 root 的命令」。标准答案是配 sudo但面试官往往追问 sudoers 的写法。常见做法是用visudo编辑加一行deploy ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx注意命令要写绝对路径否则有被 PATH 劫持的风险。这里有个血泪经验NOPASSWD后面跟的命令如果带通配符比如/usr/bin/systemctl restart *等于把整个 systemctl 的控制权交出去了攻击者可以systemctl restart 任意服务。所以能写死就写死。SUID 的题一般问「怎么找系统里所有 SUID 文件」命令是find / -perm -4000 -type f 2/dev/null。-4000是 SUID 位。追问通常是「SUID 有什么风险」答「可以让普通用户以文件属主权限执行」即可再补一句「所以不该给 shell 类程序设 SUID」。这块不用展开太深面试官主要看你知不知道边界在哪。3. Shell 脚本题面试官想看的不是语法是健壮性Shell 脚本入门容易写好难。PDF 里的 Shell 题通常分两类一类考语法for 循环、shift、数组一类考场景日志切割、批量部署、监控告警。面试官真正在意的是第二类因为语法可以查健壮性只能靠经验。这一章按「语法陷阱 → 实战脚本 → 常见坑」推进每个脚本都能直接跑。3.1 for 循环、shift 和参数处理三个必知语法点Shell 脚本 for 循环的写法有好几种面试常考的是遍历命令输出和遍历数组的区别。直接for i in $(ls)是经典错误因为文件名带空格会被拆开。正确做法是用 glob 或while read# 错误示范文件名带空格会翻车 # for f in $(ls *.log); do echo $f; done # 正确做法一glob 直接展开 for f in *.log; do [ -e $f ] || continue # 没有匹配文件时 glob 不展开要判断 echo 处理: $f done # 正确做法二find while read处理任意文件名 find . -maxdepth 1 -name *.log -print0 | while IFS read -r -d f; do echo 处理: $f done-print0和read -d 配合用空字符分隔能处理带空格、换行的文件名。IFS是清空字段分隔符防止 read 自动 trim 首尾空白。这几个参数面试官很爱追问因为能看出你有没有被文件名坑过。shift命令考的是位置参数处理。常见场景是脚本要支持-f这种选项用while加case配合shift逐个消费参数#!/bin/bash set -euo pipefail # 出错退出、未定义变量报错、管道任一环节失败即失败 VERBOSE0 TARGET while [ $# -gt 0 ]; do case $1 in -v|--verbose) VERBOSE1; shift ;; -t|--target) TARGET$2; shift 2 ;; -h|--help) echo 用法: $0 [-v] [-t target]; exit 0 ;; *) echo 未知参数: $1 2; exit 1 ;; esac done echo verbose$VERBOSE target$TARGETset -euo pipefail是脚本健壮性的第一道防线-e让命令失败即退出-u让引用未定义变量报错-o pipefail让管道中任一命令失败都算失败。很多线上事故就是脚本里某个命令失败了但没退出继续往下跑导致的。shift 2是因为-t后面跟了一个值要一次消费两个参数。3.2 日志切割与监控脚本一个能直接用的模板面试常让手写「按天切割 Nginx 日志」或「磁盘超阈值告警」。这类题考的是流程完整性加锁防重入、错误处理、日志记录。下面是一个日志切割脚本的骨架#!/bin/bash set -euo pipefail LOG_DIR/var/log/nginx KEEP_DAYS7 LOCK_FILE/tmp/logrotate.lock # 用 flock 加锁防止 cron 重复触发 exec 200$LOCK_FILE flock -n 200 || { echo 已有实例在运行; exit 1; } YESTERDAY$(date -d yesterday %Y%m%d) for log in $LOG_DIR/access.log $LOG_DIR/error.log; do [ -f $log ] || continue mv $log ${log}.${YESTERDAY} # 通知 nginx 重新打开日志文件否则会继续写旧句柄 kill -USR1 $(cat /run/nginx.pid) done # 清理过期日志 find $LOG_DIR -name *.log.* -mtime $KEEP_DAYS -delete关键点是kill -USR1Nginx 收到这个信号会重新打开日志文件。如果不发信号mv 之后 Nginx 还持有旧文件句柄新日志会写到被 mv 的文件里df看着没释放。flock -n 200里的200是文件描述符编号-n表示拿不到锁就立即退出避免任务堆积。-mtime 7是 7 天前注意号别漏。3.3 Shell 中常见坑变量、引号和退出码Shell 的坑集中在三处。第一是变量不加引号$VAR在含空格时会分词应该写$VAR。第二是[ ]和[[ ]]的区别[[ ]]支持正则和且不会分词条件判断优先用它。第三是退出码$?只反映上一条命令管道里要用PIPESTATUS数组。举个例子# 管道退出码陷阱 grep ERROR app.log | wc -l echo $? # 这是 wc 的退出码永远是 0 echo ${PIPESTATUS[0]} # 这才是 grep 的退出码没匹配到是 1PIPESTATUS是 bash 特有数组记录管道中每个命令的退出码。写监控脚本时如果只判断$?grep 没匹配到也会被当成成功告警就漏了。这个点在面试里说出来面试官基本会点头。4. Kubernetes 面试题从 kubectl 到排障链路Kubernetes 是近几年运维面试的必考项PDF 里的题从「Pod 一直 Pending 怎么查」到「Service 访问不通怎么排查」都有。这一章的思路是不背概念按排障链路走一遍。每个问题都给出kubectl命令和判断依据让你在面试时能说出「先看什么、再看什么」。4.1 Pod 状态异常Pending、CrashLoopBackOff、ImagePullBackOff 的排查顺序Pod 起不来是最常见的面试场景题。第一步永远是kubectl describe pod name -n ns看 Events 区域。三种典型状态对应不同原因Pending 通常是调度失败Events 里会写Insufficient cpu或node(s) had taint。前者是资源不够后者是节点有污点没有对应 toleration。排查命令是kubectl describe node node看 Allocated resources以及kubectl get nodes -o custom-columnsNAME:.metadata.name,TAINTS:.spec.taints。CrashLoopBackOff 是容器起来了又退出反复重启。先看kubectl logs pod --previous--previous看的是上一次崩溃的日志因为当前实例可能还没输出就挂了。常见原因是启动命令写错、依赖服务连不上、配置文件挂载路径不对。如果日志为空看kubectl get pod pod -o yaml里的lastState.terminated.exitCode137 通常是 OOMKilled1 是应用自身报错。ImagePullBackOff 是镜像拉不下来。describe里会写具体错误比如manifest unknowntag 写错或unauthorizedimagePullSecret 没配或过期。验证方法是kubectl get secret name -o jsonpath{.data.\.dockerconfigjson} | base64 -d看里面的 registry 地址和认证信息对不对。4.2 Service 与 Ingress访问不通的四层排查法Service 访问不通是高频追问。按四层往下查Pod 本身 → Service endpoints → kube-proxy/iptables → Ingress。第一层确认 Pod 就绪。kubectl get pod -o wide看 READY 是不是 1/1kubectl get endpoints svc看有没有后端地址。如果 endpoints 是空的说明 Service 的 selector 没匹配到任何 Pod检查 label 是否一致。第二层Service 的 targetPort 和 Pod 的 containerPort 是否对得上。kubectl get svc name -o yaml看targetPortkubectl get pod pod -o yaml看ports.containerPort。常见错误是 targetPort 写了 8080 但容器实际监听 80。第三层集群内直接测。起一个临时 Podkubectl run tmp --rm -it --imagebusybox -- sh然后wget -qO- svc-name.ns.svc.cluster.local:port。如果通说明 Service 没问题问题在 Ingress如果不通看 kube-proxy 是否正常kubectl -n kube-system logs kube-proxy-pod。第四层Ingress。kubectl describe ingress name看 Rules 和 Events确认 host、path、backend service 都对。常见坑是 path 类型写错Prefix和Exact行为不同/api用 Exact 就匹配不到/api/v1。4.3 资源限制与调度requests/limits 怎么设才不翻车面试问「requests 和 limits 怎么设」很多人答「requests 设小点 limits 设大点」这是模糊的。正确理解是requests 决定调度节点要有这么多可分配资源才调度limits 决定运行时上限超了 CPU 被限流、内存被 OOMKill。所以 requests 要贴近实际用量limits 留合理余量。一个可复现的验证方法是压测观察。给 Pod 设limits.cpu500m然后用stress-ng打满看kubectl top pod是不是卡在 500m 左右同时看container_cpu_cfs_throttled_seconds_total指标是否上升。CPU 被限流的表现是延迟抖动不是直接报错所以很多人设了 limits 却没意识到性能被压了。内存更危险因为超 limits 直接 OOMKill没有缓冲。常见做法是 limits 设为 requests 的 1.5 到 2 倍同时配好 liveness probe让容器在假死时能自动重启。这里有个后悔药如果一开始不确定用量可以先不设 limits 只设 requests观察一段时间kubectl top再补比一上来设死导致频繁 OOM 强。5. 避坑与排查面试和线上都容易翻车的五个点这一章把前面散落的坑集中起来每条按「现象 → 原因 → 解决」写。这些点面试官很爱追问因为能区分「背过」和「做过」。现象一df显示磁盘满du找不到大文件。原因是文件被删除但进程仍持有句柄空间未释放。解决是用lsof L1或遍历/proc/*/fd找到 deleted 文件重启或 reload 对应进程。面试时补一句「日志场景最常见」会加分。现象二Shell 脚本里for f in $(ls)处理带空格文件名出错。原因是命令替换会按 IFS 分词。解决是改用 globfor f in *.log或find -print0 | while IFS read -r -d 。这个坑几乎每个写脚本的人都踩过。现象三Kubernetes Pod 一直 PendingEvents 显示0/3 nodes are available。原因是节点资源不足或有污点。解决是kubectl describe node看 Allocated resources确认是 CPU/内存不够还是 taint 没容忍。别急着重启 Pod调度问题重启没用。现象四Service 的 endpoints 为空但 Pod 明明是 Running。原因是 Service 的 selector 和 Pod 的 label 不匹配或者 Pod 没通过 readinessProbe。解决是kubectl get pod --show-labels和kubectl get svc -o yaml对比 label再检查 probe 配置。现象五set -e的脚本里grep没匹配到导致整个脚本退出。原因是grep没匹配时退出码是 1set -e会捕获。解决是用grep ... || true或if grep -q ...; then。这个坑在写监控脚本时特别常见因为「没匹配到」往往是正常情况。6. 把 PDF 变成自己的题库一套可复用的复习方法背答案的保质期只有一场面试把题目变成自己的排查习惯才能长期用。我自己的做法是给每道高频题建一个「最小复现环境」Linux 题开一台虚拟机Kubernetes 题用 kind 或 minikube 起单节点集群Shell 题直接写脚本跑一遍。下面这张表是我按题型整理的复习优先级你可以照着排自己的计划。题型复现成本面试出现频率建议投入Linux 命令与排障低虚拟机即可极高每天 30 分钟重点练/proc和lsofShell 脚本健壮性低本地就能跑高手写 3 个脚本切割、监控、批量部署Kubernetes 排障中需要集群高用 kind 起集群把 Pending/CrashLoop 各复现一次网络与 DNS中需要多节点中重点练 Service 四层排查监控与告警低本地可模拟中写一个磁盘阈值告警脚本一个具体技巧把每道题的答案压缩成「一句话结论 一条验证命令」。比如「load 高不一定是 CPU 问题」对应vmstat 1看b列「Pod Pending 先看 Events」对应kubectl describe pod。面试时先给结论再给命令比从头背定义显得有底气。另外参考答案里的命令最好都在自己环境里跑一遍跑不通的地方往往就是面试官要追问的地方。我自己的习惯是面试前一天不刷新题只把之前跑过的脚本和kubectl命令再过一遍重点看当时踩过的报错。有次面试被问到PIPESTATUS就是因为之前写监控脚本时被 grep 退出码坑过答得特别顺。这种「被坑过」的记忆比背十遍答案都牢。希望帮到你。本文还有配套的精品资源点击获取