GitLab Webserviceチャートを使用する

このwebserviceサブチャートは、GitLab Railsウェブサーバーにポッドごとに2つのWebserviceワーカーを提供します。これは、単一のポッドがGitLabであらゆるウェブリクエストを処理するために最低限必要な数です。

このチャートのポッドは、2つのコンテナ、gitlab-workhorseとwebserviceを使用します。GitLab Workhorseはポート8181でリッスンし、ポッドへの受信トラフィックの_常に_宛先である必要があります。webserviceはGitLabのRailsコードベースを格納し、8080でリッスンしており、メトリクス収集の目的でアクセス可能です。webserviceは通常のトラフィックを直接受信すべきではありません。

要件

このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされているKubernetesクラスターから到達可能な外部サービスとして提供されるRedis、PostgreSQL、Gitaly、およびレジストリサービスに依存しています。

設定

このwebserviceチャートは次のように設定されます: グローバル設定 、デプロイ設定 、Ingress設定 、外部サービス 、およびチャート設定。

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

以下の表には、helm installコマンドで--setフラグを使用して指定できるすべてのチャートの設定が含まれています。

チャート設定例

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
deployments:
  default:
    extraEnvFrom:
      CONFIG_STRING:
        configMapKeyRef:
          name: useful-config
          key: some-string
          # optional: boolean

image.pullSecrets

pullSecretsを使用すると、プライベートレジストリに認証することで、ポッド用のイメージをプルすることができます。

プライベートレジストリとそれらの認証方法に関する追加の詳細は、Kubernetesドキュメントで確認できます。

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

image:
  repository: my.webservice.repository
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

serviceAccount

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

tolerations

tolerationsを使用すると、汚染されたワーカーノードにポッドをスケジュールできます。

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

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

annotations

annotationsを使用すると、Webserviceポッドにアノテーションを追加できます。例:

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

strategy

deployment.strategyを使用すると、デプロイの更新戦略を変更できます。デプロイが更新されたときにポッドがどのように再作成されるかを定義します。指定しない場合、クラスターのデフォルトが使用されます。たとえば、ローリングアップデート開始時に追加のポッドを作成せず、最大利用不可ポッドを50%に変更したい場合:

deployment:
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 50%

更新戦略のタイプをRecreateに変更することもできますが、これは新しいポッドをスケジュールする前にすべてのポッドを強制終了するため、新しいポッドが起動するまでウェブUIが利用できなくなることに注意してください。この場合、rollingUpdateを定義する必要はなく、typeのみで構いません:

deployment:
  strategy:
    type: Recreate

詳細については、Kubernetesドキュメントを参照してください。

TLS

Webserviceポッドは2つのコンテナを実行します:

• gitlab-workhorse
• webservice

gitlab-workhorse

Workhorseはウェブおよびメトリクスエンドポイントの両方でTLSをサポートします。これにより、Workhorseと他のコンポーネント、特にnginx-ingress、gitlab-shell、およびgitaly間の通信が保護されます。TLS証明書には、Workhorseサービスのホスト名（例：RELEASE-webservice-default.default.svc）をCommon Name（CN）またはSubject Alternate Name（SAN）に含める必要があります。

Webserviceの複数のデプロイが存在する可能性があるため、異なるサービス名に対応するTLS証明書を準備する必要があることに注意してください。これは複数のSANまたはワイルドカード証明書によって実現できます。

TLS証明書が生成されたら、それ用のKubernetes TLSシークレットを作成します。また、TLS証明書のCA証明書のみを含む別のシークレットをca.crtキーで作成する必要があります。

global.workhorse.tls.enabledをtrueに設定することで、gitlab-workhorseコンテナでTLSを有効にできます。カスタムシークレット名をgitlab.webservice.workhorse.tls.secretNameおよびglobal.certificates.customCAsにそれぞれ渡すことができます。

gitlab.webservice.workhorse.tls.verifyがtrue（デフォルト）の場合、CA証明書のシークレット名をgitlab.webservice.workhorse.tls.caSecretNameに渡す必要もあります。これは自己署名証明書およびカスタム認証局に必要です。このシークレットは、NGINXがWorkhorseのTLS証明書を検証するために使用します。

