自序

Gartner的报告指出，到2020年，将有50%的传统老旧应用会以云原生的方式被改造，到2022年，云原生和容器化的普及率将达到75%。

随着2020 KubeCon线上大会的结束，我们发现企业拥抱云原生、Kubernetes和Istio的热情空前高涨，这些技术无一例外都为“微服务”的普及铺设了更平坦的道路。

企业在拥抱云原生时，将伴随着对现有环境和业务的云原生化迁移，这往往会经历长时间多云环境共存的痛处。以迁移到Kubernetes为例，企业一般会选择从边缘业务逐渐延伸到核心业务的迁移方式，而迭代并不会因此停止，这就对交付和部署提出了新的挑战。更糟糕的是，如果企业已经采用了微服务架构，那么在这种多云环境下，对多个微服务的部署更是一种无法预测的行为。

因此，多云环境下的部署问题成为企业拥抱云原生、容器化和微服务时难以逾越的鸿沟，越来越多的企业已经注意到自己持续部署能力不足，并且尝试使用不同的工具组合来解决问题。例如，常见的是使用Ansible支持传统虚拟机的部署，使用Jenkins及其插件支持Kubernetes环境的部署。但由于这些工具对云和部署要素的抽象概念的定义并不一致，因此相关工作人员需要学习不同的概念，且需要经历不同的学习曲线，使用这些工具组合将会导致部署行为进一步陷入混沌状态。

大部分传统企业倾向于将运维团队设立为独立的组织架构，利用运维团队与开发团队天然的冲突和利益不一致，使得两者在这种组织冲突的平衡中实现产品交付和部署的动态平衡。

但从长远来看，这显然是不合理的。

像Netflix这种大型的敏捷团队更愿意将运维角色与开发角色融合，将运维职能沉淀到团队内部闭环，通过为团队提供一致性的工具，实现每个团队对持续部署的独特需求。这种内部闭环使信息流转问题得到了解决，由开发人员来决定何时以及如何进行部署，研发效率和交付质量得到了显著提升。

迁移至云原生所经历的困境也正是Netflix开发团队对统一化部署工具的诉求：云原生、混合云、持续自动化与安全部署。

Spinnaker正是Netflix多年来在持续部署方面的实践经验的结晶。它是一款开源的、支持云原生和多云环境的持续部署工具，目前支撑着Netflix数百个微服务和数万个节点混合云环境的持续部署。

2019年3月，Netflix和Google共同成立持续交付基金会（Continuous Delivery Foundation，CDF），并将Spinnaker捐赠给CDF，和大名鼎鼎的CNCF一样，CDF成了Linux基金会的一部分。CDF的其他成员包括Jenkins、Jenkins X、Tekton等顶尖的持续集成和持续部署项目。

毫无疑问，在CDF中，Jenkins的用户数量是最庞大的，但我认为Jenkins更多地属于持续集成（Continuous Integration，CI）工具。作为持续部署的集大成者，Spinnaker势必会成为团队技术选型的重点考虑对象。

在学习Spinnaker时，由于其概念复杂且上手难度较大，加上几乎没有适合中国工程师的学习资料，我遇到了非常多的“坑”。我想，其他希望学习Spinnaker的同学也会遇到同样的困境，所以我决定将自己的实践经验分享给所有人，这也是我撰写本书的出发点。

在本书的写作过程中，我被调至Nocalhost（云原生开发环境）项目中负责研发工作，研发工作异常艰辛，多线程的工作状态差点儿导致本书“难产”。庆幸的是，我的爱人始终陪伴和鼓励我，历时近9个月，我最终完成了全书的写作。

感谢我的领导王振威参与本书部分章节的写作和审校。感谢郭学坤、陈信州和彭梦姗，是他们的慧眼让我有幸参与到CODING的研发工作中。感谢为本书写推荐语的朋友们：张海龙、吴晟、张磊、孙建波、单致豪、宋净超、郑东旭和殷成文。感谢电子工业出版社博文视点的孙奇俏编辑。感谢我的家人。

最后，谨以此书献给我的爱人。

王炜
2021年8月