kubernetes中配置pod优雅终止期限需在spec层级设置terminationgraceperiodseconds字段，单位为秒，影响容器清理时间；必须置于spec下而非containers内，可通过yaml声明或kubectl patch修改，deployment中应在template.spec中统一配置。
在 Kubernetes 中配置 Pod 优雅终止期限，就是告诉 kubelet：容器收到 SIGTERM 后，最多可以宽限多少秒再被强制杀死。这个值直接影响请求是否来得及处理完、临时文件能否保存、数据库连接会不会突然中断。
直接在 Pod YAML 中设置 terminationGracePeriodSeconds
这是最基础也最常用的配置方式，适用于所有 Pod 类型（包括直接创建的 Pod、Deployment 中的模板等）。
第一步：打开你的 Pod 或 Deployment 的 YAML 文件，在 spec 层级下添加 terminationGracePeriodSeconds 字段。
第二步：填入一个正整数，单位为秒。例如设为 90，表示允许容器有 90 秒时间完成清理：
spec: terminationGracePeriodSeconds: 90 containers: - name: app image: my-app:v1
注意：【该字段必须放在 spec 下，不能放在 containers 或 lifecycle 内部】。放错位置会导致字段被忽略，kubelet 仍按默认 30 秒执行终止流程。
第三步：应用配置：kubectl apply -f pod.yaml。新创建或滚动更新的 Pod 就会生效。
通过 kubectl patch 动态修改正在运行的 Pod（不推荐用于生产）
仅适用于调试或紧急场景——因为 Pod 是不可变对象，patch 只对当前实例生效，不会影响 Deployment 控制器后续生成的新 Pod。
执行命令：kubectl patch pod <pod-name> -p '{"spec":{"terminationGracePeriodSeconds":120}}'</pod-name>
这一步操作起来很简单，但【Patch 后 Pod 不会自动重启，也不会触发重建；它只影响下次该 Pod 被删除时的行为】。如果 Pod 正在运行且未被删除，此操作无任何即时效果。
在 Deployment 中统一控制所有副本的优雅终止时间
这才是生产环境的标准做法。你不需要逐个改 Pod，而是让控制器自动把配置注入每个新建的 Pod。
方法一：在 Deployment 的 spec.template.spec 中声明：
apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployspec: replicas: 3 template: spec: terminationGracePeriodSeconds: 60 containers: - name: nginx image: nginx:1.25
方法二：使用 kubectl set 命令一键注入（适合已有 Deployment）：
kubectl set env deployment/nginx-deploy TERMGRA=60 --overwrite=false —— 错误示例，env 无法设置该字段
正确命令是：kubectl patch deployment/nginx-deploy -p '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":60}}}}'
这个 patch 会触发滚动更新，所有旧 Pod 被删除时都将按新值等待 60 秒。
验证配置是否生效
查看某个 Pod 的实际生效值：
kubectl get pod <pod-name> -o jsonpath='{.spec.terminationGracePeriodSeconds}'</pod-name>
返回数字即为当前值；若返回空，说明未设置，kubelet 将使用默认 30 秒。
进一步确认行为：删掉该 Pod，用 kubectl describe pod <pod-name></pod-name> 查看 Events，能找到类似 Stopping container app (terminate with signal TERM) 的记录，之后若超过设定时间未退出，会看到 Killing container with signal KILL。
