• 设计选择
  • 必需
  • 可选
• 配置
• 安装参数
• Chart 配置示例
  • pullSecrets
  • tolerations
  • annotations
• 启用子 chart
• 配置 image
• 配置 service
• 配置 ingress
• 配置 TLS
  • 为调试端口配置 TLS
• 配置 networkpolicy
  • 防止连接到所有内部端点的示例策略
• 配置 KEDA
• 定义 Registry 配置
  • httpSecret
  • Notification Secret
  • Redis 缓存 Secret
  • authEndpoint
  • certificate
  • readiness and liveness 探针
  • validation
    • manifests
  • notifications
  • hpa
  • storage
  • middleware.storage
    • keypairid 变体
  • debug
  • health
  • reporting
  • profiling
  • database
    • 创建数据库
  • gc 参数
  • Redis 缓存
    • Sentinels
• 垃圾收集
  • 手动垃圾收集
  • 针对容器镜像库运行管理命令

使用容器镜像库

registry 子 chart 为在 Kubernetes 上的完整云原生 GitLab 部署提供了 Registry 组件。该子 chart 使用了上游中包含 Docker Distribution 的 registry 容器。该 chart 由 3 个主要部分组成：Service、Deployment 和 ConfigMap。

所有配置都根据官方 Registry 配置文档处理，使用提供变量给 Deployment 的 /etc/docker/registry/config.yml，从 ConfigMap 填充的。 ConfigMap 覆盖上游默认值，但基于配置文件。

获取更多细节，参阅下述示例：

• distribution/cmd/registry/config-example.yml
• distribution-library-image/config-example.yml

设计选择

选择 Kubernetes Deployment 作为此 chart 的部署方法，以允许简单的实例扩展，同时允许滚动更新。 该 chart 使用了两个必需的 secret 和一个可选的 secret：

必需

• global.registry.certificate.secret：包含公共证书包的全局 secret，用于验证关联的 GitLab 实例提供的身份验证令牌。有关使用 GitLab 作为身份验证端点，请查看文档。
• global.registry.httpSecret.secret：包含 registry pod 之间共享 secret 的全局 secret。

可选

• profiling.stackdriver.credentials.secret：如果启用了 Stackdriver 分析并且您需要提供显式服务账户凭据，则此密钥中的值（默认情况下在 credentials 键中）是 GCP 服务账户 JSON 凭据。如果您使用 GKE 并使用 Workload Identity（或节点服务账户，尽管不推荐这样做），那么这个 secret 不是必需的，也不应该提供。 无论哪种情况，服务账户都需要角色 roles/cloudprofiler.agent 或等效的 手动权限

配置

我们将在下面描述配置的所有主要部分。从父 chart 配置时，这些值将是：

registry:
   enabled:
   maintenance:
      readonly:
         enabled: false
      uploadpurging:
         enabled: true
         age: 168h
         interval: 24h
         dryrun: false
   image:
      tag: 'v3.85.0-gitlab'
      pullPolicy: IfNotPresent
   annotations:
   service:
      type: ClusterIP
      name: registry
   httpSecret:
      secret:
      key:
   authEndpoint:
   tokenIssuer:
   certificate:
      secret: gitlab-registry
      key: registry-auth.crt
   deployment:
      terminationGracePeriodSeconds: 30
   draintimeout: '0'
   hpa:
      minReplicas: 2
      maxReplicas: 10
      cpu:
         targetAverageUtilization: 75
      behavior:
         scaleDown:
            stabilizationWindowSeconds: 300
   storage:
      secret:
      key: storage
      extraKey:
   validation:
      disabled: true
      manifests:
         referencelimit: 0
         payloadsizelimit: 0
         urls:
            allow: []
            deny: []
   notifications: {}
   tolerations: []
   ingress:
      enabled: false
      tls:
         enabled: true
         secretName: redis
      annotations:
      configureCertmanager:
      proxyReadTimeout:
      proxyBodySize:
      proxyBuffering:
   networkpolicy:
      enabled: false
      egress:
         enabled: false
         rules: []
      ingress:
         enabled: false
         rules: []
   tls:
      enabled: false
      secretName:
      verify: true
      caSecretName:

如果您选择将此 chart 作为独立部署，请删除顶层的 registry。

安装参数

Chart 配置示例

pullSecrets

pullSecrets 允许您对私有仓库进行身份验证，以拉取 pod 的镜像。

有关私有仓库及其身份验证方法的其它详细信息，请参见 Kubernetes 文档。

下面是一个使用 pullSecrets 的例子：

image:
  repository: my.registry.repository
  tag: latest
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

tolerations

