K8s无序号Pod ID场景下Pod优雅关停相关技术咨询

问题1：未使用StatefulSet的场景下，若Pod处于重启循环状态，在其重启成功前，是否会在缩容操作中被优先移除？ #

• 会被优先移除。针对Deployment、ReplicaSet这类无状态工作负载，Kubernetes有明确的缩容候选Pod排序规则，排序靠前的Pod会被优先删除：
  • 最高优先级删除未完成节点调度的Pending状态Pod
  • 次高优先级删除Ready状态为False的未就绪Pod
  • 处于重启循环（CrashLoopBackOff）的Pod因容器反复启动失败，始终无法进入就绪状态，会被归入次高优先级删除队列，比所有正常运行的就绪Pod更早被选中。如果同批次存在多个未就绪Pod，还会进一步参考Pod重启次数、创建时间排序，重启次数越高、创建时间越晚的Pod被删除的优先级越高。

问题2：无论是否使用StatefulSet，若缩容过程中目标Pod的容器以非零退出码退出，系统会将其重启后再执行关停流程，还是直接移除该Pod？ #

• 不会触发重启，会走完关停流程后直接移除。当Pod被选定为缩容删除目标后，API Server会立刻为该Pod打上deletionTimestamp标记，标记生效后：
  • 对应的工作负载控制器（ReplicaSet/StatefulSet等）不会再为这个异常退出的Pod触发重建逻辑
  • 节点上的kubelet检测到Pod已被标记删除，即使容器在关停过程中以非零退出码异常退出，也不会执行容器重启动作，只会按规则完成剩余宽限期等待、关联资源清理流程后，将Pod从集群中移除。
• 存在一个特殊场景：如果Pod配置了preStop生命周期钩子，钩子执行过程中容器异常退出，kubelet仍会等满配置的terminationGracePeriodSeconds宽限时长再清理Pod，不会因容器提前退出就立刻删除。

问题3：由于业务需要为Pod配置生命周期内唯一的UID，而非可复用的固定序号ID，因此不计划使用StatefulSet，该场景下是否有可行方案保障Pod始终被优雅关停？ #

• 优雅关停不是StatefulSet独有的能力，无状态工作负载完全可以通过标准配置实现稳定的优雅关停，不需要依赖StatefulSet的固定序号机制，可参考以下落地方式：
  • 根据业务实际的流量摘流、状态落盘、存量连接断开的最长耗时，合理设置terminationGracePeriodSeconds参数，默认值为30秒，存在长连接业务场景可适当调大
  • 配置正确的就绪探针（readinessProbe）：Pod收到SIGTERM信号后，kubelet会先将Pod的就绪状态置为False，上层Service/Ingress会自动将该Pod从后端端点列表摘除，避免关停过程中有新流量打入
  • 业务容器需要正确处理SIGTERM信号：收到终止信号后先停止接收新请求，处理完正在执行的请求、将内存临时状态持久化到存储后再主动退出。如果业务进程通过shell脚本启动，需要加exec参数让业务进程成为1号进程，避免SIGTERM信号被shell进程吞掉导致业务收不到终止信号
  • 若业务本身没有内置SIGTERM处理逻辑，可配置preStop钩子，先调用业务的摘流、下线接口，等待足够时间让存量请求处理完成后再触发进程退出
  • 你需要的生命周期唯一UID可以直接使用Kubernetes为每个Pod自动生成的metadata.uid字段，该字段为集群全局唯一，从Pod创建到彻底删除全程不会变化，也不会被后续新建的Pod复用，完全满足唯一标识需求，不需要额外自行生成。

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