[部署] 上云版支持蓝绿部署

[wklken]

提升可用率, 降低风险

[zhu327]

方案1:

1. 额外部署新的deployment
2. service还是只有1个, 新的deployment与老的使用相同的selector

---

service导流到endpoints时会选择分发流量到新老deployment

---

问题: 流量不可控

[zhu327]

方案2:

当前使用的TKE clb-controller 是不支持流量切分的, 但是bcs提供的bcs-ingress-controller可以控制流量权重, 通过修改clb的rs权重来实现

风险:

怎么平滑升级是个问题

[zhu327]

应用本身的问题:

1. 蓝绿部署的实例不能同时使用同一个redis
   • redis作为缓存, 如果版本缓存数据有变, 会导致获取缓存数据有问题
   • redis作为队列, 同一个队列中的消息会被蓝绿版本的不同task获取到并消费, 导致逻辑错误
2. 同理SaaS蓝绿部署时MQ也不能用同一个

[zhu327]

基本方案:

1. 部署2套
   • 数据库用同一个, 需要评估数据库连接数对性能的影响
   • redis需要考虑是否各用一个, 评估下影响
2. 从网关分流到不同的实例
   • 推动流量大户更新使用v2 api做鉴权, 切换到apigw调用

疑问:

saas 调用权限中心后台没有走网关, 如何切换

[zhu327]

BCS rollout

蓝绿部署理解

• 配置一个rollout更新的策略, 对应的operator会拦截deployment的正常发布

• deployment更新时, 会按照策略生成金丝雀的deployment, 按步骤比例生产pod数量, 此时会执行check hook, check不通过, pod状态是not ready, 直到check ok, pod 状态 ready, 此时通过service会进来部分流量, 灰度验证

• 如果策略check失败, 可以执行回退到上一步, 回滚, 暂停三类选择

• 所有的步骤执行完成后, 开始滚动更新原来的deployment, 销毁金丝雀的deployment

  hook

• 定义了执行hook检查时的逻辑方法, 当前支持通过web get的方式来执行检查

• [ ] 需要等BCS支持exec的hook方法用于执行冒烟脚本来确定pod状态

[zhu327]

当前iam容器后部署主要资源有

1. checker statefulset
2. transfer statefullset
3. worker deployment
4. iam http deployment

---

如使用BCS rollout 会有问题

1. 灰度不支持statefulset, 发布是新版的cheker/transfer会直接顶掉就版本
   • 已经顶调的statefulset会导致当前发布状态处于半更新状态, statefulset已经发布, 但是deployment还在灰
   • 如果需要回滚, statefulset需要手动操作回滚, 没有工具能直接回退到回滚的状态
2. worker/iam deployment如有灰度, 在达到配置的百分比时暂停, 需要手动执行冒烟测试
   • 如果冒烟失败需要回滚, 需要手动删除canary的deployment
   • 此时Rollout的资源状态改如何回退, 会不会影响下一次发布, 是黑盒的, 以及不清楚改如何回退状态
3. 冒烟测试
   • 当前rollout的hook机制不能有效的支持自动冒烟测试, 需要在发布状态暂停时, 手动执行

结论: 如使用Rollout的方式灰度, 一旦需要会退到发布前的状态, 需要手动执行很多的资源变更, 需要对灰度前与灰度后的部署状态有一个完整的记录, 方便回退到灰度前状态, 操作复杂, 变更出错的风险非常大

[wklken]

如果使用蓝绿的方式会不会更好? 完全部署两套, 命名空间/redis等层面隔离 部署完, 冒烟, 之后再按比例切流量(网关入口), 最后顶掉