K8s Pod驱逐机制疑问：何时删除ETCD对象/仅保留API Server记录？

驱逐过程中的核心操作 #

Kubernetes执行Pod驱逐时，核心操作分为两类：

• 首先评估Pod的优先级（基于QoS等级、Pod优先级配置等），确定驱逐顺序
• 向Pod内的容器发送终止信号（默认SIGTERM），等待配置的优雅终止时长；若超时未停止，则发送SIGKILL强制终止容器
• 根据驱逐的触发主体和场景，决定是否删除ETCD中的Pod对象，或是仅标记状态保留记录

被驱逐Pod从ETCD中删除的场景 #

• 直接调用Eviction API：不管是通过kubectl delete pod <pod-name>命令，还是自定义客户端调用Eviction API，API Server都会直接删除ETCD中的Pod对象，同时通知kubelet终止容器。执行kubectl get pod时不会再看到该Pod（可通过kubectl get pod --show-deleted查看历史记录）
• 控制器自动清理：如果Pod属于Job、CronJob等控制器资源，当Pod完成任务或被驱逐后，控制器可能会根据配置自动删除Pod对象

仅杀死Pod但保留API Server记录的场景 #

• kubelet触发的节点资源驱逐：当节点内存、磁盘、CPU等资源达到预设的驱逐阈值时，kubelet会主动驱逐低优先级Pod。此时kubelet仅终止容器，将Pod状态更新为Evicted并保留在API Server中——目的是留存驱逐原因（比如节点内存不足），方便排查问题。这类Evicted状态的Pod不会自动删除，需手动清理或通过Pod垃圾回收策略配置自动清理
• 驱逐过程中异常终止：若Pod在优雅终止过程中出现异常，kubelet仍会标记其状态为Evicted，并保留对象记录直到手动处理

你遇到的两种现象正好对应上述场景：直接调用Eviction API会彻底删除Pod对象；而节点资源不足触发的kubelet驱逐会留下Evicted状态的Pod记录。

内容的提问来源于stack exchange，提问作者Dmitri Gekhtman