GitLabチャートの前提条件

KubernetesクラスターにGitLabをデプロイする前に、以下の前提条件をインストールし、インストール時に使用するオプションを決定してください。

前提条件

kubectl

kubectlをKubernetes documentationに従ってインストールします。インストールするバージョンは、クラスターで実行されているバージョンとwithin one minor releaseでなければなりません。

Helm

Helm v4.0以降をHelm documentationに従ってインストールします。

GitLabチャートは、公式EOL（estimated in July 2026）までHelm 3のサポートを継続します。

PostgreSQL

本番環境のデプロイには、external PostgreSQL instanceを設定します。

サポートされているPostgreSQLバージョンについては、the GitLab requirementsを確認してください。

Redis

本番環境のデプロイには、external Redis instanceを設定します。利用可能なすべての設定については、Redis globals documentationを参照してください。

Gitaly

デフォルトでは、GitLabチャートにはインクラスターGitalyデプロイが含まれています。本番環境では、KubernetesでのGitalyの実行はサポートされていません。Gitaly is only supported on conventional virtual machines。

external, production-ready Gitaly instanceを設定する必要があります。利用可能なすべての設定については、Gitaly globals documentationを参照してください。

その他のオプションを決定する

GitLabをデプロイする際に、helm installとともに以下のオプションを使用します。

シークレット

SSHキーのようなシークレットを作成する必要があります。デフォルトでは、これらのシークレットはデプロイ中に自動的に生成されますが、それらを指定したい場合は、secrets documentationを参照してください。

ネットワーキングとDNS

デフォルトでは、サービスを公開するために、GitLabはIngressオブジェクトで設定された名前ベースの仮想サーバーを使用します。これらのオブジェクトは、Kubernetes Serviceのtype: LoadBalancerオブジェクトです。

gitlab、registry、およびminio（有効な場合）を、チャートの適切なIPアドレスに解決するレコードを含むドメインを指定する必要があります。

たとえば、helm installとともに次を使用します:

--set global.hosts.domain=example.com

カスタムドメインサポートが有効な場合、デフォルトで<pages domain>である*.<pages domain>サブドメインは、pages.<global.hosts.domain>になります。このドメインは、--set global.pages.externalHttpまたは--set global.pages.externalHttpsによってPagesに割り当てられた外部IPに解決されます。

カスタムドメインを使用するには、GitLab Pagesは、カスタムドメインを対応する<namespace>.<pages domain>ドメインにポイントするCNAMEレコードを使用できます。

動的IPアドレスとexternal-dns

external-dnsのような自動DNS登録サービスを使用する予定がある場合は、GitLabの追加の設定は必要ありません。ただし、external-dnsをクラスターにデプロイする必要があります。プロジェクトページには、サポートされている各プロバイダー向けのhas a comprehensive guideがあります。

GKE clusterをプロビジョニングする場合、external-dnsがクラスターに自動的にインストールされます。

静的IPアドレス

手動でDNSレコードを設定する予定がある場合は、すべて静的IPアドレスを指すようにする必要があります。たとえば、example.comを選択し、10.10.10.10の静的IPアドレスを持っている場合、gitlab.example.com、registry.example.com、およびminio.example.com（MinIOを使用している場合）はすべて10.10.10.10に解決される必要があります。

GKEを使用している場合は、creating the external IP and DNS entryの詳細を参照してください。このプロセスに関する詳細については、クラウドプロバイダーまたはDNSプロバイダーのドキュメントを参照してください。

たとえば、helm installとともに次を使用します:

--set global.hosts.externalIP=10.10.10.10

Istioプロトコル選択との互換性

サービスポート名は、Istioのexplicit port selectionと互換性のある規則に従います。これらは<protocol>-<suffix>のようになります。たとえば、tls-gitalyまたはhttps-metricsです。

GitalyとKASはgRPCを使用しますが、Issue #3822およびIssue #4908の調査結果により、代わりにtcpプレフィックスを使用します。

永続

