升级极狐GitLab chart

在升级您的极狐GitLab 实例之前，您需要检查要升级的特定版本对应的 变更记录。

note 零停机升级不适用于 GitLab charts。

我们还建议您先进行 备份。请注意必须使用 helm upgrade --set key=value 语法或 -f values.yaml 提供所有 value 值，不要使用 --reuse-values，因为某些当前值可能会被废弃。

您可以使用 helm get values <release name> 来检索您以前的 --set 参数。如果您将其定向到文件中（helm get values <release name> > gitlab.yaml），您可以通过 -f 安全地传递文件，例如 helm upgrade gitlab gitlab-jh/gitlab -f gitlab.yaml，这样可以安全替代使用 --reuse-values 。

chart 和极狐GitLab 版本对照请参考版本对照文档。

操作步骤

note 如果您要升级到 7.0 版本的 chart，遵循 7.0 手动升级步骤。 如果您要升级到 5.0 版本的 chart，遵循 5.0 手动升级步骤。

在升级之前，请考虑一下您的设定值以及您是否可能“过度配置”了您的设置。我们希望您维护一小部分修改后的值，并利用大多数 chart 默认值。如果您通过以下方式配置了大量设置：

  • 复制计算设置
  • 复制所有设置并明确定义实际上与默认值相同的值

这几乎肯定会在升级过程中导致问题，因为配置结构可能会在不同版本之间发生变化，会导致应用设置出现问题。我们将在以下步骤中介绍如何检查这一点。

以下是将极狐GitLab 升级到新版本的操作步骤：

  1. 检查要升级的特定版本对应的 变更记录。
  2. 查看部署指导的详细操作步骤。

  3. 使用以下命令提取之前的 --set 参数。

    helm get values gitlab > gitlab.yaml
  4. 确定升级时需要继承的所有值。极狐GitLab 具有合理的默认值，在升级时，您可以尝试从上述命令中传递所有值，但它可能会导致由于配置在 chart 版本之间发生更改而可能无法顺利映射的场景。我们建议保留您要显式设置的最小的值集，并在升级过程中传递这些值。

  5. 使用上一步中提取的值执行升级：

    helm upgrade gitlab gitlab-jh/gitlab \
  --version <new version> \
  -f gitlab.yaml \
  --set gitlab.migrations.enabled=true \
  --set ...

在主数据库升级期间，我们要求您将 gitlab.migrations.enabled 设置为 false。确保您明确将其设置回 true 以便未来的更新。

升级捆绑的 PostgreSQL

note 如果您未使用捆绑的 PostgreSQL chart（postgresql.install 的值为 false），您不需要执行该步骤。

将捆绑的 PostgreSQL 升级到 version 13

极狐GitLab 14.1 及更高版本支持 PostgreSQL 13。PostgreSQL 13 带来显着的性能提升。

要升级绑定的 PostgreSQL 到 version 13，需要遵循以下步骤：

  1. 准备好现有的数据库。
  2. 删除现有的 PostgreSQL 数据。
  3. 更新 postgresql.image.tag 的值为 13.6.0，并重新安装 chart 去创建一个新的 PostgreSQL 13 数据库。
  4. 恢复数据库。

将捆绑的 PostgreSQL 升级到 version 12

作为 5.0.0 发布版本 chart 的一部分，我们将捆绑的 PostgreSQL 版本从 11.9.0 升级到 12.7.0。这并非完全的替代，您需要执行手动步骤去升级数据库，了解操作步骤，请查看 5.0 升级步骤。

升级到 7.0 版本

caution 如果您要从 6.x 版本的 chart 升级到最新的 7.0 版本，您需要先更新到最新的 6.11.x 补丁版本才能继续升级。7.0 发行说明描述了支持的升级路径。

7.0.x 版本可能需要手动步骤才能执行升级。

  • 如果使用捆绑的 bitnami/Redis 子 chart 来提供集群内 Redis 服务 - 您需要在升级到 GitLab chart 7.0 版之前，手动删除 Redis 的 StatefulSet。按照下面升级捆绑的 Redis 子 chart 中的设置进行操作。

更新捆绑的 Redis 子 chart

极狐GitLab chart 的 7.0 版，将捆绑的 bitnami/Redis 子 chart 从之前安装的 11.3.4 更新为版本 16.13.2。由于子 chart 中的 redis-master StatefulSet 应用了 matchLabels 的变更，进行升级前，不手动删除 StatefulSet 会导致如下错误：

