GitLab チャートのトラブルシューティング

アップグレードに失敗しました：ジョブに失敗しました：BackoffLimitExceeded

Chart を 6.0 にアップグレードしたときにこのエラーが出たのであれば、おそらく正しいアップグレード手順を踏んでいないことが原因でしょう：

  1. GitLab Helm のリリース名を特定するために、すべてのリリースをリストアップしてください（リリースがdefault K8s ネームスペースにデプロイされていない場合は、-n <namespace> を含める必要があります）：

    helm ls

  2. あなたの GitLab Helm リリースがgitlab という名前だとすると、リリース履歴を見て最後に成功したリビジョンを特定する必要があります（リビジョンのステータスはDESCRIPTION で確認できます）：

    helm history gitlab

  3. 最後に成功したリビジョンが1 だとすると、このコマンドを使ってロールバックしてください：

    helm rollback gitlab 1

  4. <x> を適切な Chart バージョンに置き換えて、アップグレードコマンドを再実行してください：

    helm upgrade --version=5.10.<x>

  5. この時点で、--version オプションを使って特定の 6.x.x チャートバージョンを渡すか、GitLab の最新バージョンにアップグレードするオプションを削除することができます：

    helm upgrade --install gitlab gitlab/gitlab <other_options>

コマンドライン引数の詳細については、Helm を使ったデプロイをご覧ください。ChartのバージョンとGitLabのバージョンのマッピングについては、GitLab version mappingsをご覧ください。

アップグレードに失敗しました：”$name” にはデプロイ済みのリリースがありません。

このエラーは、最初のインストールが失敗した場合、2回目のインストール/アップグレードで発生します。

最初のインストールが完全に失敗し、GitLabがオペレーション可能な状態でなかった場合は、再インストールする前にまず失敗したインストールを削除してください。

helm uninstall <release-name>

代わりに、最初のインストールコマンドはタイムアウトしたが、GitLabはまだ正常に立ち上がった場合は、helm upgrade コマンドに--force フラグを追加することで、エラーを無視してリリースのアップデートを試みることができます。

そうでない場合、以前GitLab Chartのデプロイが成功した後にこのエラーが表示されたのであれば、バグに遭遇していることになります。私たちのissue tracker にイシューを登録してください。また、CI サーバーをこの問題から回復させたissue #630もご覧ください。

エラー: このコマンドには2つの引数が必要です: リリース名、チャートパス

このようなエラーは、helm upgrade を実行し、パラメータにスペースがある場合に発生する可能性があります。次の例では、Test Username が原因です：

helm upgrade gitlab gitlab/gitlab --timeout 600s --set global.email.display_name=Test Username ...

この問題を解決するには、パラメータを一重引用符で囲んでください：

helm upgrade gitlab gitlab/gitlab --timeout 600s --set global.email.display_name='Test Username' ...

アプリケーションコンテナが常に初期化されます。

Sidekiq、Webservice、その他のRailsベースのコンテナが常に初期化中である場合、dependencies コンテナの通過を待っている可能性があります。

指定したポッドのログをdependencies コンテナ専用にチェックすると、次のような繰り返しが表示されることがあります：

Checking database connection and schema version
WARNING: This version of GitLab depends on gitlab-shell 8.7.1, ...
Database Schema
Current version: 0
Codebase version: 20190301182457

これはmigrations ジョブがまだ完了していないことを示しています。このジョブの目的は、データベースがシードされ、関連するすべてのマイグレーションが配置されていることを確認することです。アプリケーションコンテナは、データベースが予想されるデータベースバージョン以上になるのを待とうとしています。これは、スキーマがコードベースの期待に合わないためにアプリケーションが誤動作しないようにするためです。

  1. migrations ジョブを検索してください。kubectl get job -lapp=migrations
  2. ジョブが実行しているポッドを探します。kubectl get pod -ljob-name=<job-name>
  3. STATUS の列をチェックしながら出力を調べてください。

STATUS がRunning の場合は続行します。STATUS がCompletedの場合は、次のチェックが通ったらすぐにアプリケーションコンテナを開始します。

このポッドのログを調べます。kubectl logs <pod-name>