デフォルトでは、GitLabチャートは、動的なプロビジョナーが基盤となる永続ボリュームを作成することを期待してボリュームクレームを作成します。storageClassをカスタマイズしたり、ボリュームを手動で作成および割り当てたりする場合は、storage documentationを参照してください。

TLS証明書

GitLabはHTTPSで実行する必要があります。これにはTLS証明書が必要です。デフォルトでは、GitLabチャートは、無料のTLS証明書を取得するためにcert-managerをインストールして設定します。

独自のワイルドカード証明書をお持ちの場合、またはすでにcert-managerをインストールしている場合、あるいはTLS証明書を取得する他の方法がある場合は、TLS optionsで詳細を参照してください。

デフォルトの設定では、TLS証明書を登録するためにメールアドレスを指定する必要があります。たとえば、helm installとともに次を使用します:

--set certmanager-issuer.email=me@example.com

Prometheus

私たちはupstream Prometheus chartを使用しており、カスタマイズされたprometheus.ymlファイルを除いて、独自のデフォルトから値をオーバーライドしません。このファイルは、Kubernetes APIとGitLabチャートによって作成されたオブジェクトへのメトリクスの収集を制限します。ただし、デフォルトでは、alertmanager、node-exporter、pushgateway、およびkube-stat-metricsを無効にします。

prometheus.ymlファイルは、Prometheusにgitlab.com/prometheus_scrapeアノテーションを持つリソースからメトリクスを収集するように指示します。さらに、gitlab.com/prometheus_pathとgitlab.com/prometheus_portアノテーションを使用して、メトリクスがどのように検出されるかを設定できます。これらのアノテーションはそれぞれ、prometheus.io/{scrape,path,port}アノテーションに匹敵します。