tolerations 允许您调度 Pod 到受污染的工作节点上。

下面是一个使用 tolerations 的例子：

tolerations:
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoExecute"

annotations

annotations 允许您向 registry pod 添加 annotation。

下面是 annotations 的一个使用示例：

annotations:
  kubernetes.io/example-annotation: annotation-value

启用子 chart

我们选择实现划分子 chart 的方式包括禁用给定部署中您可能不需要的组件的能力。 因此，您应该决定的第一个设置是 enabled。

默认情况下，注册表是开箱即用的。 如果你想禁用它，设置 enabled: false。

配置 image

这部分控制子 chart 的 Deployment 使用的容器镜像的设置。 您可以更改 Registry 和pullPolicy 的包含版本。

默认设置：

• tag: 'v3.85.0-gitlab'
• pullPolicy: 'IfNotPresent'

配置 service

此部分控制 Service 的名称和类型。 这些设置将由 values.yaml 填充。

默认情况下，服务配置为：

配置 ingress

此部分控制 registry Ingress.

配置 TLS

Container Registry 支持 TLS 以保护其与其他组件的通信，包括 nginx-ingress。

配置 TLS 的先决条件：

• TLS 证书必须在 Common Name (CN) 或 Subject Alternate Name (SAN) 中包含 Registry Service 主机名（例如，RELEASE-registry.default.svc）。
• TLS 证书生成后：
  • 创建一个 Kubernetes TLS Secret
  • 创建另一个仅包含带有 ca.crt 密钥的 TLS 证书的 CA 证书的 Secret。

要启用 TLS：

1. 将 registry.tls.enabled 设置为 true。
2. 将 global.hosts.registry.protocol 设置为 https。
3. 将 Secret 名称传递给 registry.tls.secretName 和 global.certificates.customCAs。

当 registry.tls.verify 为 true 时，必须将 CA 证书 Secret 名称传递给 registry.tls.caSecretName。这是自签名证书和自定义证书颁发机构所必需的。NGINX 使用这个 Secret 来验证 Registry 的 TLS 证书。

例如：

global:
  certificates:
    customCAs:
    - secret: registry-tls-ca
  hosts:
    registry:
      protocol: https

registry:
  tls:
    enabled: true
    secretName: registry-tls
    verify: true
    caSecretName: registry-tls-ca

为调试端口配置 TLS

Registry 调试端口也支持 TLS。 调试端口用于 Kubernetes 的 liveness 和 readiness 检查，以及为 Prometheus（如果启用）公开一个 /metrics 端点。

可以通过将 registry.debug.tls.enabled 设置为 true 来启用 TLS。 可以在 registry.debug.tls.secretName 中提供一个 Kubernetes TLS Secret，专用于调试端口的 TLS 配置。如果未指定专用密钥，则调试配置将回退到与库的常规 TLS 配置共享 registry.tls.secretName。

Prometheus 使用 https 抓取 /metrics/ 端点 - 证书的 CommonName 参数或 SubjectAlternativeName 条目需要额外配置。 有关这些要求，请参阅 配置 Prometheus 以抓取启用 TLS 的端点。

配置 networkpolicy

此部分控制 registry NetworkPolicy。 该设置可选，用于限制 registry 的 egress and Ingress 到特定端点。

防止连接到所有内部端点的示例策略

Registry 服务通常需要到对象存储的 egress 连接、来自 Docker 客户端的 ingress 连接，以及用于 DNS 查找的 kube-dns。 这会向 Registry 服务添加以下网络限制：

• 允许在10.0.0.0/8 端口 53 上对本地网络的所有出口请求（对于 kubeDNS）
• 对10.0.0.0/8 上本地网络的其他出口请求受到限制
• 允许在10.0.0.0/8 之外的出口请求

请注意，Registry 服务需要到公共互联网的出站连接才能获取 外部对象存储 上的镜像

networkpolicy:
  enabled: true
  egress:
    enabled: true
    # The following rules enable traffic to all external
    # endpoints, except the local
    # network (except DNS requests)
    rules:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 53
          protocol: UDP
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
            - 10.0.0.0/8

配置 KEDA

keda 部分允许安装 KEDA ScaledObjects，而不是常规的 HorizontalPodAutoscalers。 此配置是可选的，可以在需要根据自定义或外部指标进行自动缩放时使用。

大多数设置默认为 hpa 部分中适用的值。

如果满足以下条件，则会根据 hpa 部分中设置的 CPU 和内存阈值自动添加 CPU 和内存触发器：

• 未设置 triggers。
• 相应的 request.cpu.request 或 request.memory.request 也设置为非零值。

如果未设置触发器，则不会创建 ScaledObject。

