• 要件
• 設計の選択
• 設定
• インストールのコマンドラインオプション
• Chart設定例
  • extraEnv
  • 追加EnvFrom
  • 画像.pullSecrets
  • livenessProbe/readinessProbe
  • 許容範囲
  • 注釈
• 外部サービス
  • ワークホース
• チャート設定
  • hostKeys.secret
  • authToken
  • ロードバランサーサービス
  • 設定networkpolicy
  • ネットワークポリシーの例
• KEDAの設定

GitLab Shell チャートの使い方

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

要件

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

設計の選択

SSH レプリカを簡単にサポートし、SSH 認証キーの共有ストレージを使わないようにするために、GitLab 認証キーのエンドポイントに対して認証するために SSHAuthorizedKeysCommandを使っています。その結果、これらのポッド内で AuthorizedKeys ファイルを永続化したり更新したりすることはありません。

設定

gitlab-shell Chart は、内部サービスとChart 設定の2つの部分で設定されます。Ingressを通して公開されるポートはglobal.shell.portで設定され、デフォルトは22です。 サービスの外部ポートもglobal.shell.portで制御されます。

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

Chart設定例

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

追加EnvFrom

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

画像.pullSecrets

pullSecrets を使用すると、非公開レジストリで認証してポッドのイメージをプルできるようになります。

非公開レジストリとその認証方法の詳細については、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 は、いくつかのシナリオでポッドの終了を制御するのに役立つメカニズムを提供します。

大規模なリポジトリでは、典型的な長時間の接続に合わせて、Liveness ProbeとReadiness Probeの時間を調整すると効果的です。clone 、push のオペレーション中に発生する可能性のある中断を最小限に抑えるために、準備完了プローブの期間を有効性プローブの期間よりも短く設定します。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 の使用例です：

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

注釈

annotations では GitLab Shell のポッドにアノテーションを追加することができます。

以下はannotations

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

外部サービス

このChartはWorkhorseサービスに添付してください。

ワークホース

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

チャート設定

GitLab Shellポッドの設定には以下の値を使用します。

hostKeys.secret

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

authToken

GitLab ShellはWorkhorseとの通信でAuth Tokenを使用します。GitLab ShellとWorkhorseは共有シークレットを使ってトークンを共有します。

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

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

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

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

LoadBalancer サービスタイプに関する追加情報は、Kubernetes ドキュメントに記載されています。

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

設定networkpolicy

このセクションではNetworkPolicyを制御します。この設定はオプションで、ポッドの Egress および Ingress を特定のエンドポイントに制限するために使用します。

ネットワークポリシーの例

gitlab-shell サービスは、ポート 22 の Ingress 接続と、デフォルトの Workhorse ポート 8181 への Egress 接続を必要とします。この例では、次のネットワークポリシーを追加します：

• TCP0.0.0.0/0 ポート 2222 のネットワークからのすべての Ingress 要求が許可されます。
• DNS については、UDP10.0.0.0/8 ポート 53 のネットワークへのすべての Egress リクエストが許可されます。
• TCP10.0.0.0/8 ポート 8181 のネットワークへのすべての Egress リクエストは Workhorse に許可されています。
• Gitaly では、TCP10.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

KEDAの設定

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

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

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

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

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

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

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