主从架构有状态服务k8s部署primary属性配置与故障处理方案问询

下面给出两种路径的实现方案，你可以根据业务改造成本、高可用要求选择。

方案1：零代码改造，适配现有主从逻辑 #

这套方案不需要修改现有应用代码，只需要调整部署配置即可完成迁移。

多副本primary属性配置 #

使用StatefulSet资源部署你的服务，利用StatefulSet Pod固定有序的名称特征做判断：

• StatefulSet创建的Pod名称格式固定为{statefulset名称}-{序号}，序号从0开始递增
• 给容器添加启动预处理脚本，读取系统自带的HOSTNAME环境变量，判断如果Pod序号为0，就将配置文件中primary属性改为true，其余副本统一改为false，再启动jar包
• 参考启动脚本：

#!/bin/sh
# 替换为你的配置文件实际路径
CONFIG_PATH=/app/config/application.yml
if [[ $HOSTNAME == *-0 ]]; then
  sed -i "s/^ *primary:.*$/  primary: true/" $CONFIG_PATH
else
  sed -i "s/^ *primary:.*$/  primary: false/" $CONFIG_PATH
fi
java -jar /app/your-service.jar

故障转移实现 #

StatefulSet本身会保证指定序号的副本始终存活：

• 当序号为0的主实例Pod发生故障，K8s会自动销毁异常Pod，重新创建一个同名同序号的新Pod
• 新Pod启动时自动执行脚本将primary设为true，自动完成主实例切换，不需要人工介入
• 建议给Pod配置livenessProbe存活检测，检测到主实例服务异常时K8s会更快触发重建，降低故障影响时间

方案2：架构优化，实现更高可用性 #

如果你的业务对聚合任务的连续性要求较高，不想因为主实例重建出现分钟级的任务中断，可以做少量代码调整优化架构：

核心调整逻辑 #

去掉配置文件里写死的primary属性，改为通过分布式锁做自动主节点选举：

• 所有实例启动后默认作为从实例承接读写请求，同时尝试抢占分布式锁
• 抢占到锁的实例自动切换为主实例，开始执行MongoDB聚合任务，同时定期给锁续期
• 若主实例发生故障，锁会自动超时释放，其余存活实例会抢占到锁成为新的主实例，故障转移耗时可以控制在秒级
• 分布式锁可以直接复用现有MongoDB实现，不需要额外引入中间件：用一个专门的锁集合，写带唯一索引的锁文档，利用MongoDB的原子写能力实现抢锁逻辑即可

部署简化 #

这套方案不需要固定Pod序号，直接用Deployment部署多副本即可，扩缩容更灵活，也不用依赖StatefulSet的特性。

流量接入注意事项 #

如果按照原逻辑要求主实例不承接业务读写请求，可以给主实例打专属标签，K8s Service的selector只选择从实例标签，保证所有业务流量只会转发到从实例，避免聚合任务占用资源影响业务请求性能。

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