如何为Kubernetes中的长期运行有状态服务实现自动扩缩容？

1. 用就绪探针控制新连接接入 #

给Pod配置就绪探针，让服务在有活跃会话时返回成功，当需要停止接受新连接（比如准备缩容）时，让探针返回失败。这样Kubernetes的Service会自动把新连接导向其他就绪的Pod，直接解决“是否接受新连接”的问题。

示例配置（YAML片段）：

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

你的服务需要实现/health/ready接口：当有活跃游戏会话时返回200状态码，当会话结束或准备进入缩容流程时返回非200状态码。

2. 标记Pod缩容状态+轻量脚本控制缩容 #

不用完全依赖HPA的自动缩容逻辑，而是给Pod添加自定义标签/注解标记是否可被缩容：

• 当Pod存在活跃会话时，给Pod打上scalable: "false"标签；
• 当所有会话结束后，更新标签为scalable: "true"。

之后用CronJob运行一个简单的定时脚本，逻辑如下：

1. 查询当前Deployment/StatefulSet的Pod数量；
2. 对比预设的目标副本数（可从HPA配置或自定义配置文件获取）；
3. 仅选择标记为scalable: "true"的Pod进行删除，实现定向缩容。

这种方式比编写完整的自定义Controller简单得多，只需要调用Kubernetes API的基础操作即可。

3. 优化优雅终止逻辑 #

针对长会话场景，可以把SIGTERM方案优化为更可靠的流程：

• 将terminationGracePeriodSeconds设置为一个足够大的值（比如86400秒，即24小时）；
• 服务监听SIGTERM信号后，立即让就绪探针失败，停止接受新连接；
• 持续检查活跃会话数量，当会话全部结束后，主动退出进程，触发Pod销毁。

这样即使会话持续数小时，也能等会话自然结束后再销毁Pod，避免强制中断。

4. HPA结合自定义指标实现智能缩容 #

如果仍想保留HPA自动扩缩容的能力，可以配置基于自定义指标的规则：

• 暴露每个Pod的活跃会话数作为自定义指标（比如用Prometheus采集，通过Prometheus Adapter暴露给Kubernetes API）；
• 配置HPA以“所有Pod的平均活跃会话数”作为缩容触发条件，当平均会话数低于阈值时，仅缩容那些活跃会话数为0的Pod。

这种方式的复杂度介于脚本和自定义Controller之间，适合需要自动化扩缩容但又要兼顾会话完整性的场景。

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