- 设计选择
- 配置
- 安装参数
- Chart 配置示例
- 启用子 chart
- 配置
image
- 配置
service
- 配置
ingress
- 配置 TLS
-
配置
networkpolicy
- 配置 KEDA
- 定义 Registry 配置
- 垃圾收集
使用容器镜像库
registry
子 chart 为在 Kubernetes 上的完整云原生 GitLab 部署提供了 Registry 组件。该子 chart 使用了上游中包含 Docker Distribution 的 registry 容器。该 chart 由 3 个主要部分组成:Service、Deployment 和 ConfigMap。
所有配置都根据官方 Registry 配置文档处理,使用提供变量给 Deployment
的 /etc/docker/registry/config.yml
,从 ConfigMap
填充的。 ConfigMap
覆盖上游默认值,但基于配置文件。
获取更多细节,参阅下述示例:
设计选择
选择 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
。
安装参数
参数 | 默认值 | 说明 | |
---|---|---|---|
annotations
| Pod 注释 | ||
podLabels
| 补充 Pod 标签。不会用于选择器 | ||
common.labels
| 应用于此 chart 创建的所有对象的补充标签 | ||
authAutoRedirect
| true
| 身份验证自动重定向(必须为 Windows 客户端才能工作) | |
authEndpoint
| global.hosts.gitlab.name
| 身份验证端点(仅主机和端口) | |
certificate.secret
| gitlab-registry
| JWT 证书 | |
debug.addr.port
| 5001
| Debug 端口 | |
debug.tls.enabled
| false
| 为调试端口启用 TLS。影响 liveness 和 readiness 探测,以及指标端点(如果启用) | |
debug.tls.secretName
| Kubernetes TLS Secret 的名称,其中包含调试端点的有效证书和密钥。如果未设置且 debug.tls.enabled=true - 调试 TLS 配置将默认为库的 TLS 证书
| ||
debug.prometheus.enabled
| false
|
已废弃 使用 metrics.enabled
| |
debug.prometheus.path
| ""
|
已废弃 使用 metrics.path
| |
metrics.enabled
| false
| 指标端点是否可用于抓取 | |
metrics.path
| /metrics
| 指标端点路径 | |
metrics.serviceMonitor.enabled
| false
| 是否创建 ServiceMonitor 使 Prometheus Operator 能够管理指标抓取,请注意启用此功能会删除 prometheus.io 抓取注释
| |
metrics.serviceMonitor.additionalLabels
| {}
| 要添加到 ServiceMonitor 的其它标签 | |
metrics.serviceMonitor.endpointConfig
| {}
| ServiceMonitor 的附加端点配置 | |
deployment.terminationGracePeriodSeconds
| 30
| Pod 需要优雅终止的可选持续时间(以秒为单位) | |
deployment.strategy
| {}
| 允许配置部署使用的更新策略 | |
draintimeout
| '0'
| 收到 SIGTERM 信号后等待 HTTP 连接耗尽的时间(例如 10s )
| |
relativeurls
| false
| 启用 registry 在位置 header 中返回相对 URL | |
enabled
| true
| 启用 registry 标志 | |
hpa.behavior
| {scaleDown: {stabilizationWindowSeconds: 300 }}
| 包含放大和缩小行为的规范(需要 autoscaling/v2beta2 或更高版本)
| |
hpa.customMetrics
| []
| 自定义指标包含用于计算所需副本数的规范(覆盖在 targetAverageUtilization 中配置的平均 CPU 利用率的默认使用值)
| |
hpa.cpu.targetType
| Utilization
| 设置自动缩放 CPU 目标类型,必须是 Utilization 或 AverageValue
| |
hpa.targetAverageValue
| 75
| 设置自动扩缩容目标值 | |
hpa.cpu.targetAverageUtilization
| 设置自动缩放 CPU 目标利用率 | ||
hpa.memory.targetType
| 设置自动缩放内存目标类型,必须是 Utilization 或 AverageValue
| ||
hpa.memory.targetAverageValue
| 设置自动缩放内存目标值 | ||
hpa.memory.targetAverageUtilization
| 设置自动缩放内存目标利用率 | ||
hpa.minReplicas
| 2
| 最小副本数 | |
hpa.maxReplicas
| 10
| 最大副本数 | |
httpSecret
| Https secret | ||
extraEnvFrom
| 要暴露的其它数据源的额外环境变量列表 | ||
image.pullPolicy
| 仓库中镜像的拉取策略 | ||
image.pullSecrets
| 用于镜像仓库的 secret | ||
image.repository
| registry
| Registry 镜像 | |
image.tag
| v3.85.0-gitlab
| 要使用的镜像版本 | |
init.image.repository
| initContainer 镜像 | ||
init.image.tag
| initContainer 镜像标签 | ||
init.containerSecurityContext
| initContainer 容器特定 securityContext | ||
keda.enabled
| false
| 使用 KEDA ScaledObjects 替代 HorizontalPodAutoscalers
| |
keda.pollingInterval
| 30
| 检查每个触发器的时间间隔 | |
keda.cooldownPeriod
| 300
| 最后一个触发器报告有效后,在将资源缩放回 0 之前等待的时间 | |
keda.minReplicaCount
| KEDA 将资源缩减到的最小副本数,默认为 hpa.minReplicas
| ||
keda.maxReplicaCount
| KEDA 将资源扩展到的最大副本数,默认为 hpa.maxReplicas
| ||
keda.fallback
| KEDA 后备配置,请参阅文档 | ||
keda.hpaName
| KEDA 将创建的 HPA 资源的名称,默认为 keda-hpa-{scaled-object-name}
| ||
keda.restoreToOriginalReplicaCount
| 指定删除 ScaledObject 后,目标资源是否应缩减至原始副本数
| ||
keda.behavior
| 放大和缩小行为的 spec,默认为 hpa.behavior
| ||
keda.triggers
| 用于激活目标资源扩展的触发器列表,默认为根据 hpa.cpu 和 hpa.memory 计算的触发器
| ||
log
| {level: info, fields: {service: registry}}
| 配置日志选项 | |
minio.bucket
| global.registry.bucket
| 使用的 Legacy 存储桶名称 | |
maintenance.readonly.enabled
| false
| 启用仓库的只读模式 | |
maintenance.uploadpurging.enabled
| true
| 启用上传清除 | |
maintenance.uploadpurging.age
| 168h
| 清除早于指定时间的上传 | |
maintenance.uploadpurging.interval
| 24h
| 执行上传清除的频率 | |
maintenance.uploadpurging.dryrun
| false
| 只清除上传的列表而不删除 | |
priorityClassName
| 指派给 pods 的 Priority class | ||
reporting.sentry.enabled
| false
| 启用 Sentry 报告 | |
reporting.sentry.dsn
| Sentry DSN (Data Source Name) | ||
reporting.sentry.environment
| Sentry 环境 | ||
profiling.stackdriver.enabled
| false
| 使用 Stackdriver 启用连续分析 | |
profiling.stackdriver.credentials.secret
| gitlab-registry-profiling-creds
| 包含凭据的 secret 名称 | |
profiling.stackdriver.credentials.key
| credentials
| 存储凭据的密钥 | |
profiling.stackdriver.service
|
RELEASE-registry (模板化服务名称)
| 用于记录下配置文件的 Stackdriver 服务的名称 | |
profiling.stackdriver.projectid
| 运行的 GCP 项目 | 将配置文件报告给的 GCP 项目 | |
database.enabled
| false
| 启用元数据数据库。 这是一项实验性功能,不得在生产环境中使用 | |
database.host
| global.psql.host
| 数据库服务器主机名 | |
database.port
| global.psql.port
| 数据库服务器端口 | |
database.user
| 数据库用户名 | ||
database.password.secret
| RELEASE-registry-database-password
| 包含数据库密码的 secret 名称 | |
database.password.key
| password
| 存储数据库密码的 secret key | |
database.name
| 数据库名称 | ||
database.sslmode
| SSL 模式。可以是 disable 、allow 、prefer 、require 、verify-ca 或 verify-full 之一
| ||
database.ssl.secret
| global.psql.ssl.secret
| 包含客户端证书、密钥和证书颁发机构的机密。 默认为主要的 PostgreSQL SSL 机密 | |
database.ssl.clientCertificate
| global.psql.ssl.clientCertificate
| 引用客户端证书的 secret 中的 key | |
database.ssl.clientKey
| global.psql.ssl.clientKey
| 引用客户端密钥的 secret 中的 key | |
database.ssl.serverCA
| global.psql.ssl.serverCA
| 引用证书颁发机构(CA)的 secret 中的 key | |
database.connecttimeout
| 0
| 等待连接的最长时间。0 或未指定表示无限期地等待 | |
database.draintimeout
| 0
| 在关闭时等待耗尽所有连接的最长时间。0 或未指定意味着无限期地等待 | |
database.preparedstatements
| false
| 启用预编译语句。默认情况下禁用以与 PgBouncer 兼容 | |
database.pool.maxidle
| 0
| 空闲连接池中的最大连接数。如果 maxopen 小于 maxidle ,那么 maxidle 就会减少以匹配 maxopen 限制。0 或未指定意味着没有空闲连接
| |
database.pool.maxopen
| 0
| 数据库的最大打开连接数。 如果 maxopen 小于maxidle ,那么 maxidle 就会减少以匹配 maxopen 限制。0 或未指定意味着无限制的打开连接
| |
database.pool.maxlifetime
| 0
| 连接可以重用的最长时间。 过期的连接可能会在重用之前延迟关闭。0 或未指定意味着无限重用 | |
database.migrations.enabled
| true
| 启用迁移作业以在 Chart 的初始部署和升级时自动运行迁移。请注意,也可以从任何正在运行的 Registry pod 中手动运行迁移 | |
database.migrations.activeDeadlineSeconds
| 3600
| 在迁移作业上设置 activeDeadlineSeconds | |
database.migrations.backoffLimit
| 6
| 在迁移作业上设置 backoffLimit | |
database.discovery.enabled
| false
| 为数据库启用服务发现。这是 Registry 元数据数据库的一项实验性功能。不要在生产环境中使用 | |
database.discovery.nameserver
| 为服务发现设置名称服务器 (DNS) 的服务器地址或 FQDN。当 database.discovery.enabled 设置为 true 时需要配置
| ||
database.discovery.port
| 53
| 设置名称服务器的端口。默认为 53
| |
database.discovery.primaryrecord
| 需要从 nameserver 获取的 SRV 资源记录。primaryrecord 将用于运行 database.migrations
| ||
database.discovery.tcp
| false
| 当需要 TCP 连接而不是 UDP 时设置为 true
| |
gc.disabled
| true
| 当设置为 true 时,在线 GC workers 被禁用
| |
gc.maxbackoff
| 24h
| 发生错误时,用于在 worker 运行之间休眠的最大指数补偿时间。 除非 gc.noidlebackoff 为 true ,否则也适用于没有任务要处理的情况。 请注意,这不是绝对最大值,因为始终会添加高达 33% 的随机抖动因子
| |
gc.noidlebackoff
| false
| 设置为 true 时,在没有要处理的任务时,禁用 worker 运行之间的指数补偿
| |
gc.transactiontimeout
| 10s
| 每个 worker 运行的工作事务超时。每个 worker 在开始时启动一个数据库事务。如果超过此超时,则取消 worker run 以避免停滞或长时间运行的事务 | |
gc.blobs.disabled
| false
| 当设置为“true”时,blob 的 GC 工作线程被禁用 | |
gc.blobs.interval
| 5s
| 每个 worker run 之间的初始睡眠间隔 | |
gc.blobs.storagetimeout
| 5s
| 存储操作的超时时间。用于限制在存储后端删除悬空 blob 的请求的持续时间 | |
gc.manifests.disabled
| false
| 当设置为 true 时,manifest 的 GC worker 被禁用
| |
gc.manifests.interval
| 5s
| 每个 worker run 之间的初始睡眠间隔 | |
gc.reviewafter
| 24h
| 垃圾收集器应拾取记录以供审查的最短时间。 -1 表示无需等待
| |
securityContext.fsGroup
| 1000
| 应该在其下启动 pod 的 Group ID | |
securityContext.runAsUser
| 1000
| Pod 应该在其下启动的 user ID | |
securityContext.fsGroupChangePolicy
| 更改卷的所有权和权限的策略(需要 Kubernetes 1.23) | ||
containerSecurityContext
| 覆盖用于启动容器的容器 securityContext | ||
containerSecurityContext.runAsUser
| 1000
| 允许覆盖启动容器的特定安全上下文 | |
serviceLabels
| {}
| 补充服务标签 | |
tokenService
| container_registry
| JWT 令牌服务 | |
tokenIssuer
| gitlab-issuer
| JWT 令牌发行者 | |
tolerations
| []
| Pod 分配的容忍标签 | |
middleware.storage
| 中间件存储配置层 | ||
redis.cache.enabled
| false
| 当设置为 true 时,启用 Redis 缓存。此功能取决于启用的元数据数据库。仓库元数据将缓存在配置的 Redis 实例上
| |
redis.cache.host
| <Redis URL>
| Redis 实例的主机名。如果为空,该值将为 global.redis.host:global.redis.port
| |
redis.cache.port
| 6379
| Redis 实例的端口 | |
redis.cache.sentinels
| []
| 列出带有主机和端口的 sentinels | |
redis.cache.mainname
| 主服务器名称。仅适用于 sentinels | ||
redis.cache.password.secret
| gitlab-redis-secret
| 包含 Redis 密码的 Secret 名称 | |
redis.cache.password.key
| redis-password
| 存储 Redis 密码的 Secret key | |
redis.cache.db
| 0
| 用于每个连接的数据库的名称 | |
redis.cache.dialtimeout
| 0s
| 连接 Redis 实例的超时时间。默认为无超时 | |
redis.cache.readtimeout
| 0s
| 从 Redis 实例读取的超时时间。默认为无超时 | |
redis.cache.writetimeout
| 0s
| 写入 Redis 实例的超时时间。默认为无超时 | |
redis.cache.tls.enabled
| false
| 设置为 true 以启用 TLS
| |
redis.cache.tls.insecure
| false
| 设置为 true 以在通过 TLS 连接时禁用服务器名称验证
| |
redis.cache.pool.size
| 10
| 最大 socket 连接数。默认为 10 个连接 | |
redis.cache.pool.maxlifetime
| 1h
| 客户端退出连接的连接时长。默认是不关闭时长过大的连接 | |
redis.cache.pool.idletimeout
| 300s
| 在关闭非活动连接之前等待多长时间 |
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
填充。
默认情况下,服务配置为:
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
name
| String | registry
| 配置 Service 的名称 |
type
| String | ClusterIP
| 配置 Service 的类型 |
externalPort
| Int | 5000
| Service 暴露的端口 |
internalPort
| Int | 5000
| Pod 用来接受来自 Service 的请求的端口 |
clusterIP
| String | null
| 允许根据需要配置自定义集群 IP |
loadBalancerIP
| String | null
| 允许根据需要配置自定义 LoadBalancer IP 地址 |
配置 ingress
此部分控制 registry Ingress.
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
apiVersion
| String | 在 apiVersion 字段中使用的值。
| |
annotations
| String | 此字段与 Kubernetes Ingress 的标准 annotations 完全匹配。
| |
configureCertmanager
| Boolean | 切换 Ingress 注释 cert-manager.io/issuer 和 acme.cert-manager.io/http01-edit-in-place 。有关更多信息,请参阅 GitLab Pages 的 TLS 要求。
| |
enabled
| Boolean | false
| 控制是否为支持它们的服务创建 Ingress 对象的设置。 当 false 时,使用 global.ingress.enabled 设置。
|
tls.enabled
| Boolean | true
| 当设置为 false 时,禁用 Registry 子 chart 的 TLS。主要用于无法在 ingress-level 使用 TLS 终止的情况,例如在 Ingress Controller 之前有 TLS 终止代理时。
|
tls.secretName
| String | Kubernetes TLS Secret 的名称,其中包含 registry URL 的有效证书和密钥。如果未设置,则使用 global.ingress.tls.secretName 。 默认为未设置。
|
配置 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:
- 将
registry.tls.enabled
设置为true
。 - 将
global.hosts.registry.protocol
设置为https
。 - 将 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 到特定端点。
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
enabled
| Boolean | false
| 此设置为 registry 启用 NetworkPolicy
|
ingress.enabled
| Boolean | false
| 当设置为 true 时,将激活 Ingress 网络策略。 除非指定规则,否则这将阻止所有 Ingress 连接。
|
ingress.rules
| Array | []
| Ingress 策略规则,详见 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 和下面的例子。 |
egress.enabled
| Boolean | false
| 当设置为 true 时,将激活 Egress 网络策略。 除非指定规则,否则这将阻止所有出口连接。
|
egress.rules
| Array | []
| 出口策略规则,详细信息参见 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 和下面的例子 |
防止连接到所有内部端点的示例策略
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 文档。
名称 | 类型 | 默认值 | 描述 |
---|---|---|---|
enabled
| Boolean | false
| 使用 KEDA ScaledObjects 替代 HorizontalPodAutoscalers
|
pollingInterval
| Integer | 30
| 检查每个触发器的时间间隔 |
cooldownPeriod
| Integer | 300
| 最后一个触发器报告有效后,在将资源缩放回 0 之前等待的时间 |
minReplicaCount
| Integer | KEDA 将资源缩减到的最小副本数,默认为 hpa.minReplicas
| |
maxReplicaCount
| Integer | KEDA 将资源扩展到的最大副本数,默认为 hpa.maxReplicas
| |
fallback
| Map | KEDA 后备配置,请参阅文档 | |
hpaName
| String | KEDA 将创建的 HPA 资源的名称,默认为 keda-hpa-{scaled-object-name}
| |
restoreToOriginalReplicaCount
| Boolean | 指定删除 ScaledObject 后,目标资源是否应缩减至原始副本数
| |
behavior
| Map | 放大和缩小行为的 spec,默认为 hpa.behavior
| |
triggers
| Array | 用于激活目标资源扩展的触发器列表,默认为根据 hpa.cpu 和 hpa.memory 计算的触发器
|
定义 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
功能时,将自动创建 notificationSecret
secret 对象。
要手动创建此密钥:
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
字段中的任何正则表达式。
名称 | 类型 | 默认值 | 描述 |
---|---|---|---|
referencelimit
| Int | 0
| 单个 manifest 可能具有的最大引用数,例如层、镜像配置和其他 manifests。当设置为 0 (默认)时,此验证被禁用。
|
payloadsizelimit
| Int | 0
| manifest 有效负载的最大数据大小(以字节为单位)。当设置为 0 (默认)时,此验证被禁用。
|
urls.allow
| Array | []
| 在 manifest 层中启用 URL 的正则表达式列表。如果留空(默认),带有任何 URL 的层都将被拒绝。 |
urls.deny
| Array | []
| 限制 manifest 层中的 URL 的正则表达式列表。当留空(默认)时,没有通过 urls.allow 列表的 URL 层将被拒绝。
|
notifications
notifications
字段用于配置 Registry 通知。
它有一个空 hash 作为默认值。
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
endpoints
| Array | []
| 列表中的每一项对应一个端点 |
events
| 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
中找到:
对于 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
或其它兼容的对象存储。
delete.enabled: true
填入到此配置中。这使预期行为与 MinIO 的默认使用以及 Linux 软件包保持一致。 任何用户提供的值都将取代此默认值。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
变体
不同的供应商对相同的结构使用不同的字段名称:
供应商 | 字段名称 |
---|---|
Google CDN | keyname
|
CloudFront | keypairid
|
middleware.storage
部分的配置。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 将使用自己的数据库来跟踪其状态。
按照以下步骤手动创建数据库和角色。
-
使用数据库密码创建 secret:
kubectl create secret generic RELEASE_NAME-registry-database-password --from-literal=password=randomstring
-
登录到您的数据库实例:
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
-
创建数据库用户:
CREATE ROLE registry WITH LOGIN;
-
设置数据库用户密码。
-
获取密码:
kubectl get secret RELEASE_NAME-registry-database-password -o jsonpath="{.data.password}" | base64 --decode
-
在
psql
提示符中设置密码:\password registry
-
-
创建数据库:
CREATE DATABASE registry WITH OWNER registry;
-
从 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
二进制文件以及必要的
配置可用。
要运行管理命令:
-
连接 Registry pod:
kubectl exec -it <registry-pod> -- bash
-
一旦进入 Registry pod,
registry
二进制文件在PATH
中可用并且可以直接使用。 配置文件位于/etc/docker/registry/config.yml
。 以下示例检查数据库迁移的状态:registry database migrate status /etc/docker/registry/config.yml
有关更多详细信息和其他可用命令,请参阅相关文档: