GitLab Shellチャートの使用

gitlab-shell GitLab Shell Helmチャートは、GitLabへのGitアクセス用に設定されたサーバーを提供します。

要件

このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされているKubernetesクラスタから到達可能な外部サービスとして提供されるWorkhorseサービスへのアクセスに依存します。

設計上の選択

SSHレプリカを容易にサポートし、SSH認証キーの共有ストレージの使用を避けるために、GitLab認証キーエンドポイントに対して認証するために、SSH AuthorizedKeysCommandを使用しています。その結果、これらのポッド内のAuthorizedKeysファイルを永続化または更新しません。

設定

gitlab-shellチャートは、外部サービスとチャートの設定の2つの部分で構成されています。Ingressを介して公開されるポートは、global.shell.portで構成され、22がデフォルトです。Serviceの外部ポートもglobal.shell.portによって制御されます。

インストールコマンドラインオプション

チャート設定

extraEnv

extraEnvを使用すると、ポッド内のすべてのコンテナに追加の環境変数を公開できます。

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を使用すると、内のすべてので、他のデータソースからの追加のを公開できます。

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を使用すると、プライベートレジストリに対して認証して、ポッドのイメージをプルできます。

プライベートレジストリとその認証方法の詳細については、Kubernetesドキュメントを参照してください。

pullSecretsの使用例を以下に示します:

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

serviceAccount

このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。

livenessProbe/readinessProbe

deployment.livenessProbeとdeployment.readinessProbeは、一部のシナリオでポッドの終了を制御するのに役立つメカニズムを提供します。

大規模なリポジトリは、通常実行時間の長い接続に一致するように、livenessプローブとreadinessプローブの時間を調整するとメリットがあります。cloneおよびpush操作中の潜在的な中断を最小限に抑えるために、readinessプローブの期間をlivenessプローブの期間よりも短く設定します。terminationGracePeriodSecondsを増やし、スケジューラがポッドを終了する前に、これらの操作により多くの時間を与えます。より大きなリポジトリのワークロードで安定性と効率性を高めるために、GitLab Shellポッドを調整するための開始ポイントとして、以下の例を検討してください。

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を使用すると、taintされたワーカーノードでポッドをスケジュールできます

tolerationsの使用例を以下に示します:

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

affinity

詳細については、affinityを参照してください。

annotations

annotationsを使用すると、注釈をGitLab Shellポッドに追加できます。

annotationsの使用例を以下に示します。

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

外部サービス

このチャートは、Workhorseサービスに接続する必要があります。

Workhorse

workhorse:
  host: workhorse.example.com
  serviceName: webservice
  port: 8181

チャートの設定

次の値は、GitLab Shellポッドを構成するために使用されます。

hostKeys.secret

SSHホストキーを取得するKubernetes secretの名前。シークレット内のキーは、GitLab Shellで使用するために、キー名ssh_host_で始まる必要があります。

authToken

GitLab Shellは、Workhorseとの通信で認証トークンを使用します。共有シークレットを使用して、GitLab ShellおよびWorkhorseとトークンを共有します。

authToken:
 secret: gitlab-shell-secret
 key: secret

ロードバランサーサービス

service.typeがLoadBalancerに設定されている場合は、オプションでservice.loadBalancerIPを指定して、ユーザー指定のIPでLoadBalancerを作成できます（クラウドクラウドプロバイダーがサポートしている場合）。

（クラウドプロバイダーがサポートしている場合）、LoadBalancerにアクセスできるCIDR範囲を制限するために、オプションでservice.loadBalancerSourceRangesのリストを指定することもできます。

LoadBalancerサービスタイプの詳細については、Kubernetesドキュメントを参照してください。

service:
  type: LoadBalancer
  loadBalancerIP: 1.2.3.4
  loadBalancerSourceRanges:
  - 5.6.7.8/32
  - 10.0.0.0/8

OpenSSHの追加設定

