Kubernetes 是一个复杂系统。真正理解 K8s，不是背几个资源对象名称，而是能解释调度、重启、配置更新、Service 转发、日志采集和故障排查背后的机制。
本文用 10 个问题测试你对 Kubernetes 的理解程度。
原文：https://medium.com/@rifewang/kubernetes-10-questions-to-test-your-understanding-of-k8s-c2860c9f3cbf
先看问题
- 在具有两个节点的集群中，一个节点有 Pod，另一个没有，新 Pod 将被调度到哪个节点？
- 如果容器中运行的应用程序遇到 OOM（内存不足）错误，容器会重启，还是会重新创建整个 Pod？
- 是否可以在不重新创建 Pod 的情况下动态应用环境变量或 ConfigMap 更新等应用程序配置？
- Pod 一旦创建，即使用户没有采取进一步行动，是否也就稳定下来了？
- ClusterIP 类型的 Service 能否确保 TCP 流量的负载均衡？
- 应如何收集应用程序日志，是否存在丢失日志的风险？
- 如果 HTTP Server 类型 Pod 的 livenessProbe 正常，是否意味着应用程序没有问题？
- 应用程序如何扩展以应对流量波动？
- 当你执行
kubectl exec -it <pod> -- bash时，你是否登录了 Pod？ - 如果 Pod 中的容器反复退出和重启，你将如何排除故障？
下面逐一解释。
1. 新 Pod 会被调度到哪个节点？
调度结果不能只看“哪个节点空”。调度过程包括过滤、打分和绑定等阶段：
结果取决于 Pod 亲和性、污点和容忍度、资源请求、调度插件等配置。在两个节点默认配置且可用资源相同的前提下，NodeResourcesFit 插件会影响打分。
其评分策略包括：
| 策略 | 倾向 |
|---|---|
LeastAllocated |
优先选择资源使用率较低的节点 |
MostAllocated |
优先选择资源使用率较高的节点 |
RequestedToCapacityRatio |
按资源利用率目标进行平衡 |
如果使用 MostAllocated 策略，新 Pod 可能被调度到已有 Pod 的节点；如果使用另外两种策略，则更可能倾向空节点。
2. 容器 OOM 后，是容器重启还是 Pod 重建？
当容器内存不足时，通常是容器根据 Pod 的 RestartPolicy 重启。默认 RestartPolicy 是 Always，因此 Pod 对象本身通常保持不变。
但在极端情况下，例如节点存在严重内存压力，Pod 可能被驱逐，之后由控制器重新创建。
关键区别是：
- 容器 OOM：通常表现为容器重启，Pod 还在。
- 节点压力驱逐：可能导致 Pod 被移除并在其他节点重建。
3. 环境变量和 ConfigMap 能否动态更新？
环境变量无法在不重建 Pod 的情况下动态更新。容器启动后，环境变量已经注入到进程环境中。
ConfigMap 则要看使用方式：
- 如果 ConfigMap 作为文件挂载，且不使用
subPath，可以动态更新。 - 如果 ConfigMap 通过环境变量注入，不能动态更新。
- 如果挂载时使用
subPath，通常也不会获得动态更新效果。
同步延迟取决于 kubelet 的 syncFrequency（默认 1 分钟）和 configMapAndSecretChangeDetectionStrategy。
4. Pod 创建后是否就稳定了？
不能保证。即使用户没有进一步操作，Pod 仍可能受资源短缺、节点故障、网络中断、驱逐策略等因素影响。
Kubernetes 的目标不是让某个 Pod 永远不变，而是通过控制器、调度器和重启策略尽量维持期望状态。因此理解 Pod 时，要区分“单个 Pod 的稳定性”和“工作负载整体的可用性”。
5. ClusterIP Service 能否确保 TCP 流量均匀负载均衡？
不能简单地说能。
ClusterIP Service 依靠 Linux 内核 Netfilter 进行负载均衡。其 connection tracking 机制会维护已建立 TCP 连接的会话状态。对于长期连接，这可能导致流量长期落在少数后端 Pod 上，从而出现负载分配不均。
所以，ClusterIP 能提供服务发现和连接层面的转发能力，但不等于一定能让所有 TCP 流量均匀分布。
6. 应用日志如何收集，会不会丢？
应用日志常见输出方式有两种：
- 输出到
stdout/stderr。 - 写入文件。
对于 stdout/stderr，日志通常保存在节点上，可以由 Fluentd、Filebeat 等日志代理收集，这些代理通常以 DaemonSet 部署。但如果 Pod 被删除，而日志还没来得及被 Agent 收集，就存在丢失风险。
将日志写入持久化存储上的文件可以降低丢失概率，但也会引入文件管理、采集路径和存储成本问题。
7. livenessProbe 正常是否代表应用没问题？
不代表。
从应用角度看，livenessProbe 只说明应用还“活着”，不代表业务功能完全正常。应用可能处于降级状态，但仍能通过 livenessProbe。
从网络角度看，httpGet 类型 livenessProbe 检查的是来自节点 kubelet 的请求，不保证跨节点网络、入口网关或真实用户路径都正常。
因此，livenessProbe 适合判断是否需要重启容器，不适合单独作为业务健康的完整判断。
8. 应用如何应对流量波动？
Kubernetes 支持两类常见扩缩容方式：
- HPA（Horizontal Pod Autoscaler）：横向调整 Pod 数量。
- VPA（Vertical Pod Autoscaler）：纵向调整 Pod 资源规格。
VPA 可能涉及使用调整后的资源重新创建 Pod，因此适用场景受限。HPA 更常见，它可以根据 CPU 使用率、请求速率或自定义指标动态调整 Pod 数量。外部系统也可以通过向 kube-apiserver 发送请求触发扩展。
9. kubectl exec 是登录 Pod 吗？
不是。
kubectl exec -it <pod> -- bash 实际是在目标容器的隔离环境中启动一个新的 bash 进程。对于多容器 Pod，需要指定容器；单容器 Pod 默认使用唯一容器。
Pod 是一组共享部分 Linux namespace 的容器集合。容器共享 Network、IPC、UTS namespace，而 PID 和 Mount namespace 通常保持独立。因此说“登录 Pod”并不准确，更准确的说法是“在某个容器中启动交互式进程”。
10. 容器反复退出和重启，如何排障？
如果容器反复崩溃，kubectl exec 往往来不及进入容器。更有效的路径是：
- 查看 Pod 状态和事件，确认是否是 CrashLoopBackOff、OOMKilled 或镜像拉取问题。
- 查看当前容器日志和上一次退出日志。
- 检查节点和容器运行时日志。
- 检查依赖服务、配置、Secret、ConfigMap 和挂载卷。
- 使用
kubectl debug启动临时容器，调查运行环境和依赖项。
总结表
| 问题 | 关键判断 |
|---|---|
| Pod 调度 | 取决于调度插件、资源、亲和性、污点和打分策略 |
| OOM | 多数情况下容器重启，严重节点压力下 Pod 可能被驱逐 |
| 配置更新 | 环境变量不能动态更新，文件挂载 ConfigMap 有条件动态更新 |
| Pod 稳定性 | 单个 Pod 不保证永久稳定，控制器负责维持期望状态 |
| ClusterIP | 长连接可能导致后端负载不均 |
| 日志 | stdout/stderr 采集存在删除前未采集的丢失风险 |
| livenessProbe | 只能证明进程活着，不代表业务完全健康 |
| 扩缩容 | HPA 常用于横向扩展，VPA 会影响 Pod 生命周期 |
| kubectl exec | 是在容器中启动进程，不是登录 Pod |
| CrashLoop 排障 | 优先看状态、事件、历史日志和 debug 临时容器 |
FAQ
livenessProbe 和 readinessProbe 的关注点一样吗？
不一样。livenessProbe 关注容器是否需要重启；readinessProbe 关注 Pod 是否应该接收流量。本文原问题聚焦 livenessProbe，因此不能用它直接证明业务可用。
ConfigMap 文件挂载更新后，应用一定会自动生效吗？
不一定。Kubernetes 可以更新挂载文件，但应用是否重新读取配置取决于应用自身逻辑。有些应用需要收到信号或重启进程才能加载新配置。
CrashLoop 时为什么不优先 exec？
容器反复退出时，交互式进入窗口很短，常常失败。先看事件、退出原因和历史日志，通常更有效。