global:
  workhorse:
    tls:
      enabled: true
  certificates:
    customCAs:
      - secret: gitlab-workhorse-ca
gitlab:
  webservice:
    workhorse:
      tls:
        verify: true
        # secretName: gitlab-workhorse-tls
        caSecretName: gitlab-workhorse-ca
      monitoring:
        exporter:
          enabled: true
          tls:
            enabled: true

gitlab-workhorseコンテナのメトリクスエンドポイントにおけるTLSはglobal.workhorse.tls.enabledから継承されます。メトリクスエンドポイントにおけるTLSは、WorkhorseでTLSが有効な場合にのみ利用可能であることに注意してください。このメトリクスリスナーは、gitlab.webservice.workhorse.tls.secretNameで指定されたものと同じTLS証明書を使用します。

メトリクスエンドポイントに使用されるTLS証明書は、特に含まれるPrometheus Helmチャートを使用する場合、含まれるSubject Alternative Names（SANs）について追加の考慮事項を必要とする場合があります。詳細については、Prometheusをスクレイプ可能なTLS有効エンドポイントに設定するを参照してください。

webservice

TLSを有効にする主なユースケースは、PrometheusメトリクスをスクレイプするためのHTTPS経由の暗号化を提供することです。

PrometheusがHTTPSを使用して/metrics/エンドポイントをスクレイプするには、証明書のCommonName属性またはSubjectAlternativeNameエントリに追加の設定が必要です。これらの要件については、Prometheusをスクレイプ可能なTLS有効エンドポイントに設定するを参照してください。

gitlab.webservice.tls.enabled設定により、webserviceコンテナでTLSを有効にできます:

gitlab:
  webservice:
    tls:
      enabled: true
      # secretName: gitlab-webservice-tls

secretNameはKubernetes TLSシークレットを指す必要があります。例えば、ローカル証明書とキーを持つTLSシークレットを作成するには:

kubectl create secret tls <secret name> --cert=path/to/puma.crt --key=path/to/puma.key

このチャートのCommunity Editionを使用する

デフォルトの場合、HelmチャートではGitLabのEnterprise Editionを使用します。必要であれば、代わりにCommunity Editionを使用できます。両者の違いについて詳しくはこちら。

Community Editionを使用するには、image.repositoryをregistry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ceに、workhorse.imageをregistry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ceに設定します。

グローバル設定

いくつかの一般的なグローバル設定をチャート間で共有しています。共通の設定オプション（GitLabやレジストリのホスト名など）については、Globalsドキュメントを参照してください。

デプロイ設定

このチャートは、複数のデプロイオブジェクトとそれに関連するリソースを作成する機能を持っています。この機能により、GitLabアプリケーションへのリクエストは、パスベースのルーティングを使用して複数のポッドセット間で分散されます。

このマップのキー（この例ではdefault）は、それぞれの「名前」です。defaultには、デプロイ、サービス、HorizontalPodAutoscaler、PodDisruptionBudget、およびオプションでRELEASE-webservice-defaultで作成されたIngressが設定されます。

提供されていないプロパティは、gitlab-webserviceチャートのデフォルトから継承されます。

deployments:
  default:
    ingress:
      path: # Does not inherit or default. Leave blank to disable Ingress.
      pathType: Prefix
      provider: nginx
      annotations:
        # inherits `ingress.anntoations`
      proxyConnectTimeout: # inherits `ingress.proxyConnectTimeout`
      proxyReadTimeout:    # inherits `ingress.proxyReadTimeout`
      proxyBodySize:       # inherits `ingress.proxyBodySize`
    deployment:
      annotations: # map
      labels: # map
      # inherits `deployment`
    pod:
      labels: # additional labels to .podLabels
      annotations: # map
        # inherit from .Values.annotations
    service:
      labels: # additional labels to .serviceLabels
      annotations: # additional annotations to .service.annotations
        # inherits `service.annotations`
    hpa:
      minReplicas: # defaults to .minReplicas
      maxReplicas: # defaults to .maxReplicas
      metrics: # optional replacement of HPA metrics definition
      # inherits `hpa`
    pdb:
      maxUnavailable: # inherits `maxUnavailable`
    resources: # `resources` for `webservice` container
      # inherits `resources`
    workhorse: # map
      # inherits `workhorse`
    extraEnv: #
      # inherits `extraEnv`
    extraEnvFrom: #
      # inherits `extraEnvFrom`
    puma: # map
      # inherits `puma`
    workerProcesses: # inherits `workerProcesses`
    shutdown:
      # inherits `shutdown`
    nodeSelector: # map
      # inherits `nodeSelector`
    tolerations: # array
      # inherits `tolerations`
    priorityClassName: # inherits `priorityClassName`

