使用 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 120 指定如果用户未成功登录服务器将断开连接的时间
config.maxStartups.full 100 SSHd 拒绝概率会线性增加,当未认证连接数达到指定数量时,所有未认证连接尝试将被拒绝
config.maxStartups.rate 30 当未经身份验证的连接过多时,SSHd 将以指定的概率拒绝连接(可选)
config.maxStartups.start 10 如果当前未经身份验证的连接数超过指定数量,SSHd 将拒绝连接尝试(可选)
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   要暴露的附加环境变量列表
hpa.targetAverageValue 100m 设置自动扩缩容目标值
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 镜像标签
logging.format text 对于 JSON 结构的日志,设置为 json
logging.sshdLogLevel ERROR 底层 SSH 守护进程的日志级别
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
sshDaemon openssh 选择将运行哪个 SSH 守护进程,可能的值(opensshgitlab-sshd
tolerations [] 分配给 Pod 的容忍标签
workhorse.serviceName webservice Workhorse service 名称(默认情况下,Workhorse 是 webservice Pods / Service 的一部分)

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

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.livenessProbedeployment.readinessProbe 提供了一种机制来帮助控制某些场景下 Pod 的终止。

较大的仓库受益于调整 liveness 和 readiness 时间,以匹配其典型的长时间运行的连接。readiness 探测持续时间比 liveness 探测持续时间短,以最大限度地减少 clonepush 操作期间的潜在中断。增加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 当设置为 trueIngress 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:
      - to:
        - 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