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
で制御されます。
インストールのコマンドラインオプション
パラメータ | デフォルト | 説明 |
---|---|---|
annotations | ポッド注釈 | |
podLabels | ポッドラベルの補足。セレクタには使用されません。 | |
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 デーモンの PROXY プロトコルサポートを有効にします。 |
config.proxyPolicy | "use" | PROXYプロトコルの処理ポリシーを指定します。値は以下のいずれかでなければなりません。use, require, ignore, reject
|
config.proxyHeaderTimeout | "500ms" |
gitlab-sshd が PROXY プロトコルヘッダの読み込みをあきらめるまでの最大時間。単位を含める必要があります: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 デーモンの GSS-API サポートを有効にします。 |
config.gssapi.keytab.secret | gssapi-with-mic認証メソッドのkeytabを保持するKubernetesシークレットの名前。 | |
config.gssapi.keytab.key | keytab | Kubernetesシークレット内のkeytabを保持するキー |
config.gssapi.krb5Config | GitLab Shellコンテナ内の/etc/krb5.conf ファイルのコンテナ。 | |
config.gssapi.servicePrincipalName |
gitlab-sshd デーモンが使用する Kerberos サービス名。 | |
deployment.livenessProbe.initialDelaySeconds | 10 | Liveness Probeが開始されるまでの遅延時間 |
deployment.livenessProbe.periodSeconds | 10 | Livenessプローブの実行頻度 |
deployment.livenessProbe.timeoutSeconds | 3 | Livenessプローブがタイムアウトした場合 |
deployment.livenessProbe.successThreshold | 1 | 一度失敗したプローブが成功したとみなされるための最小連続成功回数 |
deployment.livenessProbe.failureThreshold | 3 | 成功した後に失敗したとみなされるための連続した失敗の最小値 |
deployment.readinessProbe.initialDelaySeconds | 10 | Readiness Probeが開始されるまでの遅延。 |
deployment.readinessProbe.periodSeconds | 5 | Readinessプローブの実行頻度 |
deployment.readinessProbe.timeoutSeconds | 3 | 準備完了プローブがタイムアウトした場合 |
deployment.readinessProbe.successThreshold | 1 | Readinessプローブが失敗した後、成功したとみなされるための最小連続成功回数 |
deployment.readinessProbe.failureThreshold | 2 | 成功した後、レディネス・プローブが失敗したとみなされるには、最低連続失敗回数が必要です。 |
deployment.strategy | {} | デプロイによって使用されるアップデート戦略を設定できます。 |
deployment.terminationGracePeriodSeconds | 30 | Kubernetesがポッドの強制終了を待機する秒数 |
enabled | true | シェル有効フラグ |
extraContainers | 追加コンテナのリスト | |
extraInitContainers | 追加コンテナのリスト | |
extraVolumeMounts | 追加ボリュームマウントのリスト | |
extraVolumes | 作成する追加ボリュームのリスト | |
extraEnv | 公開する追加環境変数のリスト | |
extraEnvFrom | 公開する他のデータソースの追加環境変数のリスト | |
hpa.behavior | {scaleDown: {stabilizationWindowSeconds: 300 }} | ビヘイビアには、アップスケーリングとダウンスケーリングのビヘイビアの仕様が含まれます(autoscaling/v2beta2 以上が必要です)。 |
hpa.customMetrics | [] | カスタム・メトリクスには、希望するレプリカ数を計算するために使用するメトリクスの設定が含まれます(targetAverageUtilization で設定された平均CPU使用率をデフォルトで上書きします)。 |
hpa.cpu.targetType | AverageValue | オートスケーリングCPUターゲット・タイプを設定します。Utilization またはAverageValue
|
hpa.cpu.targetAverageValue | 100m | オートスケーリングCPUターゲット値の設定 |
hpa.cpu.targetAverageUtilization | オートスケーリングCPUターゲット使用率の設定 | |
hpa.memory.targetType |
Utilization 、またはAverageValue
| |
hpa.memory.targetAverageValue | オートスケーリング・メモリ・ターゲットの値を設定します。 | |
hpa.memory.targetAverageUtilization | オートスケーリングメモリ使用率の設定 | |
hpa.targetAverageValue | 自動スケーリングCPU目標値の設定 | |
image.pullPolicy | IfNotPresent | シェルイメージプルポリシー |
image.pullSecrets | 画像リポジトリのシークレット | |
image.repository | registry.com/gitlab-org/build/cng/gitlab-shell | シェルイメージリポジトリ |
image.tag | master | シェル画像タグ |
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がリソースをスケールダウンする最小レプリカ数。minReplicas
| |
keda.maxReplicaCount | KEDAがリソースをスケールアップする際の最大レプリカ数。maxReplicas
| |
keda.fallback | KEDAフォールバック設定。 | |
keda.hpaName | KEDAが作成するHPAリソースの名前。keda-hpa-{scaled-object-name}
| |
keda.restoreToOriginalReplicaCount |
ScaledObject が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します。 | |
keda.behavior | アップスケーリングとダウンスケーリングの動作を指定します。hpa.behavior
| |
keda.triggers | 対象リソースのスケーリングを有効にするトリガーのリスト。デフォルトはhpa.cpu とhpa.memory
| |
logging.format | json | 構造化されていないログの場合はtext 。 |
logging.sshdLogLevel | ERROR | SSHデーモンのログレベル |
priorityClassName | ポッドに割り当てられる優先度クラス。 | |
replicaCount | 1 | シェルレプリカ |
serviceLabels | {} | 補足サービスラベル |
service.externalTrafficPolicy | Cluster | Shellサービスの外部トラフィックポリシー(クラスターまたはローカル) |
service.internalPort | 2222 | シェル内部ポート |
service.nodePort | 設定されている場合、シェルnodePortを設定します。 | |
service.name | gitlab-shell | シェルサービス名 |
service.type | ClusterIP | シェルサービスタイプ |
service.loadBalancerIP | ロードバランサーに割り当てる IP アドレス (サポートされている場合) | |
service.loadBalancerSourceRanges | LoadBalancer へのアクセスを許可する IP CIDR のリスト (サポートされている場合) | |
securityContext.fsGroup | 1000 | ポッドを起動するグループID |
securityContext.runAsUser | 1000 | ポッドを起動するユーザーID |
securityContext.fsGroupChangePolicy | ボリュームの所有権と権限を変更するためのポリシー (Kubernetes 1.23 が必要) | |
containerSecurityContext | コンテナが起動するコンテナsecurityContext をオーバーライドします。 | |
containerSecurityContext.runAsUser | 1000 | コンテナが起動される特定のセキュリティコンテキストを上書きできるようにします。 |
sshDaemon | openssh | どのSSHデーモンを実行するかを選択。可能な値 (openssh ,gitlab-sshd ) |
tolerations | [] | ポッド割り当て用のトレラベル |
workhorse.serviceName | webservice | Workhorse サービス名 (デフォルトでは、Workhorse は Web サービス Pods / Service の一部です) |
metrics.enabled | false | メトリクス・エンドポイントをスクレイピングできるようにする場合(sshDaemon=gitlab-sshd が必要)。 |
metrics.port | 9122 | メトリクス・エンドポイント・ポート |
metrics.path | /metrics | メトリクスエンドポイントパス |
metrics.serviceMonitor.enabled | false | Prometheus Operatorがメトリクスのスクレイピングを管理できるようにServiceMonitorを作成する必要がある場合、これを有効にすると、prometheus.io スクレイピング注釈が削除されることに注意してください。 |
metrics.serviceMonitor.additionalLabels | {} | ServiceMonitorに追加するラベル |
metrics.serviceMonitor.endpointConfig | {} | ServiceMonitorの追加エンドポイント設定 |
metrics.annotations | 廃止明示的なメトリクス・アノテーションを設定します。テンプレート・コンテンツに置き換えられました。 |
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
名前 | 種類 | デフォルト | 説明 |
---|---|---|---|
host | 文字列 | Workhorse サーバのホスト名。serviceName の代わりに省略することもできます。 | |
port | 整数 | 8181 | Workhorse サーバーに接続するポート。 |
serviceName | 文字列 | webservice | Workhorse サーバをオペレーションしているservice の名前。デフォルトでは Workhorse はウェブサービス Pods / Service の一部です。これが存在し、host が存在しない場合、Chart はhost の値の代わりにサービスのホスト名(と現在の.Release.Name )をテンプレート化します。これはWorkhorseをGitLabチャート全体の一部として使うときに便利です。 |
チャート設定
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
名前 | 種類 | デフォルト | 説明 |
---|---|---|---|
authToken.key | 文字列 | 認証トークンを含む上記の秘密のキーの名前。 | |
authToken.secret | 文字列 | プルする KubernetesSecret の名前。 |
ロードバランサーサービス
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 を特定のエンドポイントに制限するために使用します。
名前 | 種類 | デフォルト | 説明 |
---|---|---|---|
enabled | ブール値 | false | この設定はNetworkPolicy
|
ingress.enabled | ブール値 | false |
true に設定すると、Ingress ネットワーク ポリシーがアクティビティになります。これにより、ルールが指定されていない限り、すべての Ingress 接続がブロックされます。 |
ingress.rules | 配列 | [] | 詳細はhttps://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource と以下の例を参照してください。 |
egress.enabled | ブール値 | false |
true に設定すると、Egress ネットワーク ポリシーがアクティビティになります。これにより、ルールが指定されていない限り、すべてのイグレス接続がブロックされます。 |
egress.rules | 配列 | [] | イグレスポリシーのルール。詳細は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 リクエストが許可されます。 - TCP
10.0.0.0/8
ポート 8181 のネットワークへのすべての Egress リクエストは Workhorse に許可されています。 - 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
KEDAの設定
このkeda
セクションでは、通常のHorizontalPodAutoscalers
の代わりにKEDA ScaledObjects
をインストールできるようにします。この設定はオプションで、カスタムまたは外部のメトリクスに基づいてオートスケーリングする必要がある場合に使用できます。
ほとんどの設定は、該当する場合はhpa
セクションで設定された値にデフォルト設定されます。
以下が真である場合、hpa
セクションで設定された CPU とメモリのしきい値に基づいて、CPU とメモリのトリガーが自動的に追加されます:
-
triggers
がセットされていません。 - 対応する
request.cpu.request
またはrequest.memory.request
の設定もゼロ以外の値に設定されます。
トリガーが設定されていない場合、ScaledObject
は作成されません。
これらの設定の詳細については、KEDAのドキュメントを参照してください。
名前 | 種類 | デフォルト | 説明 |
---|---|---|---|
enabled | ブール値 | false | の代わりにKEDA ScaledObjects を使用します。HorizontalPodAutoscalers
|
pollingInterval | 整数 | 30 | 各トリガーを |
cooldownPeriod | 整数 | 300 | リソースを0にスケールバックする前に、最後のトリガがアクティブであると報告された後、待機する期間。 |
minReplicaCount | 整数 | KEDAがリソースをスケールダウンする最小レプリカ数。minReplicas
| |
maxReplicaCount | 整数 | KEDAがリソースをスケールアップする際の最大レプリカ数。maxReplicas
| |
fallback | マップ | KEDAフォールバック設定。 | |
hpaName | 文字列 | KEDAが作成するHPAリソースの名前。keda-hpa-{scaled-object-name}
| |
restoreToOriginalReplicaCount | ブール値 |
ScaledObject が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します。 | |
behavior | マップ | アップスケーリングとダウンスケーリングの動作を指定します。hpa.behavior
| |
triggers | 配列 | 対象リソースのスケーリングを有効にするトリガーのリスト。デフォルトはhpa.cpu とhpa.memory
|
keda
の使用例についてはexamples/keda/gitlab-shell.yml
を参照してください。