当集群节点因维护或故障被驱逐时，Pod 会被 Kubernetes 调度器自动分配到满足资源请求和调度约束的其余健康节点，但最终落点并非随机，而是由节点污点、Pod 容忍度、亲和性规则以及当前集群资源碎片共同决定。
节点驱逐触发后，Pod 重调度流程如何运转
触发驱逐的三种典型场景
- 主动运维：使用
kubectl drain命令将节点标记为不可调度，并逐出其上所有 Pod,这是最常见的计划内维护方式。 - 节点压力驱逐：当 kubelet 检测到节点内存、磁盘空间或 PID 资源不足时，自动触发 Eviction，根据 Pod 优先级和服务质量等级（QoS）决定驱逐顺序。
- 云供应商实例故障：AWS EC2 实例意外停止或底层硬件故障，节点心跳超时后控制器将其标记为
Unknown，随后 Pod 被调度到其他节点。
Pod 重调度流程与节点选择逻辑
驱逐请求通过 Eviction API 或节点控制器发起后，Pod 进入 Terminating 状态，Endpoints 控制器移除其 IP 地址，调度器（default-scheduler）监听未绑定的 Pod,执行以下步骤：
- 预选阶段：过滤掉不满足资源请求、端口冲突、节点选择器、亲和性约束以及污点容忍度的节点。
- 优选阶段：对剩余节点打分，考虑节点资源利用率、Pod 亲和性、拓扑分布约束等,选择最高分节点。
- 绑定：将 Pod 与目标节点绑定，kubelet 启动容器。
决定 Pod 新位置的三大核心因素
- 资源可用性：目标节点必须满足 Pod 的
requests和limits，否则调度器会跳过该节点，如果所有节点资源碎片化，Pod 将陷入Pending。 - 节点选择器与亲和性：
nodeSelector、nodeAffinity、podAffinity/podAntiAffinity规则会限制 Pod 可调度的节点范围。 - 污点与容忍度：节点上的污点（如
node-role.kubernetes.io/control-plane:NoSchedule
）只有配置了对应容忍的 Pod 才能调度上去，未被驱逐的节点若带有干扰性污点，Pod 可能无法落地。
Kubernetes 节点驱逐后 pod 调度策略详解
默认调度器的过滤与打分机制
调度器通过一系列预置谓词（Predicates）进行过滤，PodFitsResources 检查资源是否充足，NodeSelector 检查标签匹配，MatchNodeSelector 处理节点选择器，过滤后的节点进入优选阶段，优选项包括 LeastRequestedPriority（优先使用资源剩余最多的节点）和 BalancedResourceAllocation（保持 CPU 与内存使用均衡），实战中，Pod 没有设置资源请求，调度器会认为其资源需求为零，可能导致多个 Pod 被调度到同一节点，引发资源争抢。为每个 Pod 明确设置资源请求是避免调度失败的基本功。
节点亲和性与 Pod 反亲和性如何影响调度结果
- 硬亲和性（
requiredDuringSchedulingIgnoredDuringExecution）：调度时必须满足该规则，否则 Pod 无法调度，要求 Pod 只能运行在 SSD 标签节点上。 - 软亲和性（
preferredDuringSchedulingIgnoredDuringExecution）：调度器优先满足，但不强制，当资源紧张时,软亲和性可能被忽略。 - Pod 反亲和性：用于分散同一应用的多副本，配置
podAntiAffinity使两个副本不调度到同一节点，可用性提高的同时，也可能导致驱逐后副本分散到不同可用区,从而增加跨可用区流量成本。
PodDisruptionBudget：保证驱逐过程中服务不降级
通过设置 PDB，可以限制一次中断的 Pod 数量，对 3 副本的 Deployment 设置 maxUnavailable=1，驱逐时最多只有一个 Pod 被同时中断，调度器会等待新 Pod 就绪后再继续驱逐其他 Pod，这是生产环境必备策略,能避免滚动维护时服务完全不可用。
实战场景：Pod 重调度后可能遇到的“坑”
资源碎片导致 Pod 长时间 Pending
即使集群总资源充足，但每个节点剩余资源碎片化，可能无法满足单个 Pod 的请求，节点剩余 0.5 核 CPU，但 Pod 请求 1 核，导致所有节点都不满足，此时需要调整 Pod 资源请求，或依赖 cluster-autoscaler 扩容节点。业内专家指出，资源碎片是导致 Pod 在驱逐后持续 Pending 的最常见原因之一。
节点污点未容忍导致调度失败
如果节点被打了专用污点，如 node.kubernetes.io/unschedulable:NoSchedule，没有对应容忍的 Pod 不会被调度上去，驱逐时，如果所有节点都有污点且 Pod 未配置容忍，Pod 将一直 Pending，运维人员应检查 Pod 的 tolerations 字段,并在节点上合理使用污点与容忍度实现隔离。
跨可用区调度与成本考量
当集群节点分布在多个可用区，驱逐后 Pod 可能被调度到其他可用区，导致跨 AZ 流量成本增加，使用 topologySpreadConstraints 可以控制 Pod 在区域间的分布，避免所有 Pod 集中到同一区域，设置 topologyKey: topology.kubernetes.io/zone 并限制 maxSkew: 1，确保 Pod 在各可用区均匀分布，既降低故障影响,也控制网络成本。
如何提高 Pod 重调度的确定性与效率
合理设置资源请求与限制
为每个 Pod 设置准确的资源请求，避免调度器低估或高估需求，使用 Vertical Pod Autoscaler（VPA）可以帮助自动调整，但注意 VPA 可能与驱逐事件冲突，需配置 updateMode: Off 仅在离线时推荐值。
利用 topologySpreadConstraints 均匀分布 Pod
示例配置：
topologySpreadConstraints: - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule
确保 Pod 在节点间均匀分布，驱逐时影响范围更小，行业共识认为，均匀分布是最有效的防御策略，能显著降低节点故障对整体服务的影响。
启用 cluster-autoscaler 应对资源不足
当驱逐导致创建新 Pod 但资源不足时，cluster-autoscaler 会自动扩容节点组，提供新节点供调度，配置时注意节点组大小限制，以及扩容延迟时间，避免因资源不足导致 Pod 长时间 Pending。
监控与排查调度异常
常用命令：
kubectl describe pod <pod-name>查看事件,了解调度失败原因。kubectl get events --sort-by='.lastTimestamp'查看集群最新事件。- 检查调度器日志：
kubectl logs -n kube-system <scheduler-pod>。
如果发现 Pod 停留在 Pending 状态，优先查看 Events 输出，通常能直接提示资源不足、污点不匹配或亲和性冲突。
关于集群节点驱逐后 pod 重调度的常见问题
节点被驱逐时，DaemonSet 的 Pod 也会被重新调度吗？
DaemonSet 的 Pod 由 DaemonSet 控制器管理，当节点被驱逐时，该 Pod 被删除，但控制器会立即在满足条件的节点上重新创建，DaemonSet Pod 默认容忍所有节点污点，因此即使节点被设置为不可调度，DaemonSet 也能在节点上运行，如果节点被完全删除，DaemonSet Pod 会在其他节点上启动。
如何强制 Pod 调度到特定节点，避免被驱逐影响？
可以使用 nodeName 字段直接指定节点，但这样会绕过调度器，且节点故障时 Pod 无法自动迁移，更推荐使用 nodeAffinity 硬约束，requiredDuringSchedulingIgnoredDuringExecution 确保 Pod 只调度到特定标签节点，同时配合 PDB 和拓扑分布约束，实现可控的调度策略,避免单点故障。
节点驱逐后，挂载了 PVC 的 Pod 如何处理？
PVC 使用 ReadWriteOnce 模式，且原来节点被驱逐，Pod 在新节点上启动时会重新挂载同一 PVC，但若 PVC 被其他 Pod 占用，新 Pod 会 Pending 直到 PVC 释放，建议使用 ReadWriteMany 存储类，或设置 StorageClass 为 allowVolumeExpansion: true，并配置 Pod 的 PVC 为 ReadWriteOnce 时，确保节点故障后 PVC 能被快速释放并重新绑定。