Helm v2からHelm v3への移行
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
Helm v2は、2020年11月に正式に非推奨になりました。GitLab Helm Chartバージョン5.0(GitLab Appバージョン14.0)以降、Helm v2.xを使用したインストールとアップグレードはサポートされなくなりました。今後のGitLabのアップデートを入手するには、Helm v3に移行する必要があります。
Helm v2とHelm v3の変更点
Helm v3では、Helm v2との下位互換性のない多くの変更が導入されています。主な変更点としては、Tillerの要件の削除や、クラスタ上でのリリース情報の保存方法などが挙げられます。詳細については、Helm v3の変更点の概要とHelm v2以降のFAQをご覧ください。
アプリケーションのデプロイに使用するHelm Chartは、新しいバージョンのHelmと互換性がない可能性があります。複数のアプリケーションがHelm v2でデプロイおよび管理されている場合は、それらも変換する場合は、Helm v3と互換性があるかどうかを確認する必要があります。GitLab Helm Chartは、GitLab Helm Chartのバージョンv3.0.0以降、Helm v3.0.2以上をサポートしています。Helm v2はサポートされなくなりました。
現在実行中のアプリケーションの観点からは、Helm v2からv3への移行を実行しても何も変更されません。一般的に、Helm v2からv3への移行を実行しても非常に安全ですが、念のため、Helm v2のバックアップを作成してください。
Helm v2からHelm v3への移行方法
Helm 2to3プラグインを使用して、GitLabのリリースをHelm v2からHelm v3に移行できます。この移行プラグインに関するいくつかの例を含むより詳細な説明については、Helmのブログ記事を参照してください: Helm v2からHelm v3への移行方法。
複数の人がGitLab Helmのインストールを管理している場合は、各ローカルマシンでhelm3 2to3 move configを実行する必要がある場合があります。helm3 2to3 convertは1回だけ実行する必要があります。
既知の問題
移行後に「UPGRADE FAILED: cannot patch」エラーが表示される
移行後、その後のアップグレードが失敗する可能性があり、次のようなエラーが表示されます:
Error: UPGRADE FAILED: cannot patch "..." with kind Deployment: Deployment.apps "..." is invalid: spec.selector:
Invalid value: v1.LabelSelector{...}: field is immutableまたは
Error: UPGRADE FAILED: cannot patch "..." with kind StatefulSet: StatefulSet.apps "..." is invalid:
spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbiddenこれは、Cert ManagerとRedisの依存関係におけるHelm 2から3への移行に関する既知の問題が原因です。一言で言えば、一部のDeploymentsおよびStatefulSetsのheritageラベルはイミュータブルであり、Tiller(Helm 2によって設定)からHelm(Helm 3によって設定)に変更できません。そのため、_強制的に_置き換える必要があります。
これを回避するには、次の手順を使用します:
これらの手順は、特にRedis StatefulSetなど、リソースを強制的に置き換えます。このStatefulSetにアタッチされたデータボリュームが安全で、そのまま残っていることを確認する必要があります。
- cert-manager Deploymentsを置き換えます(有効になっている場合)。
kubectl get deployments -l app=cert-manager -o yaml | sed "s/Tiller/Helm/g" | kubectl replace --force=true -f -
kubectl get deployments -l app=cainjector -o yaml | sed "s/Tiller/Helm/g" | kubectl replace --force=true -f -- (オプション)Redis StatefulSetによって要求されるPV上の
persistentVolumeReclaimPolicyをRetainに設定します。これは、PVが誤って削除されないようにするためです。
kubectl patch pv <PV-NAME> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'- 既存のRedis PVCの
heritageラベルをHelmに設定します。
kubectl label pvc -l app=redis --overwrite heritage=Helm- Redis StatefulSetをカスケードなしで置き換えます。
kubectl get statefulsets.apps -l app=redis -o yaml | sed "s/Tiller/Helm/g" | kubectl replace --force=true --cascade=false -f -Helmアップグレードの実行時に移行後にRBACのイシューが発生する
変換が完了した後、Helmアップグレードを実行すると、次のエラーが発生する可能性があります:
Error: UPGRADE FAILED: pre-upgrade hooks failed: warning: Hook pre-upgrade gitlab/templates/shared-secrets/rbac-config.yaml failed: roles.rbac.authorization.k8s.io "gitlab-shared-secrets" is forbidden: user "your-user-name@domain.tld" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["secrets"], Verbs:["get" "list" "create" "patch"]}Helm2は、Tillerサービスアカウントを使用して、このような操作を実行していました。Helm3はTillerを使用しなくなり、クラスタ管理者としてhelm upgradeを実行している場合でも、コマンドを実行するには、ユーザーアカウントに適切なRBACの権限が必要です。完全なRBACの権限を自分自身に付与するには、次を実行します:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=your-user-name@domain.tldその後、helm upgradeは正常に動作するはずです。