このジョブの実行中に失敗した場合は、アドレスに対処しなければなりません。これらは解決するまでアプリケーションの使用をブロックします。考えられる問題は次のとおりです：

  • 設定された PostgreSQL データベースに到達できないか、認証に失敗しました。
  • 設定された Redis サービスに到達できないか、認証に失敗しました。
  • Gitalyインスタンスへの到達失敗

設定変更の適用

次のコマンドは、gitlab.yaml に加えられたアップデートを適用するために必要なオペレーションを実行します：

helm upgrade <release name> <chart path> -f gitlab.yaml

含まれる GitLab Runner の登録に失敗しました。

GitLabでRunnerの登録トークンが変更された場合に起こることがあります。(これはバックアップを復元した後によく起こります)

  1. GitLab インストールのadmin/runners ウェブページにある新しい共有 Runner トークンを見つけてください。

  2. Kubernetesに保存されている既存のランナートークンの名前を探します。

    kubectl get secrets | grep gitlab-runner-secret

  3. 既存のシークレットを削除

    kubectl delete secret <runner-secret-name>

  4. 2つのキーで新しいシークレットを作成します。(runner-registration-token に共有トークン、runner-token に空のキー)

    kubectl create secret generic <runner-secret-name> --from-literal=runner-registration-token=<new-shared-runner-token> --from-literal=runner-token=""

リダイレクトが多すぎる

NGINX Ingressの前にTLSターミネーションがあり、設定にtls-secretsが指定されている場合に発生する可能性があります。

  1. 値を更新してglobal.ingress.annotations."nginx.ingress.kubernetes.io/ssl-redirect": "false"

    値ファイルを介して

    # values.yaml
global:
  ingress:
    annotations:
      "nginx.ingress.kubernetes.io/ssl-redirect": "false"

    Helm CLI経由：

    helm ... --set-string global.ingress.annotations."nginx.ingress.kubernetes.io/ssl-redirect"=false

  2. 変更を適用します。

note
SSL終了のために外部サービスを使用する場合、そのサービスはhttpsへのリダイレクトに責任を負います（必要な場合）。

アップグレードが不変フィールドエラーで失敗します。

spec.clusterIP

これらのChartの3.0.0リリース以前は、spec.clusterIP プロパティが、実際の値("")がないにもかかわらず、いくつかのServicesに入力されていました。これはバグであり、Helm 3のプロパティの3方向マージで問題が発生します。

チャートがHelm 3でデプロイされると、さまざまなサービスからclusterIP プロパティを収集し、それらをHelmに提供された値に入力するか、影響を受けるサービスをKubernetesから削除しない限り、_アップグレードのパスは_ありません。

このChartの3.0.0リリースではこのエラーが修正されましたが、手動での修正が必要です。

これは、影響を受けるサービスをすべて削除するだけで解決できます。

  1. 影響を受けるサービスをすべて削除してください：

    kubectl delete services -lrelease=RELEASE_NAME
  2. Helm経由でアップグレードを実行します。
  3. 今後のアップグレードではこのエラーは発生しません。
note
これにより、NGINX Ingress のLoadBalancer の動的な値が使用されている場合は、この Chart から変更されます。externalIP に関する詳細は、Ingress のグローバル設定のドキュメントを参照してください。DNSレコードの更新が必要になる場合があります！

spec.selector

Sidekiqポッドは、Chartリリース3.0.0 以前にはユニークセレクタを受け取っていませんでした。この問題は

Helmを使用して3.0.0 にアップグレードすると、古いSidekiqデプロイが自動的に削除され、SidekiqDeployments 、HPAs 、Pods の名前に-v1 を追加して新しいデプロイが作成されます。

5.5.0 以降、Helmは以前のバージョンの古いSidekiqデプロイを削除し、Pods 、Deployments 、HPAs のサフィックスに-v2 を使用します。

3.0.0 をインストールする際、Sidekiqデプロイでこのエラーが発生し続ける場合は、次の手順で解決してください：

  1. Sidekiqサービスを削除します。

    kubectl delete deployment --cascade -lrelease=RELEASE_NAME,app=sidekiq

  2. Helm経由でアップグレードを実行します。

親切なデプロイで “RELEASE-NAME-cert-manager” パッチを適用できません。