デプロイIngress

各deploymentsエントリは、チャート全体のIngress設定を継承します。ここで提示される値は、そちらで提供される値をオーバーライドします。pathを除き、すべての設定は同じです。

webservice:
  deployments:
    default:
      ingress:
        path: /
    api:
      ingress:
        path: /api

pathプロパティはIngressのpathプロパティに直接入力され、各サービスに送信されるURIパスを制御できます。上記の例では、defaultがキャッチオールパスとして機能し、apiが/api以下のすべてのトラフィックを受信しました。

pathを空に設定することで、特定のデプロイに関連付けられたIngressリソースが作成されないように無効にできます。以下を参照してください。internal-apiは外部トラフィックを受信しません。

webservice:
  deployments:
    default:
      ingress:
        path: /
    api:
      ingress:
        path: /api
    internal-api:
      ingress:
        path:

Ingress設定

アノテーション

annotationsはWebservice Ingressにアノテーションを設定するために使用されます。

serviceUpstream

これにより、NGINXにサービス自体をアップストリームとして直接コンタクトさせることで、Webserviceポッドへのトラフィックをより均等に分散するのに役立ちます。詳細については、NGINXドキュメントを参照してください。

これをオーバーライドするには、以下を設定します:

gitlab:
  webservice:
    ingress:
      serviceUpstream: "false"

proxyBodySize

proxyBodySizeは、NGINXプロキシの最大ボディサイズを設定するために使用されます。これは、デフォルトよりも大きなDockerイメージを許可するために一般的に必要です。これはLinuxパッケージインストールにおけるnginx['client_max_body_size']設定と同等です。代替オプションとして、以下の2つのパラメータのいずれかでもボディサイズを設定できます:

• gitlab.webservice.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"
• global.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"

追加Ingress

extraIngress.enabled=trueを設定することで、追加のIngressをデプロイできます。このIngressは、デフォルトのIngressに-extraサフィックスを付けて命名され、デフォルトのIngressと同じ設定をサポートします。

ゲートウェイAPI

GitLabチャートがGateway API経由で公開されるように設定されている場合、各デプロイはwebserviceチャートのHTTPRouteへのルールとして追加されます。

.rules=[]をデプロイに設定することで、特定のデプロイがHTTPRouteにルールを持つことを無効にできます。

webservice:
  deployments:
    default:
      gatewayRoute:
        rules:
        - matches:
          - path:
              type: PathPrefix
              value: /
            timeouts:
              request: "20s"
              backendRequest: "20s"
    api:
      gatewayRoute:
        rules:
        - matches:
          - path:
              type: PathPrefix
              value: /api
    internal-api:
      gatewayRoute:
        rules: []

リソース

メモリリクエスト/制限

各ポッドはworkerProcessesに等しい数のワーカーを起動し、それぞれが一定量のメモリを使用します。推奨事項:

• ワーカーあたり最小1.25GB（requests.memory）
• ワーカーあたり最大1.5GB、プライマリ用に1GB追加（limits.memory）

必要なリソースは、ユーザーによって生成されるワークロードに依存し、将来、GitLabアプリケーションの変更やアップグレードに基づいて変更される可能性があることに注意してください。

デフォルト:

workerProcesses: 2
resources:
  requests:
    memory: 2.5G # = 2 * 1.25G
# limits:
#   memory: 4G   # = (2 * 1.5G) + 950M

4つのワーカーが設定されている場合:

workerProcesses: 4
resources:
  requests:
    memory: 5G   # = 4 * 1.25G
# limits:
#   memory: 7G   # = (4 * 1.5G) + 950M

外部サービス

Redis

Redisドキュメントはグローバルページに統合されました。最新のRedis設定オプションについては、このページを参照してください。

PostgreSQL

PostgreSQLドキュメントはグローバルページに統合されました。最新のPostgreSQL設定オプションについては、このページを参照してください。