OpenSSHのsshd（.sshDaemon: openssh経由）を使用する場合、追加の設定を行う方法は2つあります。.opensshd.supplemental_config、および/etc/ssh/sshd_config.d/*.confへのスニペットのマップ。

提供される設定は、必ずsshd_configの機能要件を満たしている必要があります。マニュアルページを必ずお読みください。

opensshd.supplemental_config

.opensshd.supplemental_configの内容は、コンテナ内のsshd_configファイルの末尾に直接配置されます。この値は、複数行の文字列である必要があります。

例: ssh-rsaキー交換アルゴリズムを使用して、古いクライアントを有効にする。ssh-rsaなどの非推奨アルゴリズムを有効にすると、重大なセキュリティ脆弱性が発生することに注意してください。これらの変更により、公開されているGitLabインスタンスでの悪用の可能性が大幅に拡大します。

opensshd:
    supplemental_config: |-
      HostKeyAlgorithms +ssh-rsa,ssh-rsa-cert-v01@openssh.com
      PubkeyAcceptedAlgorithms +ssh-rsa,ssh-rsa-cert-v01@openssh.com
      CASignatureAlgorithms +ssh-rsa

sshd_config.d

sshdに完全な設定スニペットを提供するには、/etc/ssh/sshd_config.dにコンテンツをマウントし、ファイルが*.confと一致するようにします。これらは、_後_デフォルトの設定に含まれており、アプリケーションがコンテナおよびチャート内で機能するために必要であることに注意してください。これらの値は、しません sshd_configの内容をオーバーライドするのではなく、それらを拡張します。

例: extraVolumesおよびextraVolumeMountsを介して、ConfigMapの単一のアイテムをコンテナにマウントする:

extraVolumes: |
  - name: gitlab-sshdconfig-extra
    configMap:
      name: gitlab-sshdconfig-extra

extraVolumeMounts: |
  - name: gitlab-sshdconfig-extra
    mountPath: /etc/ssh/sshd_config.d/extra.conf
    subPath: extra.conf

networkpolicyの設定

このセクションでは、NetworkPolicyを制御します。この設定はオプションであり、特定のエンドポイントへのポッドのエグレスとIngressを制限するために使用されます。

ネットワークポリシー

gitlab-shellサービスには、ポート22のIngress接続と、デフォルトのworkhorseポート8181へのさまざまなエグレス接続が必要です。この例では、次のネットワークポリシーを追加します:

• Ingressリクエストを許可します:

  • nginx-ingressポッドからポート2222へ

  • prometheusポッドからポート9122へ

    prometheusからポート9122へのアクセスは、SSHデーモンがgitlab-sshdに設定されている場合にのみ必要です

• エグレスリクエストを許可します:

  • webserviceポッドからポート8181へ
  • gitalyポッドからポート8075へ

提供されている例は単なる例であり、完全ではない可能性があることに注意してください

この例は、kube-dnsがネームスペースkube-systemにデプロイされ、prometheusがネームスペースmonitoringにデプロイされ、nginx-ingressがネームスペースnginx-ingressにデプロイされたという前提に基づいています。

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: nginx-ingress
            podSelector:
              matchLabels:
                app: nginx-ingress
                component: controller
        ports:
          - port: 2222
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: monitoring
            podSelector:
              matchLabels:
                app: prometheus
                component: server
                release: gitlab
        ports:
          - port: 9122
  egress:
    enabled: true
    rules:
      - to:
          - podSelector:
              matchLabels:
                app: gitaly
        ports:
          - port: 8075
      - to:
          - podSelector:
              matchLabels:
                app: webservice
        ports:
          - port: 8181
      - to:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: kube-system
            podSelector:
              matchLabels:
                k8s-app: kube-dns
        ports:
          - port: 53
            protocol: UDP

KEDAの設定

このkedaセクションでは、通常のHorizontalPodAutoscalersの代わりにKEDA ScaledObjectsのインストールを有効にします。この設定はオプションであり、カスタムメトリクスまたは外部メトリクスに基づいてオートスケールが必要な場合に使用できます。

ほとんどの設定は、該当する場合、hpaセクションで設定された値にデフォルト設定されます。

次が当てはまる場合、hpaセクションで設定されたCPUとメモリのしきい値に基づいて、CPUとメモリのトリガーが自動的に追加されます:

• triggersが設定されていません。
• 対応するrequest.cpu.requestまたはrequest.memory.request設定も、ゼロ以外の値に設定されています。

トリガーが設定されていない場合、ScaledObjectは作成されません。

これらの設定の詳細については、KEDAドキュメントを参照してください。

kedaの使用例については、examples/keda/gitlab-shell.ymlを参照してください。