CertManagerバージョン0.10 からのアップグレードでは、多くの変更点がありました。古いカスタムリソース定義をアンインストールし、Helmのトラッキングから削除してから再インストールする必要があります。

Helmチャートはデフォルトでこれを試みますが、このエラーに遭遇した場合は手動アクションを取る必要があるかもしれません。

このエラーメッセージが表示された場合、新しいカスタムリソース定義がデプロイに実際に適用されていることを確認するために、アップグレードには通常よりもう1ステップ必要です。

  1. 古いCertManagerデプロイメントを削除します。

    kubectl delete deployments -l app=cert-manager --cascade

  2. アップグレードを再度実行します。今度は新しいカスタムリソース定義をインストールします。

    helm upgrade --install --values - YOUR-RELEASE-NAME gitlab/gitlab < <(helm get values YOUR-RELEASE-NAME)

gitlab-kube-state-metrics にパッチを当てることはできません。

Prometheusバージョン11.16.9 から15.0.4 にアップグレードすると、kube-state-metrics デプロイメントで使用されるセレクタラベルが変更されます（デフォルトでは無効になっています）(prometheus.kubeStateMetrics.enabled=false)。

prometheus.kubeStateMetrics.enabled=true を意味するこのエラーメッセージが表示された場合、アップグレードには追加のステップが必要です：

  1. 古いkube-state-metricsデプロイを削除します。

    kubectl delete deployments.apps -l app.kubernetes.io/instance=RELEASE_NAME,app.kubernetes.io/name=kube-state-metrics --cascade=orphan

  2. Helm経由でアップグレードを実行します。

ImagePullBackOff Failed to pull image およびmanifest unknown エラー

global.gitlabVersionを使っている場合は、そのプロパティを削除することから始めてください。ChartとGitLab間のバージョンマッピングを確認し、helm コマンドに互換性のあるバージョンのgitlab/gitlab chartを指定してください。

アップグレードに失敗しました：「アップグレードに失敗しました。helm 2to3 convert

これは既知のイシューです。Helm 2 リリースを Helm 3 にマイグレーションすると、その後のアップグレードに失敗することがあります。詳しい説明と回避策はHelm v2 から Helm v3 へのマイグレーション にあります。

UPGRADE FAILED: type mismatch on mailroom：%!t(<nil>)

このようなエラーは、マップを必要とするキーに有効なマップを指定しなかった場合に発生します。

例えば、以下の設定はこのエラーを引き起こします：

gitlab:
  mailroom:

これを解決するには、以下のどちらかを行ってください：

  1. gitlab.mailroom に有効なマップを用意してください。
  2. mailroom キーを完全に削除してください。

オプションのキーでは、空のマップ ({}) が有効な値であることに注意してください。

復元失敗：ERROR: cannot drop view pg_stat_statements because extension pg_stat_statements requires it

Helmチャートインスタンスでバックアップをリストアする際に、このエラーに直面する可能性があります。回避策として以下の手順を使用してください：

  1. toolbox ポッド内部で DB コンソールを開きます：

    /srv/gitlab/bin/rails dbconsole -p

  2. 拡張機能を削除します：

    DROP EXTENSION pg_stat_statements;
  3. 復元処理を実行します。

  4. リストア完了後、DBコンソールでエクステンションを再作成します：

    CREATE EXTENSION pg_stat_statements;

pg_buffercache 拡張機能で同じイシューが発生した場合は、上記と同じ手順に従って拡張機能を削除し、再作成してください。

このエラーについての詳細はイシュー#2469をご覧ください。

バンドルされた PostgreSQL ポッドが起動しません：database files are incompatible with server

GitLab Helm chartを新しいバージョンにアップグレードした後、バンドルされているPostgreSQLポッドで以下のエラーメッセージが表示されることがあります：

gitlab-postgresql FATAL:  database files are incompatible with server
gitlab-postgresql DETAIL:  The data directory was initialized by PostgreSQL version 11, which is not compatible with this version 12.7.

このアドレスに対処するには、Helmを以前のバージョンのチャートにロールバックしてから、アップグレードガイドの手順に従ってバンドルされている PostgreSQL のバージョンをアップグレードしてください。PostgreSQL が適切にアップグレードされたら、GitLab Helm chart のアップグレードをもう一度試してください。