Webserviceデプロイ内のdependencies initContainerは、スクリプトを実行して以下をチェックします:

• GitLabの依存関係が利用可能かどうか。
• PostgreSQL用のデータベース移行が実行されたかどうか。

WebserviceチャートのextraEnv設定キーを使用して、これらのスクリプトの動作を制御できます。2つの環境変数がサポートされています:

• BYPASS_POST_DEPLOYMENT=true: すべての通常の移行が実行され、デプロイ後の移行のみが保留中の場合、依存関係チェックは合格します。
• BYPASS_SCHEMA_VERSION=true（推奨されません）: 通常の移行が実行されていない場合でも、依存関係チェックは合格します。この環境変数を使用すると、データベーススキーマがアプリケーションコードの期待値と一致しないため、Railsデプロイは起動後にエラーになる可能性があります。

Gitaly

global:
  gitaly:
    ## These settings are used by Gitaly clients: GitLab Rails, GitLab Shell, Workhorse.
    client:
      maxAttempts: 4
      maxBackoff: '1.4s'

その他のGitaly設定は、グローバル設定によって設定されます。Gitaly設定ドキュメントを参照してください。

MinIO

minio:
  serviceName: 'minio-svc'
  port: 9000

レジストリ

registry:
  host: registry.example.com
  port: 443
  api:
    protocol: http
    host: registry.example.com
    serviceName: registry
    port: 5000
  tokenIssuer: gitlab-issuer
  certificate:
    secret: gitlab-registry
    key: registry-auth.key

チャート設定

以下の値はWebserviceポッドを設定するために使用されます。

メトリクス

メトリクスはmetrics.enabledの値で有効にでき、GitLabモニタリングexporterを使用してメトリクスポートを公開します。ポッドにはPrometheusアノテーションが与えられるか、metrics.serviceMonitor.enabledがtrueの場合はPrometheus Operator ServiceMonitorが作成されます。メトリクスは代わりに/-/metricsエンドポイントからスクレイプできますが、これには管理者エリアでGitLab Prometheusメトリクスが有効になっている必要があります。GitLab Workhorseメトリクスもworkhorse.metrics.enabledを介して公開できますが、これらはPrometheusアノテーションを使用して収集できないため、workhorse.metrics.serviceMonitor.enabledがtrueであるか、または外部Prometheus設定が必要です。

GitLab Shell

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

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

ウェブサーバーオプション

現在のバージョンのチャートはPumaウェブサーバーをサポートしています。

Puma固有のオプション:

Workhorseロードシェディング

ロードシェディングは、リクエストバックログが設定されたしきい値を超えたときに設定されたHTTPステータスコードを返すことでPumaが過負荷になるのを防ぎ、リバースプロキシが他のインスタンスへのリクエストを再試行できるようにします。

ロードシェディングを有効にするには、loadSheddingパラメータを設定します:

gitlab:
  webservice:
    workhorse:
      loadShedding:
        enabled: true
        backlogThreshold: 50
        retryAfterSeconds: 0
        statusCode: 503
        strategy: max

• backlogThresholdは、ロードシェディングをトリガーする滞留リクエストの数を指定します。
• retryAfterSecondsは、レスポンスのRetry-Afterヘッダーの値を設定します。
• statusCodeは、ロードシェディング時に返すHTTPステータスコードを設定します（デフォルト：503）。データベースのタイムアウトやGitalyの問題によって引き起こされる他の503エラーからロードシェディングを区別するために、529のようなカスタムコードを使用します。
• strategyは、実効バックログがどのように計算されるかを決定します:
  • max: すべてのPumaワーカーにおける最大バックログを使用します（デフォルト）。
  • sum: すべてのPumaワーカーにおけるすべてのバックログの合計を使用します。

プロキシ設定

ロードシェディングを効果的に機能させるには、リバースプロキシが503レスポンスを受信したときにリクエストを再試行するように設定されている必要があります。これにより、リクエストが正常なインスタンスに分散されることが保証されます。

NGINXの例として、Ingressに次のアノテーションを設定します:

ingress:
  annotations:
    nginx.ingress.kubernetes.io/proxy-next-upstream: "http_503"
    nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "3"
    nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "10s"

