银行重要的业务场景如何用k8s做滚动更新？

这个问题细说的话就多了，需要看业务场景。强一致性交易类业务，像消费之类的需要应用本身来保证，事务失败要能回滚。那版本升级回滚就要有优雅停机的动作，一些渠道类交易，只是做中间转接，一般是可以直接做升级回滚的。
升级回滚的操作，主要是通过替换应用依赖的镜像版本。k8s的升级回滚是利用新版本镜像或者旧版本镜像拉起一个新pod，下线一个旧pod依次完成此操作的，保证业务正常运行。

平台方面：结合K8s的流量分发，实现金丝雀发布机制，通过精细的流量控制，来实现业务的滚动更新。应用方面：应用需要有合理的设计，在规划时就需要有相关的设计，对应用有合理的低耦合的切分，尽量减少发布应用的涉及面，这其中最重要的如何实现问题的回退，特别是影响到账务数据的，采用数据染色或是零时表的方式，尽量做到应用可回溯。

这个问题可以结合着蚂蚁作大规模发布的时候所关注的变更管理来回答。

原生 deployment 做灰度或者金丝雀发布时，默认情况下在 Pod 变更和流量治理层面的管控还稍显不足，无法完全做到无损发布或按需过程管控。因此，我们在 PaaS 产品层面做了定制，在 Kubernetes 层面做了自定义资源的扩展，目的是能够在云原生的场景下，依然对整个发布过程实现精细化管控，使得大规模集群发布、灰度、回滚时更加优雅，符合技术风险三板斧原则。

在实际的生产环境中，围绕容器大规模变更会配合业务监控及更多维度的观察，确保每一步都是符合预期、验证通过的。这样在应用实例层面的精细化管控，为运维提供了能够及时刹车回滚的机会，是线上应用发布的一个重要的保险绳。

简单来说，在蚂蚁内部所有的变更要满足” 可灰度、可监控、可应急 “，当基础设施全面转向云原生，就开始基于Kubernetes作了非常多扩展和补充。对于金融业务场景，从实际产品层，需要做到：

1. 感知底层拓扑
2. 分组/beta/分批发布 

3. 优雅摘流

   云原生应用 PaaS 平台的建设实践
   https://www.infoq.cn/article/gT1pKC2o5W8bTFcTGtOD

探秘金融级云原生发布工作负载 CafeDeployment
https://yq.aliyun.com/articles/705857

欢迎交流。