• 先决条件
  • kubectl
  • Helm
  • PostgreSQL
  • Redis
• 决定其他选项
  • Secrets
  • 网络和 DNS
    • external-dns 动态 IP 地址
    • 固定 IP 地址
    • 与 Istio 协议选择的兼容性
  • 持久化
  • TLS 证书
  • Prometheus
    • 配置 Prometheus 抓取启用了 TLS 的端点
    • 导出器端点
  • 外发电子邮件
  • 接收电子邮件
  • 服务台电子邮件
  • RBAC

安装极狐GitLab chart 的先决条件

在 Kubernetes 集群中部署极狐GitLab 之前，请安装以下先决条件，并决定安装时将使用的选项。

先决条件

kubectl

按照 Kubernetes 文档安装 kubectl。

您安装的版本必须是在集群中运行的版本的一个小版本中。

Helm

按照 Helm 文档，安装 Helm v3.3.1 或更高版本。

PostgreSQL

默认情况下，极狐GitLab chart 包含由 bitnami/PostgreSQL 提供的集群内 PostgreSQL 部署。 此部署仅供试用，不建议在生产中使用。

您应该设置一个外部的、生产就绪的 PostgreSQL 实例。PostgreSQL 13 是自极狐GitLab chart 6.0 以来推荐的默认版本。

从极狐GitLab chart 4.0.0 开始，复制在内部可用，但默认情况下未启用。尚未对此类功能进行负载测试。

Redis

默认情况下，极狐GitLab chart 包含由 bitnami/Redis 提供的集群内 Redis 部署。 此部署仅供试用，不建议在生产中使用。

您应该设置一个外部、生产就绪的 Redis 实例。有关所有可用的配置设置，请参阅 Redis 全局配置文档。

从极狐GitLab chart 4.0.0 开始，复制在内部可用，但默认情况下未启用。尚未对此类功能进行负载测试。

决定其他选项

部署极狐GitLab 时，您将在使用 helm install 时，使用以下选项。

Secrets

您必须创建一些 secrets，例如 SSH 密钥。默认情况下这些 secrets 会自动生成，但是如果您想要对它们进行自定义配置，您可以遵循 secrets 指导。

网络和 DNS

默认情况下，为了公开服务，极狐GitLab 使用配置了 Ingress 对象的基于名称的虚拟服务器。这些对象是 type: LoadBalancer 的 Kubernetes Service 对象。

您必须指定一个包含记录的域名，将 gitlab、registry 和 minio（如果启用）解析为 chart 的适当 IP 地址。

例如，将以下配置与 helm install 一起使用：

--set global.hosts.domain=example.com

启用自定义域名支持后，默认为 <pages domain> 的 *.<pages domain> 子域名将变为 pages.<global.hosts.domain>。域名解析为由 --set global.pages.externalHttp 或 --set global.pages.externalHttps 分配给 Pages 的外部 IP。

要使用自定义域名，Pages 可以使用 CNAME 记录，将自定义域名指向相应的 <namespace>.<pages domain> 域名。

external-dns 动态 IP 地址

如果您计划使用自动 DNS 注册服务，例如 external-dns，您不需要对极狐GitLab 进行额外配置，但您需要在集群中部署。如果您选择了 external-dns，项目页面会为每个支持的提供商显示完整指导。

如果您使用仓库中的脚本配置了 GKE 集群，external-dns 已在您的集群中安装。

固定 IP 地址

如果您计划手动配置 DNS 记录，他们应全部指向一个固定 IP 地址。例如您拥有 example.com 和固定 IP 10.10.10.10，则 gitlab.example.com, registry.example.com 和 minio.example.com （如果使用 MinIO）应全部解析到 10.10.10.10。

如果您使用 GKE，配置固定 IP 和 DNS。在配置过程中，请查阅云提供商和 DNS 提供商的文档获取更多帮助。

例如，将以下配置与 helm install 一起使用：

--set global.hosts.externalIP=10.10.10.10

与 Istio 协议选择的兼容性

服务端口名称遵循与 Istio 的端口选择兼容的约定。 看起来像 <protocol>-<suffix>，例如 grpc-gitaly 或 https-metrics。

持久化

默认情况下，chart 将创建 Volume Claims，预期存在动态 provisioner 提供底层持久卷。如果您想自定义 storageClass 或手动创建挂载 volumes，请查看存储文档。

TLS 证书

您应该使用 https 并配置 TLS 证书来运行极狐GitLab。chart 默认安装并配置 cert-manager 获得免费 TLS 证书。

如果您拥有通配符证书，您已安装 cert-manager，或有其它获取 TLS 证书的方法，请查阅 TLS 选项文档。

对于默认配置，您必须指定 email 地址去注册您的 TLS 证书。

对于默认配置，您必须指定一个电子邮件地址来注册您的 TLS 证书。例如，将以下配置与 helm install 一起使用：

--set certmanager-issuer.email=me@example.com

Prometheus

我们使用上游 Prometheus chart，不要覆盖其它默认文件的值，除了自定义的 prometheus.yml 文件，该文件用于限制收集 Kubernetes API 的指标数据，以及由极狐GitLab chart 创建资源的指标数据。默认禁用 alertmanager，nodeExporter 和 pushgateway。

prometheus.yml 文件控制 Prometheus 从具有 gitlab.com/prometheus_scrape annotation 的资源中收集指标。此外，也可以使用 gitlab.com/prometheus_path 和 gitlab.com/prometheus_port annotations 配置指标的收集方式。每一个 annotation 与 prometheus.io/{scrape,path,port} annotation 相似。

