如何让Cadence Worker停止接收新任务实现K8s优雅缩容

你当前方案的核心缺口是：仅配置terminationGracePeriodSeconds只能保证Pod不被强杀，无法阻止待下线Worker在终止流程启动后继续拉取新任务，大超时配置的Activity一旦在这个窗口被拉取，必然会因为Pod退出执行失败触发重试。

可直接落地的完整实现逻辑分3步：

• 配置Pod的preStop生命周期钩子作为新任务拦截的第一道关卡
  Cadence各语言SDK都原生提供Worker停止方法，调用后会立刻终止任务轮询协程，不再拉取任何新的Workflow/Activity任务，仅保留当前正在处理的任务协程继续执行。你可以在Worker进程内暴露一个简单的管理端口，比如实现一个HTTP接口，收到请求时直接调用worker.Stop()触发排水。
  对应K8s配置参考：

  lifecycle:
    preStop:
      exec:
        command: ["/bin/sh", "-c", "curl -s -X POST http://127.0.0.1:9090/internal/worker/drain; sleep 15"]
  terminationGracePeriodSeconds: 1800 # 按你存量任务最长执行时间配置，不用硬卡最大startToClose超时
  

  这里的15秒sleep是为了抵消Cadence服务端的可用Worker列表缓存延迟，确保服务端不再给当前Worker分发新任务后，再进入后续终止流程。
• 优化长耗时Activity的容错配置，不要盲目拉长终止宽限期
  对于执行时长超过你可接受的Pod终止等待窗口的长耗时Activity，不要通过无限拉长terminationGracePeriodSeconds适配，这会导致缩容/发布流程卡几个小时完全不可用。正确的做法是给这类Activity配置合理的heartbeatTimeout，在Activity逻辑里定期上报心跳，Worker下线后，服务端会在心跳超时后立刻将任务重新调度到其他活跃Worker，不会等满整个startToCloseTimeout才触发重试。
• 配合K8s流量拦截降低分发延迟
  如果你用ClusterIP Service对外暴露Cadence前端服务，可以在preStop阶段先主动将当前Pod从Service Endpoints中摘除，配合K8s kube-proxy的规则更新，从网络层阻断新的任务轮询请求到达待下线Pod，进一步降低边界场景下新任务被误分发的概率。

避坑提示：不要依赖进程收到SIGTERM后再触发Worker排水。K8s发送SIGTERM和更新Service Endpoints是并行执行的，存在几秒到十几秒的时间差，这个窗口内待下线Pod依然可能收到新的任务请求，preStop钩子执行完成后K8s才会发送SIGTERM和更新端点，能彻底覆盖这个时间差。

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