Kubernetes实战指南：零宕机无缝迁移Spring Cloud至k8s

1. 项目迁移背景

1.1 为什么要在“太岁”上动土？

目前公司的测试环境、UAT环境、生产环境均已经使用k8s进行维护管理，大部分项目均已完成容器化，并且已经在线上平稳运行许久。在我们将大大小小的项目完成容器化以后，测试、UAT、生产环境的发版工具以及CICD流程慢慢的实现统一化管理，并且基于k8s开发了内部的发版审核平台，同时接入了Jira等项目管理工具。

在自研平台进行发版时，能够自动关联项目的开发进度以及Release版本，最重要的是其可以控制发版权限、统一发版工具及发版模式，并且支持一键式发版多个项目的多个模块，同时也包括了发版失败应用的统一回滚及单个应用的回滚。

因为该项目从始至今一直在使用GitRunner进行发版，并且基于虚机部署，所以一直没有集成到发版审核平台，但是由于项目比较重要，并且涉及的服务和机器较多，所以必须要把这个项目进行容器化并且统一发版工具才能更好的适应公司的环境，以及更好的应对下一代云计算的发展。

1.2 为什么要弃用Git Runner？

首先我们看一下Git Runner发版的页面，虽然看起来很简洁清爽，但是也难免不了会遇到一些问题。

1.2.1 多分支并行开发问题

当多分支并行开发或者能够发版到生产环境的分支较多时，很容易在手动部署的阶段点错，或者看串行，当然这种概率很小。

但是我们可以看到另外一个问题，每次提交或者合并，都会触发构建，当我们使用Git Flow分支流时，可能同时有很多分支都在并行开发、并行测试、并行构建，如果Git Runner是基于虚机创建的，很有可能会出现构建排队的情况，当然这个排队的问题，也是能解决的。

1.2.2 多微服务配置维护问题

其次，如果一个项目稍微大一些，维护起来也不是很方便。比如这个准备要迁移的项目，一个前端和二十多个业务应用，再加上Zuul、ConfigServer、Eureka将近三十个服务，每个服务对应一个Git仓库，然后每个服务同时在开发的分支又有很多，如果想要升级GitLab CI脚本或者微服务的机器想要添加节点，这将是一个枯燥乏味的工作。

1.2.3 安全问题

最后，还有一个安全的问题，GitLab的CI脚本一般都是内置在代码仓库里面的，这就意味着任何有Push或者Merge权限的人都可以随意的修改CI脚本，这会导致意想不到的结果，同时也会威胁到服务器和业务安全，针对发版而言，可能任何的开发者都可以点击发版按钮，这些可能一直都是一个安全隐患。

但是这些并不意味着Gi