Error: UPGRADE FAILED: cannot patch "gitlab-redis-master" with kind StatefulSet: StatefulSet.apps "gitlab-redis-master" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy' and 'minReadySeconds' are forbidden

删除 RELEASE-redis-master 的 StatefulSet：

  1. 将 webservice、sidekiq、kas 和 gitlab-exporter 部署的副本缩小到 0：

    kubectl scale deployment --replicas 0 --selector 'app in (webservice, sidekiq, kas, gitlab-exporter)' --namespace <namespace>

  2. 删除 RELEASE-redis-master StatefulSet：

    kubectl delete statefulset RELEASE-redis-master --namespace <namespace>
    • <namespace> 应该替换为安装 GitLab chart 的命名空间。

然后按照正常升级步骤。由于 Helm 合并更改的方式，您可能需要手动扩展在第一步中缩小的 deployments。

global.redis.password 的使用

为了减轻配置类型与使用 global.redis.password 的冲突，我们已弃用 global.redis.password 转而支持 global.redis.auth。

除了显示弃用通知之外 - 如果您执行 helm upgrade 时看到以下警告消息：

coalesce.go:199: warning: destination for password is a table. Ignoring non-table value

这表明您正在值文件中设置 global.redis.password。

6.0 升级步骤

caution 如果您从 5.x 版本的 chart 升级到最新的 6.0 版本，您需要先更新到最新的 5.10.x 补丁版本才能使升级工作。 6.0 发行说明描述了支持的升级路径。

要升级到 6.0 版本，您必须首先使用最新的 5.10.x 补丁版本。6.0 中不需要任何额外的手动更改，因此您可以按照常规版本升级步骤进行升级。

5.9 升级步骤

Sidekiq pod 永远不会 ready

升级到 5.9.x 可能会导致 Sidekiq pod 未准备好。Pod 启动并且似乎工作正常，但从不监听默认指标端点端口 (metrics.port) 的 3807。 因此，Sidekiq pod 未被视为准备就绪。

这可以从 管理中心 解决：

  1. 在左侧边栏上，选择 搜索或转到。
  2. 选择 管理中心。
  3. 选择 设置 > 指标和分析。
  4. 展开 指标 - Prometheus。
  5. 确保启用 启用运行状况和性能指标端点。
  6. 重启受影响的 Pod。

5.5 升级步骤

task-runner chart 被重命名为 toolbox 并在 5.5.0 中被移除。因此，您的配置中任何提及 task-runner 的内容都应重命名为 toolbox。 在 5.5 及更高版本中，使用 toolbox chart，在 5.4 及更早版本中，使用 task-runner chart。

缺少对象存储 secret 错误

升级到 5.5 或更高版本可能会导致类似以下的错误：

Error: UPGRADE FAILED: execution error at (gitlab/charts/gitlab/charts/toolbox/templates/deployment.yaml:227:23): A valid backups.objectStorage.config.secret is needed!

如果错误中提到的 secret 已经存在并且是正确的，那么这个错误很可能是因为有一个对象存储配置值仍然引用了 task-runner 而不是新的 toolbox。在您的配置中将 task-runner 重命名为 toolbox 以解决此问题。

5.0 升级步骤

caution 如果您要从 4.x 版本的 chart 升级到最新的 5.0 版本，您需要先更新最新的 4.12.x 补丁版本以便升级。

5.0.0 版本需要手动步骤才能执行升级。如果您使用捆绑的 PostgreSQL，执行升级的最佳方法是备份旧数据库，然后将数据恢复到新的数据库实例中。

caution 在继续升级之前，记得进行备份。未能按照操作步骤执行，可能导致您的 数据库丢失。确保您有单独的备份。

如果您在使用外部 PostgreSQL 数据库，您应该首先将数据库升级到 12 或更高版本。然后遵循常规升级步骤

如果您使用捆绑的 PostgreSQL 数据库，您应该遵循捆绑数据库升级步骤。

5.0 版本升级过程故障排查

  • 如果升级过程中观察到任何失败提示，您可以检查 gitlab-upgrade-check pod 的描述信息，获取更多信息：

    kubectl get pods -lrelease=RELEASE,app=gitlab
kubectl describe pod <gitlab-upgrade-check-pod-full-name>