GitLab Helmチャートインスタンスのアップグレード

GitLab Helmチャートインスタンスを、より新しいバージョンのGitLabにアップグレードします。

前提条件

GitLab Helmチャートインスタンスをアップグレードする前に:

1. アップグレードする前に必要な情報を参照してください。
2. GitLab HelmチャートのバージョンはGitLabのバージョンと同じ番号体系ではないため、必要なGitLab Helmチャートのバージョンを見つけるには、バージョンマッピングを参照してください。
3. アップグレード先の特定リリースに対応する変更履歴を参照してください。
4. 8.x以前のバージョンのGitLab Helmチャートバージョンからアップグレードする場合は、GitLabドキュメントアーカイブを参照して、ドキュメントの古いバージョンにアクセスしてください。
5. バックアップを実行します。

GitLab Helmチャートインスタンスのアップグレード

GitLab Helmチャートインスタンスをアップグレードするには:

1. ワークフローを妨げないように、アップグレード中にメンテナンスモードをオンにすることを検討して、ユーザーが書き込み操作を実行できないように制限します。

2. ターゲットのGitLabバージョンと同じバージョンにGitLab Runnerをアップグレードします。

3. 以前に提供された値を抽出します:

   helm get values gitlab > gitlab.yaml

4. アップグレード時に引き継ぐ必要のあるすべての値を決定します。明示的に設定する最小限の値のセットのみを保持し、アップグレードプロセス中にそれらを渡す必要があります。それ以外の場合は、GitLabのデフォルト値を使用する必要があります。

ダウンタイムなしでアップグレード

オフラインにせずに、ライブGitLab環境をアップグレードします。

要件

ダウンタイムなしのアップグレードプロセスには、以下が必要です:

• WebサービスとSidekiq用に複数のレプリカが設定されたマルチノードGitLab Helmチャートデプロイ。
• 一度に1つのマイナーリリースをアップグレードします。したがって、18.0から18.1へはアップグレードできますが、18.2へはアップグレードできません。リリースをスキップすると、データベースの変更が間違った順序で実行され、データベーススキーマが破損した状態になる可能性があります。

考慮事項

ダウンタイムなしのアップグレードを検討する場合は、以下に注意してください:

• Gitaly in Kubernetesはダウンタイムなしのアップグレードをサポートしていません。ダウンタイムが必要です。
• ほとんどの場合、パッチリリースが最新でない場合、パッチリリースから次のマイナーリリースに安全にアップグレードできます。たとえば、18.0.5から18.1.0へのアップグレードは、18.0.6が存在する場合でも安全です。アップグレードするバージョンのバージョン固有のアップグレードに関する注記を確認することを推奨します。
• デプロイに、ローリングアップデート中に新旧両方のポッドを同時に実行するのに十分なリソースがあることを確認してください。必要な追加リソースの量は、maxSurge設定によって異なります。たとえば、maxSurgeの場合: 10%の場合、新しいポッドで使用するために10%の追加容量が必要です。

推奨されるデプロイ設定

スムーズなローリングアップデートを保証するには、以下の設定は、アップグレードプロセスを制御し、ダウンタイムなしを達成するために必要です。

これらの設定は、ベースラインの推奨事項です。これらは、デプロイのリソース可用性、レプリカ数、およびパフォーマンス要件に基づいて調整する必要があります。アップグレード中に一時的に追加のポッドを作成するmaxSurge設定をサポートするのに十分なクラスターリソースがあることを確認してください。

global:
  extraEnv:
    BYPASS_SCHEMA_VERSION: true
gitlab:
  webservice:
    deployment:
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: "10%"
          maxUnavailable: 0
    terminationGracePeriodSeconds: 60
  sidekiq:
    deployment:
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: "10%"
          maxUnavailable: 0
    terminationGracePeriodSeconds: 600
  gitlab-shell:
    deployment:
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: "10%"
          maxUnavailable: 0
    terminationGracePeriodSeconds: 60
  registry:
    deployment:
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: "10%"
          maxUnavailable: 0
    terminationGracePeriodSeconds: 60

nginx-ingress:
  controller:
    deployment:
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: "10%"
          maxUnavailable: 0
    terminationGracePeriodSeconds: 300
    minReadySeconds: 10

これらの設定により、以下が保証されます:

• アップデート中、少なくとも1つのポッドが常に利用可能です。
• 古いポッドが終了する前に、新しいポッドが起動されます。
• ポッドには、正常にシャットダウンして接続をドレインする時間があります。
• ポッドは、準備完了と見なされる前に安定しています。

アップグレードプロセス

kubectl get deployments -lapp=webservice -n <namespace>
kubectl get deployments -lapp=sidekiq -n <namespace>

GitLabをアップグレードするには

1. デプロイメントを一時停止します:

   kubectl rollout pause deployment/gitlab-webservice-default
   kubectl rollout pause deployment/gitlab-sidekiq-all-in-1-v2

2. 新しいバージョンへのアップグレードを開始します:

   helm upgrade gitlab gitlab/gitlab \
   --version <GitLab Helm chart version> \
   -f values.yaml \
   --set gitlab.migrations.extraEnv.SKIP_POST_DEPLOYMENT_MIGRATIONS=true

3. 事前移行とアップグレードの完了を待ちます:

   kubectl get jobs -lrelease=gitlab,chart=migrations-<GitLab version> -n <namespace>
   kubectl wait --for=condition=complete job/<job name> --timeout=600s

4. Sidekiqのデプロイメントの一時停止を解除します:

   kubectl rollout resume deployment/gitlab-sidekiq-all-in-1-v2
   kubectl rollout status deployment/gitlab-sidekiq-all-in-1-v2 --timeout=15m

5. Webサービスのデプロイメントの一時停止を解除します:

   kubectl rollout resume deployment/gitlab-webservice-default
   kubectl rollout status deployment/gitlab-webservice-default --timeout=15m

6. 移行後の処理を実行します:

   helm upgrade gitlab gitlab/gitlab \
   --version <GitLab Helm chart version> \
   -f values.yaml

7. 移行後の処理が完了するまで待ちます:

   kubectl get jobs -lrelease=gitlab,chart=migrations-<GitLab version> -n <namespace>
   kubectl wait --for=condition=complete job/<job name> --timeout=600s

   デプロイによっては、移行の完了までの600sタイムアウト時間が十分でない場合があります。このタイムアウトをニーズに合わせて長くしたり、ジョブを定期的にチェックして、次の手順に進む前に完了していることを確認したりできます。

ダウンタイムありでアップグレード

1. 前の手順で抽出およびレビューした値を使用して、アップグレードを実行します:

   helm upgrade gitlab gitlab/gitlab \
   --version <new version> \
   -f gitlab.yaml \
   --set gitlab.migrations.enabled=true \
   --set ...

   メジャーデータベースのアップグレード中は、gitlab.migrations.enabledをfalseに設定する必要があります。将来のアップデートのために、明示的にtrueに戻すようにしてください。

アップグレード後

1. 有効になっている場合は、メンテナンスモードをオフにします。
2. アップグレードヘルスチェックを実行します。

関連トピック

1. Linuxパッケージインストールでのダウンタイムなしのアップグレード
2. アップグレードパス
3. GitLabアップグレードノート