• 典型安装
• 配置集群存储
  • 建议
  • Storage Class 简易配置
  • 使用自定义 Storage Class
• 使用静态 Volume Provisioning
  • 使用 Google GKE
  • 使用 Amazon EKS
  • 手动创建 PersistentVolumeClaims
• 安装后更改存储
• 可选卷

存储指南

GitLab Chart 中的以下应用程序需要持久存储来维护状态。

• Gitaly（持久化 Git 存储库）
• PostgreSQL（持久化 GitLab 数据库数据）
• Redis（持久化 GitLab 作业数据）
• MinIO（持久化对象存储数据）

管理员可以选择使用动态或静态 volume provisioning 提供存储。

重要: 通过预先规划，最大限度减少安装后额外的存储迁移任务。 第一次部署后所做的更改，需要在运行 helm upgrade 之前，手动编辑现有的 Kubernetes 对象。

典型安装

安装程序使用默认 storage class和动态 volume provisioning创建存储。 应用通过 Persistent Volume Claim 连接到此存储。 当可用时，建议管理员使用 动态 volume provisioning 而不是 静态 volume provisioning。

管理员应该使用 kubectl get storageclass 确定其生产环境中的默认 storage class。 然后使用 kubectl describe storageclass *STORAGE_CLASS_NAME* 检查它。某些提供商（例如 Amazon EKS）不提供默认 storage class。

配置集群存储

建议

默认的 storage class 应该：

• 可用时使用快速 SSD 存储
• 设置 reclaimPolicy 为 Retain

在没有将 reclaimPolicy 设置为 Retain 的情况下卸载 GitLab 实例，将允许自动化作业完全删除卷、磁盘和数据。 一些平台将默认的 reclaimPolicy 设置为 Delete。 gitaly 的 persistent volume claims 不遵循此规则，因为其适用于 StatefulSet。

Storage Class 简易配置

以下 YAML 配置提供了为极狐GitLab 创建自定义 storage class 所需的最低要求。将 CUSTOM_STORAGE_CLASS_NAME 替换为适合目标安装环境的值。

• GKE on Google Cloud 的 storage class 示例
• Amazon Web Services 的 EKS 示例

Amazon EKS 可能表现出以下现象：节点的创建并不总是与 Pod 位于同一区域。设置上面的 zone 参数将降低任何风险。

使用自定义 Storage Class

将自定义 storage class 设置为集群默认值，它将用于所有动态 provisioning。

kubectl patch storageclass CUSTOM_STORAGE_CLASS_NAME -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Alternatively, the custom storage class and other options may be provided per service to Helm during installation. View the provided example configuration file and modify for your environment.

或者，可以在安装期间向 Helm 提供每个服务的自定义 storage class 和其它选项。查看示例配置文件并针对您的环境进行修改。

helm install -upgrade gitlab gitlab-jh/gitlab -f HELM_OPTIONS_YAML_FILE

阅读以下内容，了解更多额外的持久化选项：

• Gitaly 持久化配置
• MinIO 持久化配置
• Redis 持久化配置
• 上游 PostgreSQL chart 配置

Note: 一些高级持久性选项在 PostgreSQL 和其他组件之间有所不同，因此在进行更改之前检查每个选项的特定文档很重要。

使用静态 Volume Provisioning

建议使用动态 volume provisioning，但是，某些集群或环境可能不支持它。

管理员需要手动创建 Persistent Volume。

使用 Google GKE

1. 在集群中创建一个持久化磁盘。

gcloud compute disks create --size=50GB --zone=*GKE_ZONE* *DISK_VOLUME_NAME*

1. 修改示例 YAML 配置后创建 Persistent Volume。

kubectl create -f *PV_YAML_FILE*

使用 Amazon EKS

1. 在集群中创建一个持久化磁盘。

aws ec2 create-volume --availability-zone=*AWS_ZONE* --size=10 --volume-type=gp2

1. 修改示例 YAML 配置后创建 Persistent Volume。

kubectl create -f *PV_YAML_FILE*

手动创建 PersistentVolumeClaims

Gitaly 服务使用 StatefulSet 进行部署。使用以下命名约定创建 PersistentVolumeClaim，以便正确识别和使用。

<mount-name>-<statefulset-pod-name>

Gitaly 的 mount-name 是 repo-data。 StatefulSet pod 名称是使用以下方法创建的：

<statefulset-name>-<pod-index>

GitLab Cloud Native Chart 使用以下方法确定 statefulset-name：

<chart-release-name>-<service-name>

Gitaly PersistentVolumeClaim 的正确名称是：repo-data-gitlab-gitaly-0。

Note: 如果将 Praefect 与多个虚拟存储一起使用，则每个定义的虚拟存储的每个 Gitaly 副本都需要一个 PersistentVolumeClaim。 例如，如果你定义了 default 和 vs2 虚拟存储，每个都有 2 个副本，那么你需要以下 PersistentVolumeClaims： - repo-data-gitlab-gitaly-default-0 - repo-data-gitlab-gitaly-default-1 - repo-data-gitlab-gitaly-vs2-0 - repo-data-gitlab-gitaly-vs2-1

修改示例 YAML 配置并在调用 helm 时引用它。

其它不使用 StatefulSet 的服务允许管理员为配置提供 volumeName。此 Chart 仍将负责创建 volume claim 并尝试绑定到手动创建的卷。检查每个包含的应用程序的 chart 文档。 对于大多数情况，只需修改示例 YAML 配置，仅保留将使用手动创建的磁盘卷的那些服务。

安装后更改存储

初始安装后，存储更改（如迁移到新卷或更改磁盘大小）需要在 Helm upgrade 命令之外编辑 Kubernetes 对象。

请参阅 管理持久卷文档。

可选卷

对于较大的安装，您可能需要向 Toolbox 添加持久存储以使备份/还原正常工作。有关如何执行此操作的指南，请参阅我们的故障排查文档。