バンドルされている NGINX Ingress ポッドが起動に失敗します：Failed to watch *v1beta1.Ingress

Kubernetes バージョン 1.22 以降を実行している場合、バンドルされた NGINX Ingress コントローラポッドに以下のエラーメッセージが表示されることがあります：

Failed to watch *v1beta1.Ingress: failed to list *v1beta1.Ingress: the server could not find the requested resource

このアドレスに対処するには、Kubernetes のバージョンが 1.21 以上であることを確認してください。Kubernetes 1.22 以降の NGINX Ingress サポートに関する詳細は#2852を参照してください。

/api/v4/jobs/request エンドポイントでの負荷の増加

/api/* をサービシングするデプロイに対してworkhorse.keywatcher オプションがfalse に設定されている場合、このイシューに直面する可能性があります。次の手順で確認してください：

  1. /api/* を提供しているポッドのコンテナgitlab-workhorse にアクセスします：

    kubectl exec -it --container=gitlab-workhorse <gitlab_api_pod> -- /bin/bash

  2. ファイル/srv/gitlab/config/workhorse-config.toml を検査します。[redis] 設定が欠落している可能性があります：

    grep '\[redis\]' /srv/gitlab/config/workhorse-config.toml

[redis] 設定が存在しない場合、デプロイ中にworkhorse.keywatcher フラグがfalse に設定され、/api/v4/jobs/request エンドポイントに余分な負荷がかかります。これを修正するには、webservice Chart でkeywatcher を有効にしてください：

workhorse:
  keywatcher: true

Git over SSH：the remote end hung up unexpectedly

SSH経由でのGitオペレーションが断続的に失敗し、以下のエラーが発生することがありました：

fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

このエラーにはいくつかの原因が考えられます：

  • ネットワークのタイムアウト：

    Git クライアントは、オブジェクトを圧縮するときなど、接続をオープンしたままアイドル状態にしておくことがあります。HAProxy のtimeout client のような設定は、このようなアイドル状態の接続を終了させるかもしれません。

    GitLab 14.0（Chartバージョン5.0）以降では、sshd でキープアライブを設定することができます：

     gitlab:
   gitlab-shell:
     config:
       clientAliveInterval: 15

  • gitlab-shell メモリ ：

    デフォルトでは、ChartはGitLab Shellメモリの制限を設定しません。gitlab.gitlab-shell.resources.limits.memory が低く設定されすぎると、SSH経由のGitオペレーションがこれらのエラーで失敗することがあります。

    kubectl describe nodes を実行して、これがネットワーク上のタイムアウトではなくメモリ制限によるものであることを確認してください。

     System OOM encountered, victim process: gitlab-shell
 Memory cgroup out of memory: Killed process 3141592 (gitlab-shell)

YAML設定：mapping values are not allowed in this context

YAML 設定に先頭の空白が含まれている場合、以下のエラー・メッセージが表示されることがあります：

template: /var/opt/gitlab/templates/workhorse-config.toml.tpl:16:98:
  executing \"/var/opt/gitlab/templates/workhorse-config.toml.tpl\" at <data.YAML>:
    error calling YAML:
      yaml: line 2: mapping values are not allowed in this context

このアドレスに対処するには、設定に先頭のスペースがないことを確認してください。

例えば、次のように変更します：

  key1: value1
  key2: value2

…をこう変えてください：

key1: value1
key2: value2

この変更により、GitLab 14.5 (chart version 5.5.0)でMR 2218経由で追加されたgomplateによって設定が正しく入力されるようになりました。

TLS と証明書

GitLabインスタンスが非公開のTLS認証局を信頼する必要がある場合、GitLabはオブジェクトストレージ、Elasticsearch、Jira、Jenkinsのような他のサービスとのハンドシェイクに失敗する可能性があります：

error: certificate verify failed (unable to get local issuer certificate)

非公開認証局によって署名された証明書の部分的な信頼は、以下の場合に発生する可能性があります：

  • 提供された証明書が別々のファイルになっていない場合。
  • 証明書initコンテナが必要なステップをすべて実行していません。

また、GitLabはほとんどがRuby on RailsとGoで書かれており、それぞれの言語のTLSライブラリの動作は異なります。この違いは、GitLab UIではジョブログのレンダリングに失敗するが、生のジョブログは問題なくダウンロードできるといったイシューを引き起こします。

さらに、proxy_download の設定によっては、トラストストアが正しく設定されていれば、ブラウザは問題なくオブジェクトストレージにリダイレクトされます。同時に、1つ以上のGitLabコンポーネントによるTLSハンドシェイクはまだ失敗する可能性があります。

証明書トラストのセットアップとトラブルシューティング

証明書のトラブルシューティングの一環として、以下のことを確認してください：

  • 信頼する必要がある証明書ごとにシークレットを作成してください。

  • 証明書は1ファイルにつき1つだけ用意してください。

     kubectl create secret generic custom-ca --from-file=unique_name=/path/to/cert

    この例では、証明書はキー名unique_name

バンドルやチェーンを指定した場合、GitLabコンポーネントの中には動作しないものがあります。

kubectl get secrets とkubectl describe secrets/secretname でシークレットをクエリすると、Data の下に証明書のキー名が表示されます。

Chart globals のglobal.certificates.customCAs を使用して、信頼する追加の証明書を指定します。

ポッドがデプロイされると、initコンテナが証明書をマウントし、GitLabコンポーネントがそれらを使えるように設定します。initコンテナはregistry.gitlab.com/gitlab-org/build/cng/alpine-certificates 。

追加の証明書は、秘密鍵名を証明書のファイル名として使って/usr/local/share/ca-certificates のコンテナにマウントされます。

initコンテナは、/scripts/bundle-certificates （ソース）を実行します。このスクリプトでは、update-ca-certificates ：

  1. カスタム証明書を/usr/local/share/ca-certificates から/etc/ssl/certs にコピーします。
  2. バンドルca-certificates.crt をコンパイルします。

  3. 各証明書のハッシュを生成し、Railsに必要なハッシュを使ってシンボリックリンクを作成します。証明書バンドルは警告とともにスキップされます：

    WARNING: unique_name does not contain exactly one certificate or CRL: skipping

initコンテナのステータスとログをトラブルシューティングします。たとえば、証明書initコンテナのログを表示し、警告がないか確認します：

kubectl logs gitlab-webservice-default-pod -c certificates

Railsコンソールで確認します。

ツールボックスのポッドを使用して、Railsが提供した証明書を信頼しているかどうかを確認します。

  1. Railsコンソールを起動します（<namespace> をGitLabがインストールされている名前空間に置き換えてください）：

    kubectl exec -ti $(kubectl get pod -n <namespace> -lapp=toolbox -o jsonpath='{.items[0].metadata.name}') -n <namespace> -- bash
/srv/gitlab/bin/rails console

  2. Railsが認証局をチェックする場所を確認します：

    OpenSSL::X509::DEFAULT_CERT_DIR

  3. RailsコンソールでHTTPSクエリを実行します：

    ## Configure a web server to connect to:
uri = URI.parse("https://myservice.example.com")
   
require 'openssl'
require 'net/http'
Rails.logger.level = 0
OpenSSL.debug=1
http = Net::HTTP.new(uri.host, uri.port)
http.set_debug_output($stdout)
http.use_ssl = true
   
http.verify_mode = OpenSSL::SSL::VERIFY_PEER
# http.verify_mode = OpenSSL::SSL::VERIFY_NONE # TLS verification disabled
   
response = http.request(Net::HTTP::Get.new(uri.request_uri))

initコンテナのトラブルシューティング

Dockerを使用して証明書コンテナを実行します。

  1. ディレクトリ構造を設定し、証明書を入れます：

    mkdir -p etc/ssl/certs usr/local/share/ca-certificates
   
  # The secret name is: my-root-ca
  # The key name is: corporate_root
   
kubectl get secret my-root-ca -ojsonpath='{.data.corporate_root}' | \
     base64 --decode > usr/local/share/ca-certificates/corporate_root
   
  # Check the certificate is correct:
   
openssl x509 -in usr/local/share/ca-certificates/corporate_root -text -noout

  2. 正しいコンテナ・バージョンを決定します：

    kubectl get deployment -lapp=webservice -ojsonpath='{.items[0].spec.template.spec.initContainers[0].image}'

  3. etc/ssl/certs コンテンツの準備を実行するコンテナを実行：

    docker run -ti --rm \
     -v $(pwd)/etc/ssl/certs:/etc/ssl/certs \
     -v $(pwd)/usr/local/share/ca-certificates:/usr/local/share/ca-certificates \
     registry.gitlab.com/gitlab-org/build/cng/gitlab-base:v15.10.3

  4. 証明書が正しくビルドされていることを確認します：

    • etc/ssl/certs/corporate_root.pem が作成されている必要があります。
    • 証明書自体へのシンボリックリンクであるハッシュされたファイル名があるはずです (etc/ssl/certs/1234abcd.0 のような)。

    • ファイルとシンボリックリンクは、次のように表示されます：

       ls -l etc/ssl/certs/ | grep corporate_root

      使用例：

       lrwxrwxrwx   1 root root      20 Oct  7 11:34 28746b42.0 -> corporate_root.pem
 -rw-r--r--   1 root root    1948 Oct  7 11:34 corporate_root.pem

308: Permanent Redirect リダイレクトループの発生

308: Permanent Redirect ロードバランサーが暗号化されていないトラフィック(HTTP) をNGINXに送信するように設定されている場合、リダイレクトループが発生する可能性があります。NGINX はデフォルトでHTTP を308: Permanent Redirect にリダイレクトするので、「リダイレクトループ」になってしまう可能性があります。

これを解決するには、NGINX のuse-forwarded-headers 設定を有効にしてください。

nginx-controller ログおよび404 エラーに「無効な単語」エラーが表示されます。

Helmチャート6.6以降にアップグレードした後、クラスターにインストールされたアプリケーションのGitLabまたはサードパーティのドメインにアクセスしたときに404 リターンコードが表示されたり、gitlab-nginx-ingress-controller ログに “invalid word” エラーが表示されたりすることがあります：

gitlab-nginx-ingress-controller-899b7d6bf-688hr controller W1116 19:03:13.162001       7 store.go:846] skipping ingress gitlab/gitlab-minio: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-688hr controller W1116 19:03:13.465487       7 store.go:846] skipping ingress gitlab/gitlab-registry: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:12.233577       6 store.go:846] skipping ingress gitlab/gitlab-kas: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:12.536534       6 store.go:846] skipping ingress gitlab/gitlab-webservice-default: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:12.848844       6 store.go:846] skipping ingress gitlab/gitlab-webservice-default-smartcard: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:13.161640       6 store.go:846] skipping ingress gitlab/gitlab-minio: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass
gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:13.465425       6 store.go:846] skipping ingress gitlab/gitlab-registry: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass

その場合は、GitLabの値やサードパーティのIngressオブジェクトの設定スニペットをレビューしてください。nginx-ingress.controller.config.annotation-value-word-blocklist の設定を調整または変更する必要があるかもしれません。

詳しくはAnnotation value word blocklistをご覧ください。

ボリュームのマウントに時間がかかります

Kubernetesがボリュームのコンテンツの権限を再帰的に変更してポッドのsecurityContext に一致させるため、gitaly やtoolbox チャートボリュームのような大きなボリュームのマウントには時間がかかることがあります。

Kubernetes 1.23からは、securityContext.fsGroupChangePolicy をOnRootMismatch に設定することで、このイシューを軽減できます。このフラグはすべてのGitLabサブチャートでサポートされています。

例えばGitalyサブチャートの場合：

gitlab:
  gitaly:
    securityContext:
      fsGroupChangePolicy: "OnRootMismatch"

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

KubernetesのバージョンがfsGroupChangePolicy をサポートしていない場合は、securityContext の設定を変更するか完全に削除することでイシューを軽減できます。

gitlab:
  gitaly:
    securityContext:
      fsGroup: ""
      runAsUser: ""
note
例の構文では、securityContext の設定を完全に削除しています。Helmがデフォルト値とユーザーが提供した設定をマージする方法のため、securityContext: {} またはsecurityContext を設定しても動作しません。