如果您使用 Prometheus 监控极狐GitLab 应用，原始的 prometheus.io/* annotation 仍添加到适当的 Pods 和 Services 中。这样允许已有用户持续收集指标，且可以提供在同一个 Kubernetes 集群中，同时抓取极狐GitLab 应用指标和其它应用指标的能力。

参考 Prometheus chart 文档，了解配置选项的详尽列表。prometheus 是我们使用的必需 chart，确保其中的配置项是 prometheus 的子项。

对于实例，持久存储的请求由以下配置内容控制：

prometheus:
  alertmanager:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  pushgateway:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  server:
    persistentVolume:
      enabled: true
      size: 8Gi

配置 Prometheus 抓取启用了 TLS 的端点

如果给定的导出器允许 TLS，并且 chart 配置公开了导出器端点的 TLS 配置，则可以将 Prometheus 配置为从启用了 TLS 的端点抓取指标。

使用 TLS 和 Kubernetes 服务发现用于 Prometheus 抓取配置时有一些注意事项：

• 使用 pod 和服务端点发现角色 - Prometheus 使用 Pod 的内部 IP 地址来设置抓取目标的地址。要验证 SSL 证书，Prometheus 需要配置为在为指标端点创建的证书中设置的通用名称 (CN)，或者配置为包含在主题备用名称 (SAN) 扩展中的名称。该名称不必解析，可以是任意字符串，即有效的 DNS 名称。
• 如果用于导出器端点的证书是自签名的，或不存在于 Prometheus 基础镜像中 - Prometheus pod 需要为证书颁发机构 (CA) 安装证书，该证书颁发机构 (CA) 签署了用于导出器端点的证书。Prometheus 在其基础镜像中使用 Debian 的 ca-bundle。
• Prometheus 支持使用应用于每个抓取配置的 tls_config 设置这两个项目。虽然 Prometheus 具有强大的 relabel_config 机制，用于根据 Pod annotations 和其他发现的属性设置 Prometheus 目标标签，但设置 tls_config. server_name 和 tls_config.ca_file 不能使用 relabel_config。查看 Prometheus 项目议题了解详情。

鉴于这些注意事项，最简单的配置是在用于导出器端点的所有证书中共享一个“名称”和 CA：

1. 为 tls_config.server_name 选择一个任意名称（例如，metrics.gitlab）。
2. 将该名称添加到用于对导出器端点进行 TLS 加密的每个证书的 SAN 列表中。
3. 从同一 CA 颁发所有证书：
   • 将 CA 证书添加为集群 secret。
   • 使用 Prometheus chart 的 extraSecretMounts: 配置，将该 secret 挂载到 Prometheus 服务器容器中。
   • 将其设置为 Prometheus scrape_config 的 tls_config.ca_file。

Prometheus TLS 值示例通过以下方式提供了此共享配置的示例：

1. 为 pod/endpoint scrape_config 角色设置 tls_config.server_name 为 metrics.gitlab。
2. 假设 metrics.gitlab 已添加到用于导出端点的每个证书的 SAN 列表中。
3. 假设 CA 证书已添加到名为 metrics.gitlab.tls-ca 的密钥中，密钥也名为 metrics.gitlab.tls-ca，在部署 Prometheus chart 的同一命名空间中创建（例如，kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem）。
4. 使用 extraSecretMounts: 条目将 metrics.gitlab.tls-ca secret 挂载到 /etc/ssl/certs/metrics.gitlab.tls-ca。
5. 将 tls_config.ca_file 设置为 /etc/ssl/certs/metrics.gitlab.tls-ca。

导出器端点

并非 chart 中包含的所有指标端点都支持 TLS。 如果端点启用了 TLS，还将设置 gitlab.com/prometheus_scheme: "https" 注释，以及 prometheus.io/scheme: "https" 注释，其中任何一个都可以与 relabel_config 一起使用，来设置 Prometheus __scheme__ 目标标签。 Prometheus TLS 值示例包含一个针对 __scheme__ 的 relabel_config，使用 gitlab.com/prometheus_scheme: "https" 注释。

下表列出了应用了 gitlab.com/prometheus_scrape: true 注释的部署（或使用 Gitaly 和 Praefect 中的一个或两者时）和服务端点。

在下面的文档链接中，如果组件提到添加 SAN 条目，请确保您还添加了您决定用于 Prometheus tls_config.server_name 的 SAN。

对于 webservice pod，暴露的端口是 webservice 容器中的独立 webrick 导出器。Workhorse 容器端口不抓取。有关更多详细信息，请参阅 Webservice Metrics 文档。

外发电子邮件

Outgoing email 默认禁用。如果要启用，使用 global.smtp 和 global.email 设置提供您的 SMTP 服务器的详细信息。您可以在 命令行选项文档中查看相关信息。

如果您的 SMTP 服务器需要认证，确保阅读 secrets 文档 中关于提供密码的相关部分。您可以使用 --set global.smtp.authentication="" 禁用认证。

如果您的 Kubernetes 集群部署在 GKE，请注意 SMTP 端口 25 被关闭。

接收电子邮件

了解该配置请参考 mailroom chart 文档。

服务台电子邮件

了解该配置请参考 mailroom chart 文档。

RBAC

该 chart 默认创建和使用 RBAC。如果您的集群未启用 RBAC，您需要禁用以下设置：

--set certmanager.rbac.create=false
--set nginx-ingress.rbac.createRole=false
--set prometheus.rbac.create=false
--set gitlab-runner.rbac.create=false