有关这些设置的更多详细信息，请参阅 KEDA 文档。

定义 Registry 配置

此 chart 的以下参数与底层 registry 容器的配置有关。仅公开与 GitLab 集成的最关键值。 对于这种集成，我们利用 Docker Distribution 的 auth.token.x 设置，通过 JWT 身份验证令牌。

httpSecret

字段 httpSecret 是一个包含 secret 和 key 的映射。

引用的密钥内容与 registry 的 http.secret 值相关。 这个值应该用加密生成的随机字符串填充。

如果未提供，shared-secrets 作业将自动创建此密钥。它将填充一个安全生成的 128 个字符（含字母和数字）字符串，该字符串是 base64 编码的。

要手动创建此密钥：

kubectl create secret generic gitlab-registry-httpsecret --from-literal=secret=strongrandomstring

Notification Secret

Notification Secret 用于以各种方式回调 GitLab 应用程序，例如 Geo 以帮助管理主站点和辅助站点之间的同步容器镜像库数据。

如果未提供，则在启用 shared-secrets 功能时，将自动创建 notificationSecretsecret 对象。

要手动创建此密钥：

kubectl create secret generic gitlab-registry-notification --from-literal=secret=[\"strongrandomstring\"]

然后继续设置

global:
  # To provide your own secret
  registry:
    notificationSecret:
        secret: gitlab-registry-notification
        key: secret

  # If utilising Geo, and wishing to sync the container registry
  geo:
    registry:
      replication:
        enabled: true
        primaryApiUrl: <URL to primary registry>

确保将 secret 值设置为上面创建的 secret 的名称。

Redis 缓存 Secret

当 global.redis.auth.enabled 设置为 true 时，使用 Redis 缓存 Secret。

启用 shared-secrets 功能时，如果未提供 gitlab-redis-secret secret 对象，则会自动创建。

要手动创建此密钥，请参阅 Redis 密码说明。

authEndpoint

authEndpoint 字段是一个字符串，提供 registry 将验证到的 GitLab 实例的 URL。

该值应仅包含协议和主机名。chart 模板将自动附加必要的请求路径。结果值将填入到容器内的 auth.token.realm。例如：authEndpoint: "https://gitlab.example.com"

默认情况下，此字段使用 GitLab 主机名配置填充全局设置。

certificate

certificate 字段是一个包含 secret 和 key 的映射。

secret 是一个字符串，包含 Kubernetes Secret 的名称，其中包含用于验证 GitLab 实例创建的令牌的证书包。

key 是 Secret 中包含提供给 registry 容器的证书包，作为 auth.token.rootcertbundle。

默认示例：

certificate:
  secret: gitlab-registry
  key: registry-auth.crt

readiness and liveness 探针

默认情况下，有一个 readiness and liveness 探针配置为检查调试端口 5001 上的 /debug/health。

validation

validation 字段是一个映射，用于控制 registry 中的 Docker 镜像验证过程。启用镜像验证后，registry 会拒绝带有外部层的 Windows 镜像, 除非 validation stanza 中的 manifests.urls.allow 字段明确设置为允许这些层 url。

验证仅在 manifest push 期间发生，因此已存在于镜像库中的镜像不受本部分中值更改的影响。

镜像验证默认关闭。

要启用镜像验证，您需要显式设置 registry.validation.disabled: false。

manifests

manifests 字段允许配置特定于清单的验证策略。

urls 部分包含 allow 和 deny 字段。对于包含要通过验证的 URL 的 manifest 层，该层必须匹配 allow 字段中的正则表达式之一，而不匹配 deny 字段中的任何正则表达式。

notifications

notifications 字段用于配置 Registry 通知。

它有一个空 hash 作为默认值。

设置示例如下：

notifications:
  endpoints:
    - name: FooListener
      url: https://foolistener.com/event
      timeout: 500ms
      threshold: 10
      backoff: 1s
    - name: BarListener
      url: https://barlistener.com/event
      timeout: 100ms
      threshold: 3
      backoff: 1s
  events:
    includereferences: true

hpa

hpa 字段是一个对象，控制 registry作为集合的一部分创建的实例数量。minReplicas 的默认值为 2，maxReplicas 的默认值为 10，并将 cpu.targetAverageUtilization 配置为 75%。

storage

storage:
  secret:
  key: config
  extraKey:

storage 字段引用 Kubernetes Secret 和关联的 key。这个 secret 的内容直接取自 Registry Configuration:storage。 有关更多详细信息，请参阅该文档。

AWS s3 和 Google GCS 驱动程序可以在 examples/objectstorage 中找到：

• registry.s3.yaml
• registry.gcs.yaml

对于 S3，请确保您给出正确的 registry 存储权限。有关存储配置的更多信息，请参阅管理文档中的容器镜像库存储驱动程序。

将 storage 块的 contents 放入 secret 中，并将以下事项提供给 storage 映射：

• secret：包含 YAML 块的 Kubernetes Secret 的名称。
• key：要使用的 secret 中的 key 名称。 默认为 config。
• extraKey: （可选） secret 中额外 key 的名称，将挂载到容器内的 /etc/docker/registry/storage/${extraKey}。这可用于为 gcs 驱动程序提供 keyfile。

# Example using S3
kubectl create secret generic registry-storage \
    --from-file=config=registry-storage.yaml

# Example using GCS with JSON key
# - Note: `registry.storage.extraKey=gcs.json`
kubectl create secret generic registry-storage \
    --from-file=config=registry-storage.yaml \
    --from-file=gcs.json=example-project-382839-gcs-bucket.json

您可以禁用存储驱动程序的重定向，确保所有流量都流经 Registry 服务，而不是重定向到另一个后端：

storage:
  secret: example-secret
  key: config
  redirect:
    disable: true

如果您选择使用 filesystem 驱动程序：

• 您将需要为此数据提供持久卷。
• hpa.minReplicas 应设置为 1
• hpa.maxReplicas 应设置为 1

为了弹性和简易性，建议使用外部服务，例如 s3、gcs、azure 或其它兼容的对象存储。

middleware.storage

middleware.storage 的配置遵循上游约定：

配置相当通用，并遵循类似的模式：

middleware:
  # See https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#middleware
  storage:
    - name: cloudfront
      options:
        baseurl: https://abcdefghijklmn.cloudfront.net/
        # `privatekey` is auto-populated with the content from the privatekey Secret.
        privatekeySecret:
          secret: cloudfront-secret-name
          # "key" value is going to be used to generate file name for PEM storage:
          #   /etc/docker/registry/middleware.storage/<index>/<key>
          key: private-key-ABC.pem
        keypairid: ABCEDFGHIJKLMNOPQRST

在上面的代码中 options.privatekeySecret 是一个 generic Kubernetes secret 内容，它对应于 PEM 文件内容：

kubectl create secret generic cloudfront-secret-name --type=kubernetes.io/ssh-auth --from-file=private-key-ABC.pem=pk-ABCEDFGHIJKLMNOPQRST.pem

上游使用的 privatekey 由来自 privatekey Secret 的 chart 自动填充，如果指定，将被忽略。

keypairid 变体

不同的供应商对相同的结构使用不同的字段名称：

debug

默认情况下启用 debug 端口并用于 liveness/readiness 探测。 此外，Prometheus 指标可以通过 metrics 值启用。

debug:
  addr:
    port: 5001

metrics:
  enabled: true

health

health 参数是可选的，包含对存储驱动程序的后端存储进行定期健康检查的首选项。 更多详细信息，请参阅 Docker 的配置文档。

health:
  storagedriver:
    enabled: false
    interval: 10s
    threshold: 3

reporting

reporting 参数是可选的，可以启用 reporting。

reporting:
  sentry:
    enabled: true
    dsn: 'https://<key>@sentry.io/<project>'
    environment: 'production'

profiling

profiling 参数是可选的，可以启用连续分析。

profiling:
  stackdriver:
    enabled: true
    credentials:
      secret: gitlab-registry-profiling-creds
      key: credentials
    service: gitlab-registry

database

database 参数是可选的，可以启用元数据数据库。

database:
  enabled: true
  host: registry.db.example.com
  port: 5432
  user: registry
  password:
    secret: gitlab-postgresql-password
    key: postgresql-registry-password
  dbname: registry
  sslmode: verify-full
  ssl:
    secret: gitlab-registry-postgresql-ssl
    clientKey: client-key.pem
    clientCertificate: client-cert.pem
    serverCA: server-ca.pem
  connecttimeout: 5s
  draintimeout: 2m
  preparedstatements: false
  pool:
    maxidle: 25
    maxopen: 25
    maxlifetime: 5m
  migrations:
    enabled: true
    activeDeadlineSeconds: 3600
    backoffLimit: 6
  discovery:
    enabled: true
    nameserver: 'nameserver.fqdn'
    port: 53
    primaryrecord: 'primary.record.fqdn.'
    tcp: false

创建数据库

如果启用了 Registry 数据库，Registry 将使用自己的数据库来跟踪其状态。

按照以下步骤手动创建数据库和角色。

1. 使用数据库密码创建 secret：

   kubectl create secret generic RELEASE_NAME-registry-database-password --from-literal=password=randomstring
   

2. 登录到您的数据库实例：

   kubectl exec -it $(kubectl get pods -l app.kubernetes.io/name=postgresql -o custom-columns=NAME:.metadata.name --no-headers) -- bash
   

   PGPASSWORD=${POSTGRES_POSTGRES_PASSWORD} psql -U postgres -d template1
   

3. 创建数据库用户：

   CREATE ROLE registry WITH LOGIN;
   

4. 设置数据库用户密码。

   1. 获取密码：

      kubectl get secret RELEASE_NAME-registry-database-password -o jsonpath="{.data.password}" | base64 --decode
      

   2. 在 psql 提示符中设置密码：

      \password registry
      

5. 创建数据库：

   CREATE DATABASE registry WITH OWNER registry;
   

6. 从 PostgreSQL 命令行安全退出，然后使用 exit 从容器中退出：

   template1=# exit
   ...@gitlab-postgresql-0/$ exit
   

gc 参数

gc 参数提供在线垃圾收集选项。

在线垃圾收集需要启用元数据数据库。使用数据库时必须使用在线垃圾收集，但您可以暂时禁用在线垃圾收集以进行维护和调试。

gc:
  disabled: false
  maxbackoff: 24h
  noidlebackoff: false
  transactiontimeout: 10s
  reviewafter: 24h
  manifests:
    disabled: false
    interval: 5s
  blobs:
    disabled: false
    interval: 5s
    storagetimeout: 5s

Redis 缓存

redis.cache 参数是可选的，并提供与 Redis 缓存相关的选项。 要将 redis.cache 与仓库一起使用，必须启用元数据数据库。

例如：

redis:
  cache:
    enabled: true
    host: localhost
    port: 16379
    password:
      secret: gitlab-redis-secret
      key: redis-password
    db: 0
    dialtimeout: 10ms
    readtimeout: 10ms
    writetimeout: 10ms
    tls:
      enabled: true
      insecure: true
    pool:
      size: 10
      maxlifetime: 1h
      idletimeout: 300s

Sentinels

redis.cache 可以使用 global.redis.sentinels 配置。可以提供局部值并将优先于全局值。例如：

redis:
  cache:
    enabled: true
    host: redis.example.com
    sentinels:
      - host: sentinel1.example.com
        port: 16379
      - host: sentinel2.example.com
        port: 16379

垃圾收集

Docker Registry 会随着时间的推移建立无关的数据，可以使用垃圾收集释放这些数据。

截至现在，没有使用 chart 完全自动化的运行垃圾收集的方式。

手动垃圾收集

手动垃圾收集首先要求 registry 处于只读模式。假设您已经使用 Helm 安装了 GitLab Chart，将其命名为 mygitlab，并安装在命名空间 gitlabns 中。

根据您的实际配置替换以下命令中的这些值。

# Because of https://github.com/helm/helm/issues/2948 we can't rely on --reuse-values, so let's get our current config.
helm get values mygitlab > mygitlab.yml
# Upgrade Helm installation and configure the registry to be read-only.
# The --wait parameter makes Helm wait until all ressources are in ready state, so we are safe to continue.
helm upgrade mygitlab gitlab/gitlab -f mygitlab.yml --set registry.maintenance.readonly.enabled=true --wait
# Our registry is in r/o mode now, so let's get the name of one of the registry Pods.
# Note down the Pod name and replace the '<registry-pod>' placeholder below with that value.
# Replace the single quotes to double quotes (' => ") if you are using this with Windows' cmd.exe.
kubectl get pods -n gitlabns -l app=registry -o jsonpath='{.items[0].metadata.name}'
# Run the actual garbage collection. Check the registry's manual if you really want the '-m' parameter.
kubectl exec -n gitlabns <registry-pod> -- /bin/registry garbage-collect -m /etc/docker/registry/config.yml
# Reset registry back to original state.
helm upgrade mygitlab gitlab/gitlab -f mygitlab.yml --wait
# All done :)

针对容器镜像库运行管理命令

管理命令只能从 Registry pod 中针对容器镜像库运行，其中 registry 二进制文件以及必要的 配置可用。

要运行管理命令：

1. 连接 Registry pod：

   kubectl exec -it <registry-pod> -- bash
   

2. 一旦进入 Registry pod，registry 二进制文件在 PATH 中可用并且可以直接使用。 配置文件位于/etc/docker/registry/config.yml。 以下示例检查数据库迁移的状态：

   registry database migrate status /etc/docker/registry/config.yml
   

有关更多详细信息和其他可用命令，请参阅相关文档：

• General Registry documentation