在 Kubernetes 的面试中，面试官越来越倾向于抛开死记硬背的概念，转而考察实际排错能力和对机制的理解深度。

以下为你整理了 5 个在面试中极高频出现的场景题，这些问题通常会以“你遇到过吗？”或“如果是你，你会怎么排查？”的形式出现。

🛠️ 场景一：Pod 起不来与状态异常

面试官提问：
“当你执行 kubectl get pods 时，发现 Pod 处于 ImagePullBackOff 或 CrashLoopBackOff 状态。请详细描述你的排查思路。”

考察点：
- 基础命令的熟练度
- 对容器生命周期的理解
- 日志分析能力

参考回答思路：

1.  看状态与事件：
    - 首先执行 kubectl describe pod 。
    - 重点查看底部的 Events 列表。这是 K8s 调度和运行时的“黑匣子”。
    - 如果是 ImagePullBackOff：通常是镜像名写错、私有仓库凭据未配置或节点拉取镜像超时。
    - 如果是 CrashLoopBackOff：通常意味着容器启动了但立刻崩溃了。

2.  看日志：
    - 执行 kubectl logs 。
    - 如果是 CrashLoopBackOff，当前容器可能已经挂了，必须加上 --previous 参数查看上一个崩溃实例的日志：kubectl logs  --previous。
    - 根据日志中的报错（如配置文件缺失、端口占用、代码异常）定位根本原因。

🚫 场景二：应用无法访问（网络问题）

面试官提问：
“我的应用 Pod 已经 Running 了，但是外部无法访问服务。或者 Pod 之间无法互相访问。你觉得可能是什么原因？”

考察点：
- 对 Service 和网络模型的理解
- 对端口配置的细节把握

参考回答思路：

1.  确认 Service 是否关联上 Pod：
    - 检查 Service 的 selector 标签是否与 Pod 的 labels 完全一致。
    - 执行 kubectl get endpoints 。如果列表为空，说明 Service 没有找到任何后端 Pod，问题出在标签不匹配。

2.  检查端口配置：
    - 容器端口： Pod 内的应用实际监听的端口（containerPort）是否正确？
    - Service 端口： Service 的 targetPort 是否指向了正确的容器端口？port 是否正确？
    - NodePort： 如果是 NodePort 类型，检查 nodePort 范围是否在允许区间内，且宿主机防火墙是否放行了该端口。

3.  检查网络插件：
    - 如果是跨节点 Pod 无法通信，可能是 CNI 网络插件（如 Calico, Flannel）配置错误或组件未正常运行。

💥 场景三：节点 NotReady 与资源争抢

面试官提问：
“发现某个 Worker 节点状态变成了 NotReady，或者节点上的 Pod 全部被驱逐了。这种情况通常由什么原因引起？如何处理？”

考察点：
- 节点维护能力
- 对资源管理的理解

参考回答思路：

1.  查看节点详情：
    - kubectl describe node 。
    - 查看 Conditions 部分，通常会看到 MemoryPressure、DiskPressure 或 PIDPressure。

2.  常见原因与对策：
    - 磁盘满/资源不足： 这是最常见的原因。节点磁盘空间不足会导致 Kubelet 无法写入数据，从而置为 NotReady。
    - OOMKilled： 检查是否有 Pod 没有设置资源限制，导致把节点内存跑满了，进而导致系统杀死 Kubelet 进程。
    - 网络中断： 节点与 Master 失去心跳。

3.  处理方式：
    - 如果是磁盘问题，可以尝试 kubectl drain  --delete-emptydir-data --force 将 Pod 驱赶到其他节点，然后清理磁盘重启 Kubelet。

⚖️ 场景四：CPU 100% 与负载过高

面试官提问：
“生产环境 CPU 突然飙高，你如何定位是哪个 Pod 导致的？如果需要限制某个应用的资源使用，你会怎么做？”

考察点：
- 监控与排错工具
- 资源管理机制

参考回答思路：

1.  定位高负载 Pod：
    - 首先确保集群安装了 Metrics Server。
    - 使用 kubectl top nodes 查看节点负载。
    - 使用 kubectl top pods 查看具体是哪个 Pod 占用 CPU 或内存最高。

2.  资源限制：
    - 在 Pod 的 YAML 定义中，必须设置 resources 字段。
    - requests： 保证容器运行所需的最小资源，调度器依据此值决定将 Pod 调度到哪个节点。
    - limits： 限制容器最多能使用的资源上限。如果容器超过 limits，可能会被限制 CPU 配额或因内存溢出被杀死。
    - 最佳实践： 生产环境严禁不设 limits 上线。

🔄 场景五：滚动更新与回滚

面试官提问：
“我们发布了一个新版本，发现有 Bug，如何快速回滚到上一个稳定版本？如果发布过程中发现新 Pod 一直起不来，K8s 会自动回滚吗？”

考察点：
- 发布策略理解
- 应急响应能力

参考回答思路：

1.  关于自动回滚：
    - K8s 默认不会自动回滚。 Deployment 的滚动更新如果卡住（例如新 Pod 健康检查失败），旧的 Pod 通常还会保留（取决于 maxSurge 和 maxUnavailable 配置），但不会自动变回旧版本，需要人工干预。

2.  手动回滚操作：
    - 查看历史版本：kubectl rollout history deployment/。
    - 回滚到上一版本：kubectl rollout undo deployment/。
    - 回滚到指定版本：kubectl rollout undo deployment/ --to-revision=2。

3.  预防措施：
    - 配置合理的 livenessProbe 和 readinessProbe，这样如果新版本启动失败，K8s 会停止向新 Pod 转发流量，并停止滚动更新过程，防止故障扩散。

💡 总结：回答场景题的黄金法则

在面试中回答这类问题时，建议遵循 “现象 -> 工具 -> 步骤 -> 原因 -> 解决” 的逻辑链条：

1.  复述现象： “您说的 Pod 起不来，通常是指状态异常...”
2.  使用工具： “我会首先用 kubectl describe 和 kubectl logs 这两个命令。”
3.  阐述步骤： “先看 Events，再看 Logs。”
4.  分析原因： “如果是 ImagePullBackOff，那就是镜像问题...”
5.  给出方案： “修正镜像名或配置 Secret 即可。”

这种结构化的回答方式会让面试官觉得你非常专业且有条理。