使用 GitLab Shell chart
gitlab-shell
子 chart 提供了一个配置用于 Git SSH 访问极狐GitLab 的 SSH 服务器。
要求
此 chart 依赖于对 Workhorse 服务的访问,可以作为完成 GitLab chart 的一部分,或者作为从此 chart 部署到 Kubernetes 集群访问的外部服务。
设计选择
为了轻松支持 SSH 副本,并避免使用共享存储来存储 SSH 授权密钥,我们使用 SSH AuthorizedKeysCommand 针对 GitLab 授权密钥端点进行身份验证。 因此,我们不会保留或更新这些 pod 中的 AuthorizedKeys 文件。
配置
gitlab-shell
chart 配置为两部分:外部服务和 chart设置。通过 Ingress 暴露的端口配置global.shell.port
,默认为 22
。Service 的外部端口也由global.shell.port
控制。
安装命令行选项
参数 | 默认值 | 说明 |
---|---|---|
annotations
| Pod annotations | |
podLabels
| 补充 Pod 标签。 不会用于选择器。 | |
common.labels
| 应用于此 chart 创建的所有对象的补充标签。 | |
config.clientAliveInterval
| 0
| 在其他空闲连接上保持活动 ping 之间的间隔; 默认值 0 禁用此 ping |
config.loginGraceTime
| 60
| 指定如果用户未成功登录服务器将断开连接的时间 |
config.maxStartups.full
| 100
| SSHd 拒绝概率会线性增加,当未认证连接数达到指定数量时,所有未认证连接尝试将被拒绝 |
config.maxStartups.rate
| 30
| 当未经身份验证的连接过多时,SSHd 将以指定的概率拒绝连接(可选) |
config.maxStartups.start
| 10
| 如果当前未经身份验证的连接数超过指定数量,SSHd 将拒绝连接尝试(可选) |
config.proxyProtocol
| false
| 为 gitlab-sshd daemon 启用 PROXY 协议支持
|
config.proxyPolicy
| "use"
| 指定处理代理协议的策略。值必须是 use, require, ignore, reject 之一
|
config.proxyHeaderTimeout
| "500ms"
|
gitlab-sshd 的最大持续时间,将在放弃读取 PROXY 协议 header 之前等待。必须包含单位:ms 、s 或 m 。
|
config.ciphers
| [aes128-gcm@openssh.com, chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr]
| 指定允许的密码。 |
config.kexAlgorithms
| [curve25519-sha256, curve25519-sha256@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group14-sha256, diffie-hellman-group14-sha1]
| 指定可用的 KEX(密钥交换)算法。 |
config.macs
| [hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1]
| 指定可用的 MAC(消息验证码算法)。 |
config.gssapi.enabled
| false
| 为 gitlab-sshd daemon 启用 GSS-API 支持
|
config.gssapi.keytab.secret
| 保存 gssapi-with-mic 身份验证方法的密钥表的 Kubernetes secret 的名称 | |
config.gssapi.keytab.key
| keytab
| 在 Kubernetes secret 中保存密钥表的密钥 |
config.gssapi.krb5Config
| 极狐GitLab Shell 容器中的 /etc/krb5.conf 文件的内容
| |
config.gssapi.servicePrincipalName
|
gitlab-sshd daemon 使用的 Kerberos 服务名称
| |
deployment.livenessProbe.initialDelaySeconds
| 10 | 启动 liveness 探测前的延迟 |
deployment.livenessProbe.periodSeconds
| 10 | 多久执行一次 liveness 探测 |
deployment.livenessProbe.timeoutSeconds
| 3 | liveness 探测超时时长 |
deployment.livenessProbe.successThreshold
| 1 | liveness 探测失败后被视为成功的最小连续成功次数 |
deployment.livenessProbe.failureThreshold
| 3 | 探测成功后被视为失败的 liveness 探测的最小连续失败次数 |
deployment.readinessProbe.initialDelaySeconds
| 10 | 启动 readiness 探测前的延迟 |
deployment.readinessProbe.periodSeconds
| 5 | 多久执行一次 readiness 探测 |
deployment.readinessProbe.timeoutSeconds
| 3 | readiness 探测超时时长 |
deployment.readinessProbe.successThreshold
| 1 | readiness 探测失败后被视为成功的最小连续成功次数 |
deployment.readinessProbe.failureThreshold
| 2 | 探测成功后被视为失败的 readiness 探测的最小连续失败次数 |
deployment.strategy
| {}
| 允许配置 deployment 使用的更新策略 |
deployment.terminationGracePeriodSeconds
| 30 | Kubernetes 等待 pod 强制退出的秒数 |
enabled
| true
| 启用 Shell 标记 |
extraContainers
| 包含的额外容器列表 | |
extraInitContainers
| 包含的额外 init 容器列表 | |
extraVolumeMounts
| 要添加的附加挂载卷列表 | |
extraVolumes
| 要创建的附加卷列表 | |
extraEnv
| 要暴露的附加环境变量列表 | |
extraEnvFrom
| 要暴露的附加环境变量列表 | |
hpa.behavior
| {scaleDown: {stabilizationWindowSeconds: 300 }}
| 包含放大和缩小行为的规范(需要 autoscaling/v2beta2 或更高版本)
|
hpa.customMetrics
| []
| 自定义指标包含用于计算所需副本数的规范(覆盖在 targetAverageUtilization 中配置的平均 CPU 利用率的默认使用值)
|
hpa.cpu.targetType
| AverageValue
| 设置自动缩放 CPU 目标类型,必须是 Utilization 或 AverageValue
|
hpa.targetAverageValue
| 100m
| 设置自动扩缩容目标值 |
hpa.cpu.targetAverageUtilization
| 设置自动缩放 CPU 目标利用率 | |
hpa.memory.targetType
| 设置自动缩放内存目标类型,必须是 Utilization 或 AverageValue
| |
hpa.memory.targetAverageValue
| 设置自动缩放内存目标值 | |
hpa.memory.targetAverageUtilization
| 设置自动缩放内存目标利用率 | |
hpa.minReplicas
| 最小副本数 | |
hpa.maxReplicas
| 最大副本数 | |
hpa.targetAverageValue
| 已弃用 设置自动缩放 CPU 目标值 | |
image.pullPolicy
| IfNotPresent
| Shell 镜像拉取策略 |
image.pullSecrets
| 用于镜像仓库的 Secrets | |
image.repository
| registry.com/gitlab-org/build/cng/gitlab-shell
| Shell 镜像仓库 |
image.tag
| master
| Shell 镜像标签 |
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 计算的触发器
| |
logging.format
| json
| 对于非结构化日志,设置为 text
|
logging.sshdLogLevel
| ERROR
| 底层 SSH 守护进程的日志级别 |
priorityClassName
| 指派给 Pod 的 Priority class。 | |
replicaCount
| 1
| Shell 副本数 |
serviceLabels
| {}
| 补充的 service 标签 |
service.externalTrafficPolicy
| Cluster
| Shell service 外部流量策略(集群或本地) |
service.internalPort
| 2222
| Shell 内部端口 |
service.nodePort
| Shell nodePort | |
service.name
| gitlab-shell
| Shell service 名称 |
service.type
| ClusterIP
| Shell service 类型 |
service.loadBalancerIP
| 分配给 LoadBalancer 的 IP 地址(如果支持) | |
service.loadBalancerSourceRanges
| 允许访问 LoadBalancer 的 IP CIDR 列表(如果支持) | |
securityContext.fsGroup
| 1000
| 在其下启动 Pod 的 Group ID |
securityContext.runAsUser
| 1000
| 在其下启动 Pod 的 User ID |
securityContext.fsGroupChangePolicy
| 更改卷的所有权和权限的策略(需要 Kubernetes 1.23) | |
containerSecurityContext
| 覆盖启动容器的容器 securityContext | |
containerSecurityContext.runAsUser
| 1000
| 允许覆盖启动容器的特定 securityContext |
sshDaemon
| openssh
| 选择将运行哪个 SSH 守护进程,可能的值(openssh 、gitlab-sshd )
|
tolerations
| []
| 分配给 Pod 的容忍标签 |
workhorse.serviceName
| webservice
| Workhorse service 名称(默认情况下,Workhorse 是 webservice Pods / Service 的一部分) |
metrics.enabled
| true
| 指标端点是否可用于抓取(需要 sshDaemon=gitlab-sshd )
|
metrics.port
| 9122
| 指标端点端口 |
metrics.path
| /metrics
| 指标端点路径 |
metrics.serviceMonitor.enabled
| false
| 是否创建 ServiceMonitor 使 Prometheus Operator 能够管理指标抓取,请注意启用此功能会删除 prometheus.io 抓取注释
|
metrics.serviceMonitor.additionalLabels
| {}
| 要添加到 ServiceMonitor 的其它标签 |
metrics.serviceMonitor.endpointConfig
| {}
| ServiceMonitor 的附加端点配置 |
metrics.annotations
| 已废弃 设置明确的指标注释。替换为模板内容。 |
Chart 配置示例
extraEnv
extraEnv
允许您在 Pod 的所有容器中暴露额外的环境变量。
extraEnv
示例如下:
extraEnv:
SOME_KEY: some_value
SOME_OTHER_KEY: some_other_value
当容器启动时,您可以确认环境变量是否暴露:
env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value
extraEnvFrom
extraEnvFrom
允许您从 pod 中的所有容器中的其它数据源,暴露其它环境变量。
下面是一个使用 extraEnvFrom
的示例:
extraEnvFrom:
MY_NODE_NAME:
fieldRef:
fieldPath: spec.nodeName
MY_CPU_REQUEST:
resourceFieldRef:
containerName: test-container
resource: requests.cpu
SECRET_THING:
secretKeyRef:
name: special-secret
key: special_token
# optional: boolean
CONFIG_STRING:
configMapKeyRef:
name: useful-config
key: some-string
# optional: boolean
image.pullSecrets
pullSecrets
允许您对私有仓库进行身份验证,以拉取 pod 的镜像。
有关私有仓库及其身份验证方法的其它详细信息,请参见 Kubernetes 文档。
下面是一个使用 pullSecrets
的例子:
image:
repository: my.shell.repository
tag: latest
pullPolicy: Always
pullSecrets:
- name: my-secret-name
- name: my-secondary-secret-name
livenessProbe/readinessProbe
deployment.livenessProbe
和 deployment.readinessProbe
提供了一种机制来帮助控制某些场景下 Pod 的终止。
较大的仓库受益于调整 liveness 和 readiness 时间,以匹配其典型的长时间运行的连接。readiness 探测持续时间比 liveness 探测持续时间短,以最大限度地减少 clone
和 push
操作期间的潜在中断。增加terminationGracePeriodSeconds
,并在调度程序终止 pod 之前为这些操作提供更多时间。考虑将以下示例作为调整 GitLab Shell pod 的起点,以提高更大的仓库的工作负载稳定性和效率。
deployment:
livenessProbe:
initialDelaySeconds: 10
periodSeconds: 20
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 10
readinessProbe:
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
successThreshold: 1
failureThreshold: 3
terminationGracePeriodSeconds: 300
有关此配置的其它详细信息,请参考官方 Kubernetes 文档。
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
外部服务
Workhorse service 附在此 chart 中。
Workhorse
workhorse:
host: workhorse.example.com
serviceName: webservice
port: 8181
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
host
| String | Workhorse 服务器的主机名。可以省略,使用 serviceName 进行代替。
| |
port
| Integer | 8181
| 连接 Workhorse 服务器的端口 |
serviceName
| String | webservice
| 运行 Workhorse 数据库的 service 名称。如果该配置存在,且 host 的值不存在 , 则 chart 将服务的主机名替换 host 的值。这样使用 Workhorse 作为整个 chart 一部分时很方便。
|
Chart 设置
以下值用于配置 GitLab Shell Pod。
hostKeys.secret
用于获取 SSH 主机密钥的 Kubernetes secret
的名称。 Secret 中的 keys 必须以密钥名称 ssh_host_
开头,以便 GitLab Shell 使用。
authToken
GitLab Shell 使用身份验证令牌与 Workhorse 进行通信。 GitLab Shell 和 Workhorse 使用共享 Secret 从而共享令牌。
authToken:
secret: gitlab-shell-secret
key: secret
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
authToken.key
| String | secret 中 包含认证令牌的 key 。 | |
authToken.secret
| String | 拉取的 Kubernetes Secret 的名称。
|
LoadBalancer Service
如果service.type
设置为LoadBalancer
,您可以选择指定 service.loadBalancerIP
,以创建具有用户指定 IP 的LoadBalancer
(如果您的云提供商支持)。
您还可以选择指定 service.loadBalancerSourceRanges
列表,来限制可以访问 LoadBalancer
的 CIDR 范围(如果您的云提供商支持)。
有关 LoadBalancer
Service 类型的其它信息可以查看 Kubernetes 文档
service:
type: LoadBalancer
loadBalancerIP: 1.2.3.4
loadBalancerSourceRanges:
- 5.6.7.8/32
- 10.0.0.0/8
配置 networkpolicy
此部分控制 NetworkPolicy。此配置是可选的,用于将 Pod 的 Egress 和 Ingress 限制为特定端点。
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
enabled
| Boolean | false
| 该设置启用 NetworkPolicy
|
ingress.enabled
| Boolean | false
| 当设置为 true ,Ingress network policy 将被激活。除非指定规则,否则这将阻止所有 Ingress 连接。
|
ingress.rules
| Array | []
| Ingress 策略规则,详见 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 和下面的例子 |
egress.enabled
| Boolean | false
| 当设置为 true 时,将激活 Egress 网络策略。 除非指定规则,否则这将阻止所有 egress 连接。
|
egress.rules
| Array | []
| egress 策略规则,这些详细信息参见 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 和下面的例子。 |
网络策略示例
gitlab-shell
服务需要端口 22 的 Ingress 连接和到各种默认 workhorse 端口 8181 的 Egress 连接。此示例添加以下网络策略:
- 允许来自 TCP
0.0.0.0/0
端口 2222 上的网络的所有 Ingress 请求 - DNS 允许在 UDP
10.0.0.0/8
端口 53 上对网络的所有 Egress 请求 - Workhorse 允许在 TCP
10.0.0.0/8
端口 8181 上对网络的所有 Egress 请求 - Gitaly 允许在 TCP
10.0.0.0/8
端口 8075 上对网络的所有 Egress 请求
请注意,提供的示例仅为示例,可能并不完整
networkpolicy:
enabled: true
ingress:
enabled: true
rules:
- from:
- ipBlock:
cidr: 0.0.0.0/0
ports:
- port: 2222
protocol: TCP
egress:
enabled: true
rules:
- to:
- ipBlock:
cidr: 10.0.0.0/8
ports:
- port: 8181
protocol: TCP
- port: 8075
protocol: TCP
- port: 53
protocol: UDP