Help us learn about your current experience with the documentation. Take the survey.

从 GitLab 托管应用迁移到集群管理项目（已弃用）

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

GitLab 托管应用在 GitLab 14.0 版本中被弃用，转而采用用户控制的集群管理项目。通过项目管理集群应用相比之前的 GitLab 托管应用，能让你获得更大的灵活性来管理集群。要迁移到集群管理项目，你需要可用的 GitLab Runners 并熟悉 Helm。

迁移到集群管理项目

要从 GitLab 托管应用迁移到集群管理项目，请按照以下步骤操作。另请参阅带有示例的视频教程。

基于集群管理项目模板创建新项目。
在你的集群中为该项目安装 agent。
按照项目模板中的 .gitlab-ci.yml 说明，将 KUBE_CONTEXT CI/CD 变量设置为刚安装的 agent 的上下文。
使用预配置的 .gitlab-ci.yml 文件检测通过 Helm v2 版本部署的应用：
- 如果你曾覆盖了默认的 GitLab 托管应用命名空间，请编辑 .gitlab-ci.yml，并确保脚本接收到正确的命名空间作为参数：
```
script:
  - gl-fail-if-helm2-releases-exist <your_custom_namespace>
```
- 如果你保留了默认名称（gitlab-managed-apps），则脚本已经设置好了。
无论哪种情况，手动运行流水线并阅读 detect-helm2-releases 任务的日志，以了解你是否有任何 Helm v2 版本以及它们是什么。
如果没有 Helm v2 版本，请跳过此步骤。否则，请遵循官方 Helm 文档如何从 Helm v2 迁移到 Helm v3，并在确认它们已成功迁移后清理 Helm v2 版本。
在这一步中，你应该只有 Helm v3 版本了。从主要的 ./helmfile.yaml 中取消注释你想要用此项目管理的应用程序路径。虽然你可以一次性取消注释所有想要管理的应用，但你应该为每个应用分别重复以下步骤，这样在过程中不会迷失方向。
编辑关联的 applications/{app}/helmfiles.yaml 以匹配为你的应用部署的 chart 版本。以 GitLab Runner Helm v3 版本为例：

以下命令列出版本及其版本信息：
```
helm ls -n gitlab-managed-apps

NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
runner gitlab-managed-apps 1 2021-06-09 19:36:55.739141644 +0000 UTC deployed gitlab-runner-0.28.0 13.11.0
```
从 CHART 列中获取版本，格式为 {release}-v{chart_version}，然后编辑 ./applications/gitlab-runner/helmfile.yaml 中的 version: 属性，使其与你部署的版本匹配。这是一个安全步骤，可以避免在此迁移过程中升级版本。如果你的应用部署在不同的命名空间中，请确保替换前一个命令中的 gitlab-managed-apps。
编辑与你的应用关联的 applications/{app}/values.yaml 以匹配部署的值。例如，对于 GitLab Runner：
1. 复制以下命令的输出（可能会很大）：
```
helm get values runner -n gitlab-managed-apps -a --output yaml
```
2. 用上一个命令的输出覆盖 applications/gitlab-runner/values.yaml。
这个安全步骤确保没有意外的默认值覆盖你部署的值。例如，你的 GitLab Runner 可能会被意外覆盖其 gitlabUrl 或 runnerRegistrationToken。
某些应用需要特别关注：
- Ingress：由于现有的 chart 问题，在尝试运行 ./gl-helmfile 命令时，你可能会看到 spec.clusterIP: Invalid value。为了解决这个问题，在覆盖 applications/ingress/values.yaml 中的发布值后，你可能需要覆盖所有 omitClusterIP: false 的出现，将其设置为 omitClusterIP: true。另一种方法是运行 kubectl get services -n gitlab-managed-apps 收集这些 IP，然后用你从该命令获得的值覆盖每个它抱怨的 ClusterIP。
- Vault：这个应用从 Helm v2 中使用的 chart 到 Helm v3 中使用的 chart 引入了破坏性更改。因此，将其与此集群管理项目集成的唯一方法是实际卸载此应用并接受 applications/vault/values.yaml 中建议的 chart 版本。
- Cert-manager：
  - 对于 Kubernetes 1.20 或更高版本的用户，已弃用的 cert-manager v0.10 不再有效，并且升级包含破坏性更改。因此，我们建议你备份并卸载 cert-manager v0.10，并安装最新的 cert-manager。要安装此版本，请从 ./helmfile.yaml 中取消注释 applications/cert-manager/helmfile.yaml。这将触发一个流水线来安装新版本。
  - 对于 Kubernetes 版本低于 1.20 的用户，你可以通过取消注释项目主 Helmfile (./helmfile.yaml) 中的 applications/cert-manager-legacy/helmfile.yaml 来坚持使用 v0.10。
    
    当 Kubernetes 升级到 1.20 或更高版本时，cert-manager v0.10 会损坏。
完成所有前面的步骤后，手动运行流水线并查看 apply 任务的日志，以查看你的应用程序是否被成功检测、安装，以及是否有任何意外的更新。

预期一些注释校验和会被更新，以及这个属性：
```
--- heritage: Tiller
+++ heritage: Tiller
```

获得成功的流水线后，对于任何其他想要用集群管理项目管理的已部署应用，重复这些步骤。

备份并卸载 cert-manager v0.10

遵循官方文档了解如何备份你的 cert-manager v0.10 数据。
通过编辑 applications/cert-manager/helmfile.yaml 文件中所有 installed: true 出现的位置，将其更改为 installed: false 来卸载 cert-manager。
通过执行以下命令搜索任何剩余的资源：kubectl get Issuers,ClusterIssuers,Certificates,CertificateRequests,Orders,Challenges,Secrets,ConfigMaps -n gitlab-managed-apps | grep certmanager。
对于在上一步中找到的每个资源，使用 kubectl delete -n gitlab-managed-apps {ResourceType} {ResourceName} 删除它们。例如，如果你找到一个名为 cert-manager-controller 的 ConfigMap 类型的资源，通过执行以下命令删除它： kubectl delete configmap -n gitlab-managed-apps cert-manager-controller。

视频教程

你可以观看这些视频，了解如何从 GMA 迁移到集群管理项目的示例：

使用全新的集群管理项目从头开始迁移。还涵盖了 Helm v2 应用迁移。
从现有的 GitLab 托管应用 CI/CD 项目迁移。