Spinnaker是Netflix开源的持续交付平台，提高了持续交付系统的可复用性，提供了稳定可靠的API，提供了对基础设施和程序全局性的视图，配置、管理、运维都更简单。更重要的是它支持多种外部的Triggers，支持K8S并且能够对发布流程进行管理。而在使用过程中，发现有两个痛苦的地方，第一个来自于Spinnaker系统复杂性带来的构建难度，另外一个来自于Spinnaker Pipelines流程的编排。搭建的文档网上很多，这里主要分享下如何使用Pipelines管理K8S容器发布。
注意：我们使用的Spinnaker对接的是K8S-v2版本的provider，Spinnaker官方在v2版本已经放弃了更多的点点点的傻瓜式操作，估计是想通过Pipelines声明的方式来管理发布流程，虽然易用性上有了门槛，但其实对于整个运维发布过程来讲会有很多好处。不多说，开干。
首先，创建一个应用，查看已经创建好的几个Pipelines：
1. 查看整个发布的Pipeline
Pipelines中配置了Jenkins的Trigger：
Stage1: 环境变量
Stage2: 预发布环境的yaml部署配置
Stage3: 发布审核
Stage4: 预发环境发布钩子
Stage5: 生产环境Yaml配置(和预发环境基本相同，环境变量引用的区别)
Stage6: 最终发布完成的钩子
2. 使用Jenkins触发CI
我们Jenkins的构建产物是Docker image，由于Spinnaker已经配置好了Pipeline，我们拿到tag之后即可对指定版本进行发布。
3. 使用Spinnaker的Pipeline发布流程
手动执行一次Pipeline发布
提示选择Jenkins构建的产物版本
预发发布过程
发布成功后会通知并且需要人工审核
发布通知
查看发布结果
发布审核
审核通过后自动进行生产环境发布通知
查看发布结果
查看应用的集群信息
4. Scale Out
选择生产环境进行副本扩容
查看发布结果
5. Deploy One More
提交一次代码
使用Jenkins构建完成后再次手动执行Pileline发布
发布结果验证
注意:由于我们是重新发布的，之前新扩容的版本会被缩容成pipelines中定义的副本数量
6. RollBack
由于发布了两次，每个deployment其实会有两个版本，回滚就是根据版本进行回滚的。
7. Destory App
至此，使用Spinnaker对K8S上的应用进行了一次全流程的部署实践，虽然看起来较为复杂，但是整体的发布过程还是非常清晰且严谨的。
原文作者：云原生运维技术；如有侵权，请联系管理员删除。
