如何优雅地处理 k8s 中滚动更新带来的延时任务丢失的问题

任务同时保存在 DB 中，创建和执行都会记录，启动时从 DB 中读取。目前我的任务就是这样设计的。

不是弄个事件队列解决的吗，处理好的才标记成功，不成功就按策略重试

首先，pod 最好是无状态，在 k8s 里更新、扩容、重启都方便。
第二，没有持久化的话，本身这个程序也不可靠，总会遇到异常崩溃吧。
单纯想更新后不丢任务，可以让程序监听到 terminal 后主动找个地方存一下，启动时再去读。

直接用 k8s 自带的 cronjob 类型部署

业务代码角度
任务状态和任务信息保存在 DB 中， 修改代码逻辑，在服务里面加一些请求处理，服务增加优雅关闭处理，能够处理 sigterm 的信号。

从 k8s 角度
使用自定义钩子
Deployment 资源支持以下几种钩子：

PostStart 钩子：在容器启动后立即执行。这通常用于执行容器启动后的初始化任务，例如等待其他服务启动、注册服务到服务发现系统等。
PreStop 钩子：在容器关闭之前执行。这通常用于执行容器关闭前的清理任务，例如保存数据、关闭连接、发送信号给其他进程等。

在关闭之前执行一些持久化操作
比如 可以执行一个 HTTP GET 请求 或者 exec 命令，并且它们执行是阻塞的，可以利用这个特性来做优雅停止。

调用 HTTP GET

spec:
contaienrs:
- name: my-container
lifecycle:
preStop:
httpGet:
path: "/stop"
port: 8080
scheme: "HTTP"

修改 terminationGracePeriodSeconds ， 将它调整到合适的值，不要过大。
terminationGracePeriodSeconds 等于 服务优雅退出超时时间和 preStopHook 之和

如果是一些计划任务，建议用 k8s 的 cronjob 来处理

@nicoaz 更正下 terminate 😅

看看能不能分段拆分下，就像更新 10w 条记录，不应该一次全部更新，而是分段更新和加记录 cursor ，这样被中断后后续可以继续执行

你定时设定的不对。要么用 cronjob ，要么用 db 保存上一个任务执行时间。

把这部分逻辑抽出来单独做一个模块使用 cronjob 运行，deployment 中的应用应当确保无状态

任务如果能做成可以断点续跑的，pod 随时干掉也没问题。


如果不能做成断点续跑的，就设置一个 30 分钟的 gracefully exit 时间，rollout 的时候印象中应该会等 pod 自己退出的。

但这个方案应该会一个特殊场景会有问题，某次 rollout 的时候 pod 还没 ready ，就开始执行任务了，然后紧接着又 rollout 了一个，这个时候我印象不会等 gracefully exit 直接会干掉 pod 。

所以是 pod 重启会影响业务？ k8s 中 pod 随时可能被重启的

你看下 pod 的 lifecycle 啊，pod 退出的时候会给你的程序发个信号，你收到信号的时候把任务取出来塞回队列里，新的 pod 再去队列拿回来就行了吧。

@mightybruce #5 这样就为服务增加状态了，而且很复杂

任务保持在 DB 中，存储任务状态和创建时间，然后服务内部开个线程轮询 30 分钟以前的未执行的任务，更新状态为执行中，更新成功的就本地执行，更新不成功的跳过，有可能被其他 Pod 抢到了，这块的处理是上锁最好，redis 锁或者 db 锁都行

这个问题不应该和 k8s 甚至任何环境有什么关系。 应该是系统设计问题，重新设计这个功能的实现吧。

我这里部署系统的设计是一个代码仓库打出来一个镜像，这个镜像有不同的运行方式，可以是无状态 rpc/http 使用 deployment ，也可以是有状态 binlog 使用 statefulset ，还可以是 Cronjob ，每次部署最小单元是一种部署方式

显然选 2
如果用 cronjob ，则你的应用程序和 k8s 有耦合。将来万一 k8s 没落了呢