今天我们来深入探讨一个在Kubernetes运维中经常遇到的问题：容器挂掉、Pod终止以及节点故障，究竟哪种情况会触发工作负载的重新调度？

这个问题不仅常见于技术面试，更是日常集群管理需要掌握的核心知识点。很多人对容器故障是否会导致Pod重新调度存在误解，下面我们就来解析这三种故障场景的调度机制。

1. 理解Kubernetes的核心调度原则

首先要明确一个关键事实：Kubernetes不会自动"迁移"运行中的Pod。

它的处理流程始终是：删除 → 重建 → 重新调度。

一旦Pod被调度到某个节点，它就会一直驻留在该节点，直到被终止。这与虚拟机热迁移完全不同，Kubernetes的调度机制更加直接明了。

2. 容器异常退出会触发什么？

容器是由节点上的kubelet和容器运行时共同管理的。

当容器进程异常退出时，kubelet会根据restartPolicy重启策略决定是否重启容器。对于Deployment创建的Pod，默认策略为Always：

restartPolicy: Always

这种情况下会发生什么？

仅仅是在当前节点重启容器，Pod本身不会被删除，自然不会触发重新调度。

这时候你可能会在监控中看到这样的状态：

CrashLoopBackOff

很多工程师一看到CrashLoopBackOff就以为是"调度失败需要更换节点"。

实际上并非如此，这只是表示容器在不断地重启-崩溃循环，但始终是在原节点上进行。

3. 什么情况下才会真正重新调度？

记住这个核心原则：只有Pod被删除，才会触发重新调度。

我们来看几个实际场景：

(1) 节点故障场景

当节点完全宕机，kubelet服务停止，网络连接中断

控制平面检测到Node状态变为NotReady。超过默认5分钟阈值后：

控制器会删除该节点上的Pod，然后重新创建新的Pod实例，调度器kube-scheduler会重新选择可用节点

这时候才算是真正的"重新调度"。

(2) 手动驱逐场景

运维常见操作：

kubectl drain node01 --ignore-daemonsets

这时Node会被标记为不可调度，Pod会被优雅驱逐，控制器重建Pod，调度器重新选择节点

这是一种"人为触发的重新调度"。

(3) 资源不足被驱逐

如果节点出现：内存不足/磁盘压力/PID耗尽等情况，kubelet也会主动驱逐Pod。

Pod状态变为：Evicted，控制器重新创建后，才会触发重新调度。

(4) 手动删除Pod

kubectl delete pod xxx

如果这个Pod属于：

Deployment、ReplicaSet或StatefulSet这类控制器

控制器会立即创建新Pod，然后重新调度。

但如果是独立Pod（没有控制器管理）？删除后就彻底消失了。

不会重建，更不会调度。

4. 面试标准回答模板

（建议熟记这个回答思路）你可以这样表述：

容器挂掉默认只会由kubelet在当前节点重启，不会触发重新调度。只有当Pod被删除，例如节点宕机、被驱逐或手动删除时，控制器才会重建Pod，并由调度器重新选择节点。Kubernetes本身不会自动迁移运行中的Pod。

这段话一出口，面试官基本就能判断你对调度机制的理解程度了。