k8s的Deployment部署策略线上踩坑
线上问题
我们有个服务,专门做t-1日的增量数据入仓的. 入仓流程: 每日0点系统新建个csv文件, 通过kafka监听增量数据, 实时数据写入该csv文件, 供下游数仓次日取数.
每日产生数据50G(1.8亿条)左右, 有天重启服务, 下游数仓直接告警提示: 数据有好多条脏数据,导致无法继续入仓.
结论先行
我们服务托管在k8s平台上, 这个服务是单pod, k8s默认发版策略是滚动更新,当滚动更新发版时,会出现2个pod同时存在,双pod共同往csv文件写数据.
导致脏数据, 解决方案把发版策略滚动更新改为重建更新就好.
Deployment策略
滚动更新(Rolling Update)
滚动更新是默认的更新策略，一次仅更新一批Pod，当更新的Pod就绪后再更新另一批，直到全部更新完成为止；该策略实现了不间断服务的目标，但是在更新过程中，不同客户端得到的响应内容可能会来自不同版本的应用，会出现新老版本共存状态。
删除式更新(Recreate)，当更新策略设定为Recreate，在更新镜像时，它会先删除现在正在运行的Pod，等彻底杀死后，重新创建新的RS(ReplicaSet)，然后启动对应的Pod，在整个更新过程中，会造成服务一段时间无法提供服务。也称之为单批次更新。
重建更新(Recreate)
Recreate策略在更新镜像时，它会先删除现在正在运行的Pod，等彻底杀死后，重新创建新的RS(ReplicaSet)，然后启动对应的Pod，在整个更新过程中，会造成服务一段时间无法提供服务。也称之为单批次更新。Recreate升级策略分为三个步骤:
1.杀死所有旧版本的Pod，此时Pod无法正常对外提供服务；
2.创建新的RS，启动新的Pod；
3.等待Pod就绪，对外提供服务；