金融隐士1. 合集六开篇之前，先把 Linux 命令效率这个老问题说透
这是我整理“Linux & Kubernetes 必学知识点合集”的第六篇。前几篇我分别梳理过系统启动、网络排查、容器运行时、存储挂载等方向，这篇不想继续按目录平铺，而是想聊一聊那些“看起来很简单，却在日常实操和面试交流中被反复拿出来讨论”的知识点。每个点我都会尽量把原理、排查链路和实际命令放到一起讲，而不是只丢结论。
之所以把“Linux命令效率”放在最前面，是因为我发现不少人虽然背了很多命令参数，但真正在处理服务器问题时速度并不快。问题往往不在“记没记住”，而在“有没有形成组合命令的习惯”。老手和新手拉开差距的地方，通常不是某个冷门参数，而是对管道、过滤器和文本处理工具的运用方式。
1.1 你缺的不是命令大全，而是管道思维
很多教程喜欢列出 100 条常用 Linux 命令，单看每条命令都很简单，可真到了生产环境，几乎没有哪个需求能靠单条命令完成。比如分析 Nginx 访问日志，最常见的需求是统计访问量 TOP 10 的来源 IP。新手可能会一条条查日志，或者在 Excel 里手工数；老手写出来就是这么一行：
bash复制awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 10
这行命令看起来简单，但里面包含了四个独立的处理动作：awk 负责从每一行日志中提取第一个字段作为 IP；sort 把相同 IP 排到一起；uniq -c 负责统计连续重复的行并计数；sort -rn 再按计数从大到小排列；最后 head 取前 10 行。整个过程像一条流水线，每个工具只负责一件事，再把结果交给下一个工具。
我见过不少人卡在“为什么要 sort 两次”这个问题上。uniq 去重统计的前提是相同内容必须连续，如果不先 sort，uniq 统计出的结果大概率是错的。这是管道思维中很典型的一点：不是会几个命令就行，而是要理解每个工具对输入格式有什么要求，然后主动为下一个工具准备合适的输入。
再举一个更贴近运维场景的例子。线上有一批配置文件需要批量把 IP 从旧地址改成新地址，新手会打开 vim 一个文件一个文件地改，老手会直接这样：
bash复制find /etc/myapp -type f -name "*.conf" -exec sed -i 's/192.168.1.10/192.168.2.20/g' {} \;
这条命令里的 find 负责找出符合条件的文件，-exec 把查到的每一个文件传给 sed 处理，sed 在 -i 参数下直接原地替换。如果不放心先看看哪些文件会被改动，可以先去执行不含 sed 的 find 部分，把文件列表打印出来确认一遍。这个习惯很重要，批量操作前先“空跑”一遍，能为你挡掉至少一半误操作。
1.2 把查找、批量替换和存档变成一条命令
管道思维还能帮你处理更复杂的组合场景，比如“把今天改过的配置打包备份”。如果你总是先一层一层 cd 进目录找文件，再手动打 tar，很容易漏掉那些分布在不同位置的配置。我的做法是用 find 按时间过滤，直接喂给 tar：
bash复制find /etc /opt/myapp -type f -mtime -1 -print0 | xargs -0 tar czf /backup/conf_$(date +%F).tar.gz
这里有一个容易踩的坑：如果文件名或目录名包含空格，直接用 xargs 会导致参数被错误拆开，必须用 -print0 和 xargs -0 组合，让文件名以空字符分隔而不是换行或空格分隔。在生产服务器上，目录名带空格的情况其实不少，文件系统本身允许这样做，只是命令行处理时需要多做一步防护。
另外我特别想建议每个做运维的人都建立一套属于自己的“命令备忘录”，而不是收藏一堆别人整理的“命令大全”。最简单的做法是利用 history：
bash复制history | grep "kubectl rollout"
这一条命令能帮你把之前用过的滚动更新操作原样翻出来，避免每次都要重新回忆参数，也避免因为一条命令不确定就在生产环境里翻来覆去试。只要命令被敲过一次，就有机会被检索到；偶尔还会发现一些当时写得很漂亮的长命令，顺手整理进自己的笔记。长期积累下来，这套备忘录比任何外部文档都贴合你手头这批机器的实际情况。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 磁盘“满了”却删不掉文件？一次讲清排查链路
Linux 服务器上有个出现频率极高的故障：应用突然报错说“No space left on device”，你上去一看 df -h 确实显示磁盘满了，但各个目录用 du 统计下来，加起来又没有占这么多，感觉空间“不翼而飞”。这类问题我在不同环境里遇过很多次，把完整的排查链路整理出来，下次遇到基本可以按图索骥。
2.1 三步定位法：空间满了先分清这几种情况
看到磁盘满后，第一步不是急着删文件，而是先弄清到底是哪种“满”。我一般按下面这个顺序执行：
bash复制df -h
df -i
du -sh /* 2>/dev/null | sort -hr | head -n 20
df -h 看的是块设备容量使用率，df -i 看的是 inode 使用率。两者可能完全不同：一个 100GB 的磁盘，如果上面堆了上百万个 1KB 的小文件，容量可能只用了 50%，但 inode 已经耗尽，系统同样会报“No space left on device”。而 du 统计的是目录树中的实际文件大小，如果磁盘上有文件被删除但还被进程持续占用，du 统计不出来这部分空间，df 却能看到它在使用。
这三个命令的输出一定要放在一起看。我的经验是，先看容量满没满；如果容量没满但 inode 满了，走小文件清理方向；如果容量和 inode 都正常，应用却报磁盘满，那就要查是不是挂载点被覆盖、是不是有已删除未释放的文件，甚至是不是文件系统本身出了问题。单靠一个 df -h 就下结论，很容易把方向带偏。
2.2 inode 耗尽：目录里有海量小文件
inode 耗尽最典型的现象是 df -h 显示还有几十 GB 空闲，但提示符下连临时文件都创建不了。常见的元凶有这几个：邮件服务器队列目录 /var/spool/postfix/maildrop、系统日志定时任务产生的碎片文件、Docker overlay2 目录下残留的临时层、还有应用自己写的缓存目录。
定位问题目录时，可以逐级使用 du 和 find 配合筛选：
bash复制du --inodes -d 2 /var/spool 2>/dev/null | sort -nr | head
如果发行版的 du 不支持 --inodes 参数（有些老版本不支持），也可以用 find 数目录下的文件数量：
bash复制find /var/spool/postfix -type f | wc -l
找到大量小文件之后，删除本身并不复杂，难的是判断哪些能删。有一个比较容易出事的点：有些程序会反复创建临时 pid 文件、lock 文件，一边创建一边删除，但因为并发太高，删除速度跟不上，最终堆满 inode。这种场景光删一次不够，你得去应用层调清理策略或改造文件存储方式。
2.3 文件被删除却仍被进程占用
比 inode 耗尽更难发现的是“进程占着已删除文件”导致的空间泄漏。表现是：你 rm 掉了一个超大日志文件，df 一看空间居然没有变化。原因在于，rm 只是把文件名从目录项中摘掉，文件本身还被子进程的文件描述符引用着，只要进程不退，空间就不会回收。
排查命令很直接：
bash复制lsof +L1
这个命令会列出所有被删除但仍处于打开状态的文件，L1 表示显示 link count 小于 1 的文件。看到结果后，一般有两个处理思路：如果这个进程是日志服务，比如 rsyslog、nginx、java 应用，重启对应服务让文件描述符重新打开；如果是某些可以随时拉起的应用，直接把进程重启即可。需要提醒一点：在生产上不要为了释放空间随意 kill 进程，先确认这个进程是什么、重启它会不会造成服务中断，必要时安排维护窗口操作。
lsof +L1 里还藏着另一个问题：日志文件被 rm 之后，程序还在持续往旧句柄里写数据，磁盘空间不仅没释放，反而继续增长，直到把磁盘彻底写满。遇到这种情况，正确的处理不是再次 rm，而是用 cp /dev/null 加 truncate 的方式把文件内容清空，或者直接重启进程让文件句柄重新指向新文件。
bash复制truncate -s 0 /proc/$(pidof app)/fd/$(ls -l /proc/$(pidof app)/fd | grep deleted | awk '{print $9}')
这个命令比较绕，我一般只在应急时用，平时更倾向于重启服务。你也可以先通过 lsof 看到进程 pid 和 fd 编号，再手工 truncate 对应句柄。核心思想是：让磁盘上的空间先被释放出来，保住业务，再考虑后续处理。
2.4 养成日志轮转的习惯
磁盘满问题里，日志文件是最大的一类来源。只要批量处理过几台机器，你就会发现很多服务默认不清理日志，或者应用自己用 nohup 重定向输出，日积月累生成几百 GB 的单个文件。这其实不是 Linux 本身的问题，而是日志管理策略缺失。
Linux 下最标准的做法是配置 logrotate，而不是用 cron 脚本 rm。logrotate 可以定义按大小或日期轮转、保留份数、是否压缩、轮转后是否执行 postrotate 脚本等策略。比如 Nginx 日志的典型写法：
text复制/var/log/nginx/*.log {
daily
rotate 14
compress
delaycompress
missingok
notifempty
create 0640 nginx adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}
这里 postrotate 段的 kill -USR1 是给 Nginx 发送重新打开日志文件的信号，让旧的日志句柄被释放、新的请求写进新文件里。这个细节很容易被忽略，如果日志文件已经被 rotate 了而服务还在往旧文件写，那 rotate 只是把文件名改了，本质上还是在写同一个 inode，真正的轮转并没有完成。
3. 用户管理和权限控制：从 useradd 到 sudo 提权的一整套动作
Linux 的用户管理看起来就是个 useradd 的事，可一旦涉及多人共管服务器、应用权限隔离、安全加固，很多细节就会暴露出来。这个合集里我专门把 Linux 用户这块拎出来，是因为它和“提权”“安全基线”离得最近。
3.1 useradd 补全流程，几个容易被忽略的选项
要在 Linux 上新建一个用户，很多教学文档会写成 useradd zhangsan，然后 passwd zhangsan。这能建出用户，但和多数生产环境的预期差得很远。新版发行版里，直接 useradd 不带参数，可能连家目录都不会创建，或者创建出来的 shell 是 /bin/sh，并不适合交互式登录。
我建议养成一套相对完整的建号习惯：
bash复制useradd -m -s /bin/bash -c "Zhang San" -G wheel,devops zhangsan
echo "someStrongPassword" | passwd --stdin zhangsan
passwd -w 7 zhangsan
参数解释：-m 创建家目录；-s 指定登录 shell；-c 加用户说明；-G 指定附加组。加入 wheel 组是为了让这个用户以后能通过 sudo 提权，而不是直接把 root 密码分发给所有人。passwd -w 7 表示密码过期前 7 天开始警告用户，这对账号生命周期管理很有用。
如果你希望之后每次 useradd 都自动带上一套合理的默认参数，可以修改 /etc/default/useradd 和 /etc/login.defs。前者可以定义默认的 shell、家目录基点、是否创建 mail spool；后者可以定义密码加密算法、密码最大有效期、UID 范围等。改完这两个文件，后续创建用户的体验会稳定不少，这种“一次配置、长期生效”的思路比每次敲一堆参数更靠谱。
3.2 权限设计和 sudo 最小授权
用户建好之后，权限怎么给就成了重点。最常见的错误是把某个人直接加入 sudo 组或者干脆让他有 root 密码，这种做法在几台测试机上没多大问题，但在合规一点的生产环境里很容易造成权限失控。
正确做法是把权限分成两层：第一层是系统层面通过组控制，第二层是在 sudoers 文件里精确到命令。比如运维组只需要重启 Web 服务和管理 Nginx 配置，可以在 /etc/sudoers.d/ 下面单独放一个文件：
text复制%webops ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/nginx -t
这个配置是让 webops 组里的成员不需要输入密码就能执行指定的几条命令。有人会问为什么要用 NOPASSWD，因为在自动化脚本里执行 sudo 命令时，如果要求密码会导致脚本卡住。NOPASSWD 本身并不比带密码更危险，风险取决于你授权的命令范围。如果给的是 sudo ALL，那有没有密码其实区别不大，因为拿到账号的人已经拥有全部权限。
sudoers 文件的编辑必须使用 visudo。很多人图省事直接 vim /etc/sudoers，如果写坏了语法，所有 sudo 都会失效，救回来的过程非常痛苦。visudo 会在保存前做语法检查，语法不对会拒绝保存。
还有一个容易忽略的细节：给用户分配了 sudo 权限后，需要确认用户当前登录的会话是否重新加载了组信息。如果用 ssh 登录后在新的组里执行 sudo 一直失败，多半是会话没有重新读取组信息，退出重新登录，或者用 newgrp 命令切换一下当前组就好。
3.3 SUID 这类特殊位是提权入口，也要主动巡检
既然热词里经常出现“Linux提权”，这里就不得不从防守角度多讲一点。攻击者拿到低权限账号后，第一步往往就是枚举当前环境里有什么可乘之机，sudo 权限只是其中一条路，另外几个重点怀疑对象包括 SUID 文件、环境变量中的可写路径、错误配置的定时任务、还有过于宽松的权限位。
SUID 文件是 Linux 里一类特殊的文件权限。当一个可执行程序带上 SUID 位后，普通用户运行它时会临时获得文件属主的权限。比如 /usr/bin/passwd 的属主是 root，普通用户执行 passwd 时可以通过它修改自己的密码，因为它需要写 /etc/shadow 的能力。这种机制本身没问题，问题在于如果某个带 SUID 的程序自身有漏洞，或者管理员误把 bash、python 等解释器设置了 SUID 位，任何一个普通用户都能直接提权成 root。
巡检命令并不复杂：
bash复制find / -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
找到结果后，逐一和系统自带的 SUID 基线文件比对。如果不是系统包管理的文件，建议尽快去掉 SUID/SGID 位：
bash复制chmod u-s /path/to/suspicious
同时也要检查普通用户家目录、/tmp 等可写目录下有没有可疑的二进制或者脚本，很多提权动作都发生在这些可写目录里。总之，权限相关的知识点不是说你会 chmod 777 就够了，而是要知道每种权限位在什么场景下是合理的、什么场景下是危险的，这比记住一堆硬性命令更有实际价值。
4. Kubernetes 排障：先看 Events 还是先看日志？我的判断顺序
Kubernetes 这块我想先讲排障，因为它最能体现一个人对集群的理解深度。网上总有人说“Pod 出问题就 describe 一下、logs 一下”，这没错，但没有点出顺序和逻辑。我自己的判断顺序基本是：先看现象属于集群层还是工作负载层，再决定到底先查 Events 还是先查日志。
4.1 先分清故障发生在哪个层面
假设有人告诉你“K8s 集群里某个应用访问不了了”，如果你直接跑到应用 Pod 上查日志，很可能南辕北辙，因为问题可能出在节点、调度、网络或者配置上。我习惯先跑一组快速命令，把集群层面的大盘看一眼：
bash复制kubectl get nodes -o wide
kubectl get pods -A -o wide | grep -v Running
kubectl get events --sort-by=.lastTimestamp
如果 Node 状态不是 Ready，那问题在集群基础设施，这时候看应用 Pod 日志意义不大，得去查节点上的 kubelet、容器运行时或者网络组件。如果 Node 状态正常，只有部分 Pod 异常，再进到具体命名空间去 describe Pod，看最近事件、容器状态、镜像拉取情况。
Events 的价值在于它能反映调度器、kubelet 等控制面组件对 Pod 的处理过程，比如调度失败、端口冲突、探针失败，事件里都会有线索。日志的价值则在于能反映容器内部的应用状态，比如代码启动报错、依赖连不上、权限不足。可以这样理解：Events 是“集群视角”，日志是“应用视角”，不要一上来就只看其中一个。
4.2 Pod 常见状态快速判断
Pod 的异常状态种类并不多，常见的有 Pending、ImagePullBackOff、CrashLoopBackOff、Running 但未就绪、OOMKilled 等。每种状态背后对应着不同的根因。
Pending 一般表示 Pod 还没被调度成功或者无法启动。优先查看是否有资源不足、nodeSelector 不满足、污点没容忍、PVC 无法挂载。此时 describe pod 会输出 FailedScheduling 事件，里面通常会写明“0/3 nodes are available”以及原因。如果节点资源充足却仍然失败，要怀疑节点上是否打了固定标签但 Pod 的 selector 匹配不上。
ImagePullBackOff 是镜像拉取失败。常见原因包括镜像名或 tag 写错、私有仓库没有配置 imagePullSecret、containerd 无法访问镜像仓库、仓库证书不被信任。这时候可以先手动在节点上拉一次镜像验证，比如 crictl pull，如果节点上用这个容器运行时可以拉下来，再回头看 Pod 配置里的 imagePullPolicy 和 secret。
CrashLoopBackOff 需要重点区分是“进程一直崩”还是“健康检查不通过”。查看当前日志时如果发现日志为空或者只显示进程启动信息就退出，很可能要结合上一次容器实例的日志判断：
bash复制kubectl logs <pod-name> --previous
这个命令看的是容器上一次退出的输出，往往能找到真正的报错，比如配置文件路径写错、端口被占用。探针失败导致的反复重启则会在 describe 输出里明显看到 Liveness probe failed 的线索。我见过有人一看到 CrashLoopBackOff 就疯狂看当前日志，结果当前容器每次启动后直接活不到写日志的阶段，最后一无所获，白白浪费时间。
除此之外，OOMKilled 可以算作 CrashLoopBackOff 的一种特殊形态，因为大多数情况下容器内存超过 limit 被内核杀掉后，会不断重启。判断方式比较简单：describe pod 的 last state 里如果出现 OOMKilled，把 resources.limits.memory 调大或者优化应用内存占用即可。
4.3 Node 异常和证书过期处理
前面提到 Node 状态不是 Ready 时会话重点转到节点侧。处理节点故障我一般的路径是：先 ssh 登录到节点，看 kubelet 和容器运行时状态，再查 kubelet 日志。
bash复制systemctl status kubelet
journalctl -u kubelet -n 100 --no-pager
kubelet 日志里信息量很大，常见的有 CNI 插件执行失败、容器 runtime 连接不上、证书过期、磁盘压力等。如果出现证书相关报错，例如“x509: certificate has expired or is not yet valid”，很可能是因为集群运行超过证书有效期，需要更新证书。不同 kubeadm 版本的命令略有差异，新版一般用：
bash复制kubeadm certs renew all
systemctl restart kubelet
证书更新完后，还需要注意 kubeconfig 文件使用的客户端证书也可能过期，需要重新获取或刷新。另外，有些组件是静态 Pod 形式运行在节点上的，比如 controller-manager、scheduler、etcd，证书更新后同样需要被重启才能加载新证书。
这类问题有一个共同特点：不是每次操作都会立刻报错，而是故障在某个时间点突然集中爆发，比如证书过期当天你同时看到 apiserver 认证失败、scheduler 心跳异常等一系列现象。看到这类“看似毫不相关”的多个故障同时出现，第一反应应该是检查证书有效期，而不是逐个去查组件。
5. 亲手部署一套可用 K8s 环境并接上 Dashboard，绕不开的几个关键点
想深入理解 Kubernetes，自己动手部署一套集群是最直接的方法。虽然现在很多云平台提供托管集群，点几个按钮就完事，但如果没自己从零部署过，遇到 kubelet 异常、证书问题、CNI 网络性能问题时，还是会觉得隔了一层。
5.1 环境初始化要做到什么程度
网上有很多部署教程，最容易被跳过的是环境初始化这一节，但恰恰是这一节里藏着大量后续问题的根因。我部署时会依次检查这些点：
bash复制swapoff -a
sed -i '/ swap / s/^/#/' /etc/fstab
modprobe br_netfilter
sysctl -w net.ipv4.ip_forward=1
关闭 swap 是 kubelet 的硬性要求，如果开着 swap，kubeadm 初始化会直接失败。做这一步时要注意，只执行 swapoff -a 只对当前会话有效，重启后又会出现，所以要把 /etc/fstab 里的 swap 行注释掉。
然后是内核模块和网络参数，br_netfilter 让网桥流量也能经过 iptables 规则，是 Kubernetes 网络策略和 Service 转发的基础。把这些参数写进 /etc/sysctl.d/k8s.conf 里，保证重启后依然生效。
容器运行时我一般选 containerd。安装完成后有一个非常关键的配置：把 SystemdCgroup 设为 true。如果你不设置，容器内 cgroup 驱动和 kubelet 使用的 cgroup 驱动不一致，初始化时大概率会出现 kubelet 无法启动或节点状态异常的情况。containerd 的默认配置文件一般需要通过 containerd config default | tee /etc/containerd/config.toml 生成，然后在 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] 下面找 SystemdCgroup 字段。
5.2 用 kubeadm 拉起集群的时间线
环境准备好之后，初始化控制平面的命令并没有想象中复杂：
bash复制kubeadm init \
--apiserver-advertise-address=192.168.1.10 \
--pod-network-cidr=10.244.0.0/16 \
--service-cidr=10.96.0.0/12
有两个网段要提前规划好。pod-network-cidr 会交给 CNI 插件使用，service-cidr 用于 Service 的虚拟 IP，这两个网段不能和宿主机现有网段重叠，否则会出现路由冲突。如果你后面要装 Calico，pod 网段最好按 Calico 的要求填，比如 10.244.0.0/16 是 Flannel 常用的默认网段，Calico 默认则可能是 192.168.0.0/16，不是随便填一个都能跑通。
初始化成功后，kubeadm 会打印出一串 join 命令，把它保存好，这是后续 worker 节点加入集群的凭证。如果当时没保存，也可以在控制平面上随时生成：
bash复制kubeadm token create --print-join-command
新节点执行这条命令后，会自动加入集群。这里有个细节：worker 节点也必须有相同的容器运行时、内核参数和 kubelet 组件，否则 join 后节点会一直处于 NotReady 状态。排这类问题最直接的办法是去 worker 节点上看 kubelet 日志，多数错误在日志里说得很明白。
控制平面就绪后，还需要装一个 CNI 插件。没有 CNI，所有 Pod 的 eth0 都不会分配 IP，集群看起来是起来了，实际 Pod 之间完全不通。安装 Calico 一般是 apply 一个 manifest 文件，如果你的环境无法直接访问外部仓库，可以把镜像先拉到本地节点上再导入镜像，或者提前把镜像转换成私有仓库里的版本。
5.3 Dashboard 安装与最小权限访问
集群跑通之后，很多人想装个 Kubernetes Dashboard 来看看。安装 manifest 的方式很简单，但是装完之后会遇到访问和权限两个问题。
Dashboard 默认只会创建一个叫 kubernetes-dashboard 的命名空间，并提供一堆 ClusterRole，但不会自动给你一个管理员账号。如果你只是用 kubectl proxy 方式访问，浏览器访问时点“跳过登录”只能看到很少的资源，很多页面会提示没有权限。要获得完整的管理员视图，通常需要创建一个 ServiceAccount 并绑定 cluster-admin 角色：
bash复制kubectl create serviceaccount admin-user -n kubernetes-dashboard
kubectl create clusterrolebinding admin-user --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:admin-user
kubectl -n kubernetes-dashboard create token admin-user
最后这行命令会输出一个 token。有人习惯在控制台输入 kubectl get secret 去解码老版本的 token，但新版本里更推荐直接用 create token，因为它会创建一个有时效的 token，避免长期凭证在日志或终端历史里泄露。
关于访问方式，我不推荐直接删除 Dashboard 的认证跳转或跳过登录，也不建议把 Dashboard 直接暴露到公网。更安全的做法是通过 kubectl proxy 或者本地端口转发访问：
bash复制kubectl proxy
# 浏览器打开 http://127.0.0.1:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/
实际使用中，如果是在本机操作集群，这个方式最省事，也不需要在 kube-system 里开 NodePort。如果你确实需要给团队提供长期访问入口，建议在前面加一层认证网关，或者在 ingress 上配置证书，而不是直接在 Dashboard Service 上开 NodePort。
6. 面试场景题里，最容易拉开差距的几个回答角度
作为一个经常给团队做技术面试的人，我发现 Kubernetes 相关面试题虽然多，但面试官真正想考察的并不是答案本身，而是你能不能把一个现象拆解成几个层面、找到合适的排查入口。所以这最后一章我想从场景题的角度来收尾，把上面这些知识点串起来。
6.1 场景一：为什么 Pod IP 一直在变，服务访问却不受影响？
这道题考察的是 Service 的底层机制。Pod IP 本身不稳定，因为 Pod 重建时，重新调度的 IP 会发生变化，这也是为什么不能让客户端直接访问 Pod IP 的原因。Service 的 ClusterIP 是相对稳定的，它通过 apiserver 下的 Endpoints 或 EndpointSlice 保存后端的 Pod IP 列表，当 Pod 变化时，Endpoints 会自动更新。
回答时可以进一步区分不同数据链路：早期 kube-proxy 通过 iptables 规则把访问 ClusterIP 的流量随机转发到某个后端 Pod；性能要求更高的场景则使用 IPVS 模式，在 Linux 内核中直接做负载均衡。如果再深入一点，问 kube-proxy 是怎么感知后端变化的，其实是通过 watch apiserver 的 Service 和 Endpoints 资源，更新本地规则。有了这条链路，这个问题才算真正答全。
6.2 场景二：集群突然调度不了 Pod，怎么排查？
遇到新 Pod 一直 Pending，大多数人的第一反应是去 describe 这个 Pod，看有没有 FailedScheduling 事件。这没有错，但面试官更想听的是完整的排查树。
我的回答顺序是：先看集群层状态，kubectl get nodes 看 Node 是否都 Ready；再看有没有 taint 导致 Pod 没有对应容忍；接着看节点资源是否足够，比如 CPU、内存是不是被 requests 占满了；如果这些都正常，再去看是否设置了 resource quota 或者 LimitRange，限制了当前命名空间能创建的资源总和；最后还要考虑污点和容忍、nodeSelector、亲和性规则是不是互相矛盾。
如果这些都没有问题，控制面组件也必须检查，比如 controller-manager 是否正常、是否出现 leader 选举异常，apiserver 是否有过载或限流。这些层面不是每次都能答全，但能答出来，说明你真的独立处理过集群调度问题。
6.3 场景三：Deployment 滚动更新卡住不动，怎么定位？
滚动更新的核心是 Deployment 控制器控制 ReplicaSet 的副本数量变化，分批次替换旧 Pod。如果更新卡住，首先要看新 ReplicaSet 的期望副本数和实际副本数，比如 kubectl rollout status deployment/myapp 显示等待，或者一直卡在某个百分比。
卡住的原因主要有三类：第一，新 Pod 一直没就绪，readinessProbe 探测失败，控制器不会继续创建剩余的新副本；第二，新 Pod 镜像拉取失败，导致可用副本数达不到 maxUnavailable 允许的范围；第三，maxSurge 和 maxUnavailable 配置值太小，比如只允许超出 1 个副本，但节点资源又不足，控制器既不能删旧 Pod 也不能建新 Pod，整个流程就僵住了。定位这一类问题时，重点不是看 Deployment 本身，而是看新 ReplicaSet 下面的 Pod 状态和事件。
我在实际处理这类问题时的体会是：不要一上来就 rollback。先通过 rollout history 查看版本，再 describe 一下新 ReplicaSet 里的 Pod，找到根因，很多时候问题出在配置变更引入的编译错误或探针路径不对。只有在改动特别大、业务恢复优先级更高时，才考虑直接 rollout undo，毕竟回滚也是一次重新部署，同样会受到资源和镜像问题的影响。