• 要件
• 設定
• インストールのコマンドラインオプション
• Chart設定例
  • extraEnv
  • 追加EnvFrom
  • 画像.pullSecrets
  • 許容範囲
  • 注釈
  • 戦略
  • TLS
    • gitlab-workhorse
    • webservice
• このChartのCommunity Editionを使用する場合
• グローバル設定
• デプロイの設定
  • デプロイ イングレス
• Ingressの設定
  • 注釈
  • プロキシボディサイズ
  • 追加イングレス
• リソース
  • メモリ要求/制限
• 外部サービス
  • Redis
  • PostgreSQL
  • Gitaly
  • MinIO
  • レジストリ
• チャート設定
  • メトリクス
  • GitLab シェル
  • ウェブサーバーのオプション
• 設定networkpolicy
  • ネットワークポリシーの例
  • ロードバランサーサービス
• KEDAの設定

GitLab ウェブサービスチャートの使用

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

このChartのポッドは、gitlab-workhorse とwebservice の2つのコンテナを利用しています。GitLab Workhorseはポート8181をリッスンし、ポッドへのインバウンドトラフィックの宛先と_なります_。webservice には GitLabRails コードベースが格納され、8080でリッスンし、メトリクス収集の目的でアクセスできます。webservice は、通常のトラフィックを直接受け取ってはいけません。

要件

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

設定

webservice Chart の設定は以下のとおりです：グローバル設定、デプロイ設定、イングレス設定、外部サービス、チャート設定。

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

以下の表は、--set フラグを使用して、helm install コマンドに供給できるすべての可能なチャート設定を示しています。

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

画像.pullSecrets

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

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

以下は、pullSecrets の使用例です：

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

許容範囲

tolerations 汚染されたワーカーノードでポッドのスケジューリングが可能

以下は、tolerations の使用例です：

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

注釈

annotations を使用すると、Web サービスポッドに注釈を追加できます。例えば

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

戦略

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

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

更新ストラテジーのタイプをRecreate に変更することもできますが、新しいポッドをスケジュールする前にすべてのポッドが停止し、新しいポッドが起動するまで Web 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証明書は、Common Name(CN) または Subject Alternate Name(SAN)にWorkhorse Serviceホスト名（例：RELEASE-webservice-default.default.svc ）を含める必要があります。

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

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

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

gitlab.webservice.workhorse.tls.verify がtrue の場合（デフォルト）、gitlab.webservice.workhorse.tls.caSecretName に CA 証明書のシークレット名を渡す必要があります。これは自己署名証明書とカスタム CA の場合に必要です。このシークレットは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 チャートを使用する場合、付属のサブジェクト代替名 (SAN) に対して追加の考慮が必要になる場合があります。詳細については、TLS対応エンドポイントをスクレイピングするPrometheusの設定を参照してください。

webservice

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

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

TLS はgitlab.webservice.tls.enabled の設定によりwebservice コンテナで有効にすることができます：

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

このChartのCommunity Editionを使用する場合

デフォルトでは、HelmチャートはGitLabのEnterprise 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 に設定します。

グローバル設定

私たちのChartには共通のグローバル設定があります。GitLabやレジストリのホスト名など、共通の設定オプションについてはGlobals Documentationをご覧ください。

デプロイの設定

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

この Map (default この例では ) defaultのキーdefault はそれぞれの “name” です。 defaultデプロイ、サービス、HorizontalPodAutoscaler、PodDisruptionBudget、そしてオプションでRELEASE-webservice-default で作成された Ingress があります。

提供されていないプロパティは、gitlab-webservice Chartのデフォルトを継承します。

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`

デプロイ イングレス

deployments の各エントリーはChart全体の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 にアノテーションを設定するために使用します。

デフォルトでは1つのアノテーションを設定します:nginx.ingress.kubernetes.io/service-upstream: "true" 。これにより、NGINX がアップストリームとしてサービス自体に直接連絡するように指示することで、Webservice ポッドへのトラフィックをより均等にバランスさせることができます。詳細はNGINXのドキュメントを参照してください。

これをオーバーライドするには

gitlab:
  webservice:
    ingress:
      annotations:
        nginx.ingress.kubernetes.io/service-upstream: "false"

プロキシボディサイズ

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"

追加イングレス

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

リソース

メモリ要求/制限

各ポッドは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のドキュメントはglobalsページに統合されました。最新のRedis設定オプションについては、このページを参照してください。

PostgreSQL

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

Gitaly

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

チャート設定

以下の値は、ウェブサービス・ポッドの設定に使用されます。

メトリクス

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

GitLab シェル

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

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

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

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

Puma独自のオプション：

設定networkpolicy

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

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

Webサービスサービスは、Prometheusエクスポートが有効な場合、およびNGINX Ingressからのトラフィックに対してのみIngress接続を必要とし、通常はさまざまな場所へのEgress接続を必要とします。この例では、次のネットワークポリシーを追加します：

• TCP10.0.0.0/8 ポート 8080 のネットワークからのすべての Ingress リクエストは、メトリクスのエクスポートと NGINX Ingress に対して許可されます。
• UDP10.0.0.0/8 ポート 53 のネットワークへのすべての Egress リクエストは、DNS のために許可されます。
• PostgreSQL では、TCP10.0.0.0/8 ポート 5432 のネットワークへのすべての Egress リクエストが許可されます。
• Redis では、TCP10.0.0.0/8 ポート 6379 でネットワークへのすべての Egress リクエストが許可されます。
• Gitaly では、TCP10.0.0.0/8 ポート 8075 のネットワークへのすべての Egress リクエストが許可されます。
• 10.0.0.0/8 の内部ネットワークへのその他のEgressリクエストは制限されています。
• 10.0.0.0/8 の外部へのegressリクエストは許可されています。

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

ウェブサービスは、外部オブジェクトストレージ上の画像に対して公開インターネットへのアウトバウンド接続を必要とすることに注意してください。

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 8080
  egress:
    enabled: true
    rules:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 53
          protocol: UDP
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 5432
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 6379
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 8075
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
            - 10.0.0.0/8

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

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 セクションで設定された値にデフォルト設定されます。

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

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

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

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