• 操作步骤
• 升级捆绑的 PostgreSQL
• 将捆绑的 PostgreSQL 升级到 version 13
• 将捆绑的 PostgreSQL 升级到 version 12
• 升级到 7.0 版本
  • 更新捆绑的 Redis 子 chart
  • global.redis.password 的使用
  • Ingress userNewIngressForCerts
• 6.0 升级步骤
• 老旧版本升级指南

升级极狐GitLab chart

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

升级必须要遵循支持的升级路径。因为极狐GitLab chart 的版本并不跟随极狐GitLab 的版本，两者之间的详情可以查看版本映射。

我们还建议您先进行 备份。请注意必须使用 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 升级到新版本的操作步骤：

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

将捆绑的 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 版本

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。

Ingress userNewIngressForCerts

如果您正在讲当前的 7.x chart 升级到最新，而且将 global.ingress.useNewIngressForCerts 改为 true，您还必须升级任何既有的 cert-manger Certificate 对象来删除 acme.cert-manager.io/http01-override-ingress-nam 注释。

您必须要做此变更，因为将此属性设为 false（默认的），此注释被默认添加到 Certificates，而且 cert-manger 使用它来确认应该为哪个证书使用哪个 Ingress 方法。仅将此属性修改为 false 并不能自动删除此注释。需要手动执行操作，否则 cert-manager 会持续使用旧的行为来处理已存在的 Ingress 资源。

6.0 升级步骤

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

老旧版本升级指南

如果您正在从比 5.x 还老旧的版本进行升级，查看极狐GitLab 归档文档来访问老旧版本的文档。