关于GKE集群中Pod终止时间、阶段及相关细节的咨询

一、Pod何时进入终止状态 #

Pod会在以下场景触发终止流程：

• 执行kubectl delete命令主动删除Pod
• Deployment/StatefulSet等控制器触发滚动更新，旧Pod被替换
• Pod的存活探针（livenessProbe）失败次数达到阈值，被kubelet驱逐
• 集群节点缩容、节点被删除或标记为不可调度，节点上的Pod被驱逐
• 节点资源（CPU/内存）不足，Pod被kubelet按QoS等级驱逐
• Pod关联的配置（如ConfigMap/Secret）更新触发Pod重建（部分场景）

二、终止流程的起始节点 #

当kube-apiserver收到Pod的删除请求后，会给Pod的metadata添加deletionTimestamp字段，此时Pod就正式进入终止流程，同时Pod的状态会被更新为Terminating。

注：无论Pod之前处于Running、Pending还是ContainerCreating状态，只要被标记了deletionTimestamp，就会启动终止流程，但Pending状态的Pod终止流程更简单，无需处理容器退出逻辑。

三、终止所需时长 #

Pod终止的总时长由以下几个环节的耗时组成：

1. 优雅终止期（可配置）
   默认时长为30秒，可通过Pod的spec.terminationGracePeriodSeconds字段自定义。在这个阶段：
   • kubelet先执行Pod中定义的PreStop钩子（如果有），钩子的执行时间会占用优雅终止期
   • 发送SIGTERM信号给容器内的进程，通知进程自行退出
   • kube-proxy同步更新集群网络规则，停止将流量转发到该Pod
2. 容器退出等待
   如果容器在优雅终止期内自行退出，kubelet会直接进入下一步；如果超时未退出，kubelet会发送SIGKILL信号强制杀死容器
3. 资源清理阶段
   kubelet清理容器的运行时资源（如网络命名空间、存储卷），同时kube-apiserver从etcd中移除Pod的记录，这部分耗时通常在几秒内

总时长一般为：PreStop钩子耗时（若有） + 容器退出耗时（≤优雅终止期） + 资源清理耗时。如果容器在收到SIGTERM后立即退出，总时长可能仅几秒；如果容器超时未退出，总时长则为优雅终止期加上几秒的清理时间。

额外细节 #

• 当Pod进入Terminating状态后，kube-apiserver会拒绝将新的服务请求路由到该Pod，避免流量丢失
• 如果是节点失联导致的Pod终止，kube-controller-manager会等待pod-eviction-timeout（默认5分钟）后，才会给Pod添加deletionTimestamp，之后执行正常的终止流程

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