架构比较
DevOps 2.1 升级到 3.0 的过程中，遇到的问题很大程度是由于架构发生变化，用户使用方式不可控，复杂度上升导致。但这种变化是符合云原生的集成方式、符合技术趋势的。下面简单比较一下 2.1 和 3.0 DevOps 技术架构。
2.1
如上图，在 2.1 中数据存储在 Jenkins。平台中的 MySQL 存储的是权限信息，项目与流水线、人员的对应关系。
前端用户通过 Api Gateway 调用接口，经过 ks-apiserver 认证之后，达到 Jenkins。
另一类比较特殊的是 /kapis/jenkins.kubesphere.io 通过 Api Gateway 直接透传到 Jenkins，主要是下载归档文件时使用。
3.0
如上图，在 3.0 中数据存储在 CRD。CRD 中的数据单向同步到 Jenkins，如果之前有同名数据会被覆盖。
主要有两类操作: 一类是创建类型的操作，另一类是触发类型的操作。
创建类型的操作，主要包括三种 CRD 类型的创建，DevopsProject、Pipeline、Credential 。用户通过前端，调用 ks-apiserver 接口，创建对应资源存储在 Etcd 中，然后 ks-controller-manager 不断地将这些对象同步到 Jenkins 。
触发类型的操作，主要是执行、审核流水线等瞬时动作。用户通过前端，调用 ks-apiserver 经过数据转换，直接调用 Jenkins API 。
2.1 升级 3.0 数据迁移逻辑
处理逻辑:
- 从 MySQL 获取 DevOps 目录信息
- 从 Jenkins 获取流水线、凭证等信息
- 将上面的信息序列化到 Yaml 文件中
- 将 Yaml 对象资源备份到 minio 对象存储中
- kubectl apply 这些流水线资源
- 权限迁移
迁移前后数据对比:
| 影响项 | 2.0 | 3.0 |
|---|
| DevOps 工程 | MySQL | CRD |
| 流水线 | Jenkins | CRD |
| 凭证 | Jenkins | CRD |
| 权限 | MySQL | CRD |
数据迁移方案及风险
如果仅使用 KubeSphere DevOps 页面创建流水线，通常都可以正常迁移。但可能部分用户直接在 Jenkins 的页面，对流水线进行了配置。那么迁移的过程中，可能会导致这部分配置丢失。
直接使用 Job 迁移，适用仅通过 KubeSphere 页面操作 DevOps 的用户
直接正常升级即可。如果升级之后，查看不到 DevOps 资源，可以反复执行。
老数据不迁移，新流水线通过 KubeSphere 管理，适用大量通过 Jenkins 页面修改流水线的用户
KubeSphere DevOps 兼容了大部分的 Jenkins 的配置，但不是全部。对于使用 Jenkins 页面配置的某些项，在 KubeSphere DevOps 中没有得到支持。如下图：
这些配置在数据迁移之后，将被清除。即使迁移后，再加上去，下一次对流水线进行编辑时，也会被清理。
如果需要这些配置，可以给我们提交建议。值得注意的是，这些配置通常不能配置在 Jenkinsfile 中，因为他们不是执行流水线时的逻辑。
因此，建议这类用户，保持老数据不迁移，新的流水线在 KubeSphere 页面进行管理。注意在同一个 DevOps 工程下，不要创建同名的流水线，否则会覆盖 Jenkins 的数据。
去掉额外的配置，部分迁移，适合于在 Jenkins 页面少量修改流水线的用户
如果在 Jenkins 页面修改流水线不多，建议还是使用 KubeSphere DevOps 来管理流水线，这样会得到社区更多的支持。
建议这类用户可以直接备份之后，使用 Job 进行数据迁移，然后逐步修复特殊配置过的流水线。
如果对可用性非常敏感，可以复用之前的 DevOps 工程，然后人工创建一个新流水线（注意不要同名）。在确定新的流水线能正常工作之后，再删除之前的流水线。
常见问题及答案
可以参考文档 使用 Velero 备份 Kubernetes 集群 进行 PVC 级别的备份。
也可以直接备份 Jenkins Pod 中的 /var/jenkins_home 目录。
一定要备份，因为数据迁移创建 CRD 之后，ks-controller-manager 会覆盖 Jenkins 中的数据。一旦开始迁移数据，之前的数据将无法找回。
升级会遇到各种问题，通常主要观察的是组件，而后再检查数据。可以执行 kubectl get devopsprojects --all-namespaces 和 kubectl get pipelines --all-namespaces 判断是否发生了数据迁移。
如果确定准备迁移，那么可以反复执行 Job，操作是幂等，可以重入的。
kubectl -n kubesphere-system get job ks-devops-migration -o json | jq 'del(.spec.selector)' | jq 'del(.spec.template.metadata.labels)' | kubectl replace --force -f -
参考文档