これらの設定はNGINXに以下を指示します:

• 503レスポンスで再試行します（ロードシェディングが生成します）。
• 諦めるまでに3回まで試行します。
• 再試行のために最大10秒待ちます。

ロードシェディングが生成する特定のシグナルである503レスポンスでのみ再試行すべきです。他のステータスコード（504など）やエラー条件での再試行は避けてください。これらは、すべてのバックエンドで失敗する可能性のあるリクエストを再試行することで、停止中の負荷を増幅させる可能性があります。

他のリバースプロキシについては、同等の再試行設定についてそれぞれのドキュメントを参照してください。重要なキーは、503レスポンスが他のバックエンドインスタンスへの再試行をトリガーすることを保証することです。

このnetworkpolicyを設定する

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

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

webserviceサービスは、有効な場合はPrometheus exporter用のIngress接続、NGINX Ingressからのトラフィック、およびいくつかのGitLabポッドを必要とします。通常、さまざまな場所へのエグレス接続が必要です。この例では、以下のネットワークポリシーを追加します:

• Ingressリクエストを許可します:
  • ポッドgitaly、gitlab-pages、gitlab-shell、kas、mailroom、およびnginx-ingressからポート8181へ
  • Prometheusポッドからポート8080、8083、9229へ
• エグレスリクエストを許可します:
  • gitalyポッドへのポート8075
  • kasポッドへのポート8153
  • kube-dnsへのポート53
  • registryポッドへのポート5000
  • 外部データベース172.16.0.10/32へのポート5432
  • 外部Redis 172.16.0.11/32へのポート6379
  • インターネット0.0.0.0/0へのポート443
  • AWS VPCエンドポイント（S3またはSTS用）などのエンドポイント172.16.1.0/24へのポート443

提供されている例は単なる例であり、完全ではない可能性があります。Webserviceは、外部オブジェクトストレージ上のイメージのために、パブリックインターネットへの送信接続を必要とします。この例は、kube-dnsがkube-systemネームスペースにデプロイされ、prometheusがmonitoringネームスペースにデプロイされ、nginx-ingressがnginx-ingressネームスペースにデプロイされたという前提に基づいています。

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
          - podSelector:
              matchLabels:
                app: gitaly
        ports:
          - port: 8181
      - from:
          - podSelector:
              matchLabels:
                app: gitlab-pages
        ports:
          - port: 8181
      - from:
          - podSelector:
              matchLabels:
                app: gitlab-shell
        ports:
          - port: 8181
      - from:
          - podSelector:
              matchLabels:
                app: kas
        ports:
          - port: 8181
      - from:
          - podSelector:
              matchLabels:
                app: mailroom
        ports:
          - port: 8181
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: nginx-ingress
            podSelector:
              matchLabels:
                app: nginx-ingress
                component: controller
        ports:
          - port: 8181
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: monitoring
            podSelector:
              matchLabels:
                app: prometheus
                component: server
                release: gitlab
        ports:
          - port: 9229
          - port: 8080
          - port: 8083
  egress:
    enabled: true
    rules:
      - to:
          - podSelector:
              matchLabels:
                app: gitaly
        ports:
          - port: 8075
      - to:
          - podSelector:
              matchLabels:
                app: kas
        ports:
          - port: 8153
      - to:
          - ipBlock:
              cidr: 0.0.0.0/0
              except:
                - 10.0.0.0/8
        ports:
          - port: 443
      - to:
          - ipBlock:
              cidr: 172.16.0.10/32
        ports:
          - port: 5432
      - to:
          - ipBlock:
              cidr: 172.16.0.11/32
        ports:
          - port: 6379
      - to:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: kube-system
            podSelector:
              matchLabels:
                k8s-app: kube-dns
        ports:
          - port: 53
            protocol: UDP

LoadBalancerサービス

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

service.typeがLoadBalancerに設定されている場合、LoadBalancerにアクセスできるCIDR範囲を制限するためにservice.loadBalancerSourceRangesも設定する必要があります（クラウドプロバイダーがサポートしている場合）。これは、メトリクスポートが公開されている問題により現在必要です。

LoadBalancerサービスタイプに関する追加情報は、Kubernetesドキュメントで確認できます。

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

KEDAを設定する

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

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

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

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

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

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