お使いのPrometheusのインストールでGitLabアプリケーションをモニタリングしている、またはモニタリングしたい場合は、元のprometheus.io/*アノテーションが適切なポッドとサービスに引き続き追加されます。これにより、既存ユーザーのメトリクス収集の継続性が確保され、デフォルトのPrometheus設定を使用してGitLabアプリケーションメトリクスとKubernetesクラスターで実行されている他のアプリケーションの両方をキャプチャする機能が提供されます。

upstream Prometheus chart documentationで設定オプションの網羅的なリストを参照し、これらがprometheusのサブキーであることを確認してください。これは要件チャートとして使用するためです。

たとえば、永続ストレージのリクエストは次のように制御できます:

prometheus:
  alertmanager:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  prometheus-pushgateway:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  server:
    persistentVolume:
      enabled: true
      size: 8Gi

PrometheusでTLS対応エンドポイントをスクレイプするように設定する

指定されたexporterがTLSを許可し、チャートの設定がexporterのエンドポイントのTLS設定を公開している場合、PrometheusはTLS対応エンドポイントからメトリクスをスクレイプするように設定できます。

TLSとKubernetes Service DiscoveryをPrometheusのscrape configurationsに使用する場合、いくつかの注意点があります:

• podとservice endpointsのディスカバリロールの場合、Prometheusはポッドの内部IPアドレスを使用して、スクレイプターゲットのアドレスを設定します。TLS証明書を検証するには、Prometheusは、メトリクスエンドポイント用に作成された証明書に設定されているコモンネーム（CN）で設定するか、サブジェクト代替名（SAN）拡張に含まれる名前で設定する必要があります。その名前は解決される必要はなく、valid DNS nameである任意の文字列でかまいません。
• exporterのエンドポイントに使用される証明書が自己署名されているか、またはPrometheusのベースイメージに存在しない場合、Prometheusポッドは、exporterのエンドポイントに使用される証明書に署名した認証局（CA）の証明書をマウントする必要があります。Prometheusは、Debianからca-bundleをin its base imageで使用します。
• Prometheusは、これらの両方の項目をtls_configを使用して設定することをサポートしており、これは各スクレイプ設定に適用されます。Prometheusには、ポッドアノテーションおよびその他の検出された属性に基づいてPrometheusターゲットラベルを設定するための堅牢なrelabel_configメカニズムがありますが、relabel_configを使用してtls_config.server_nameとtls_config.ca_fileを設定することはできません。詳細については、このPrometheus project issueを参照してください。

これらの注意点を考慮すると、最も簡単な設定は、exporterエンドポイントに使用されるすべての証明書で「name」とCAを共有することです:

1. tls_config.server_nameに使用する単一の任意の名前を選択します（たとえば、metrics.gitlab）。
2. その名前を、exporterエンドポイントをTLSで暗号化するために使用される各証明書のSANリストに追加します。
3. すべての証明書を同じCAから発行します:
   • CA証明書をクラスターシークレットとして追加します。
   • そのシークレットを、Prometheus chart’s extraSecretMounts:設定を使用してPrometheusサーバーコンテナにマウントします。
   • それをPrometheusのscrape_configのtls_config.ca_fileとして設定します。

Prometheus TLS values exampleは、この共有設定の例を次のように提供します:

1. ポッド/エンドポイントscrape_configロールのtls_config.server_nameをmetrics.gitlabに設定します。
2. metrics.gitlabが、exporterエンドポイントに使用されるすべての証明書のSANリストに追加されていると仮定します。
3. CA証明書が、Prometheusチャートがデプロイされている同じネームスペースに作成されたmetrics.gitlab.tls-caという名前のシークレットに、metrics.gitlab.tls-caという名前のシークレットキーとともに追加されていると仮定します（たとえば、kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem）。
4. そのmetrics.gitlab.tls-caシークレットを/etc/ssl/certs/metrics.gitlab.tls-caにextraSecretMounts:エントリを使用してマウントします。
5. tls_config.ca_fileを/etc/ssl/certs/metrics.gitlab.tls-caに設定します。

Exporterエンドポイント

GitLabチャートに含まれるすべてのメトリクスエンドポイントがTLSをサポートしているわけではありません。エンドポイントがTLSを有効にできる場合は、gitlab.com/prometheus_scheme: "https"アノテーションとprometheus.io/scheme: "https"アノテーションも設定します。これらはいずれもrelabel_configとともに使用してPrometheus __scheme__ターゲットラベルを設定できます。Prometheus TLS values exampleには、gitlab.com/prometheus_scheme: "https"アノテーションを使用して__scheme__をターゲットとするrelabel_configが含まれています。

以下の表に、GitalyとPraefectのいずれかまたは両方を使用する場合のデプロイメントをリストします: StatefulSets）およびgitlab.com/prometheus_scrape: trueアノテーションが適用されているサービスエンドポイント。

以下のドキュメントリンクで、コンポーネントがSANエントリの追加について言及している場合は、Prometheus tls_config.server_nameに使用することに決めたSANも追加してください。

ウェブサービスポッドの場合、公開ポートはウェブサービスコンテナ内のスタンドアロンのwebrick exporterです。ワークホースコンテナポートはスクレイプされません。追加の詳細については、Webservice Metrics documentationを参照してください。

送信メール

デフォルトでは、送信メールは無効になっています。これを有効にするには、global.smtpとglobal.email設定を使用してSMTPサーバーの詳細を指定します。これらの設定の詳細については、command line optionsで確認できます。

SMTPサーバーで認証が必要な場合は、secrets documentationでパスワードの提供に関するセクションを必ずお読みください。--set global.smtp.authentication=""を使用して認証設定を無効にできます。

お使いのKubernetesクラスターがGKE上にある場合、SMTP port 25 is blockedに注意してください。

受信メール

受信メールの設定は、mailroom chartにドキュメント化されています。

サービスデスクのメール

受信メールの設定は、mailroom chartにドキュメント化されています。

RBAC

GitLabチャートは、デフォルトでRBACを作成して使用します。クラスターでRBACが有効になっていない場合は、これらの設定を無効にする必要があります:

--set certmanager.rbac.create=false
--set nginx-ingress.rbac.createRole=false
--set prometheus.rbac.create=false
--set gitlab-runner.rbac.create=false

次の手順

Set up your cloud provider and create your cluster。