#ITスターは夢ではありません#一文でHelm 3の移行を一度に完了するように教えます
4657 ワード
2019年、KubernetesパッケージマネージャであるHelmは最新バージョンHelm 3をリリースし、このバージョンはすでにstableされている.Helm 3のいくつかの重要な特性は、以前の記事で紹介したように、いくつかの機能が多くの開発者を引きつけています.では、新しいバージョンへのアップグレード/移行が面倒かどうか知りたいと思います.Helmは複雑かもしれませんが、心配しないでください.アップグレードプロセスは極めて簡単です.Helm公式ブログでは、移行プロセスに関するガイドラインが提供されています.詳細は、次のとおりです.https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/この公式ガイドは、バージョンをHelm 3にそれぞれ移行するために準備する必要があることを直感的に示しています.しかし、一度に移行を完了したい場合はどうすればいいですか?Tillerを削除する前にコンポーネントが使用されていないことを確認するにはどうすればいいですか?
Helm 3バイナリファイルのダウンロード
Helm 2と最新バージョンをテストするので、Helm 2が完全にアンインストールされる前に、2つのバージョンのバイナリファイルを用意する必要があります.最新のStableバージョンのバイナリファイルをダウンロードし、PATHに追加します.既存のv 2バイナリファイルの名前をhelm 2に変更し、最新バージョンの名前をhelm 3に変更します.2つのバージョンを
CIスクリプトとChartの準備
アップグレードプロセスを実行する前に、CIスクリプトとカスタムChartがHelm 3と互換性があるかどうかを確認する必要があります.私は前に文章を書いたことがあります.https://itnext.io/breaking-changes-in-helm-3-and-how-to-fix-them-39fea23e06ff)、文章には注意すべきことが含まれており、そのほとんどが簡単に解決できます.OpenAPIの検証メカニズムは興味深いが、手が回らない可能性が高い.
これらの面倒な問題をすべて解決すれば、Helm 3に移行することができます.
Helm構成の移行
冒頭のHelmブログの記事では、Helm 3が使用できるようにすべてのローカル構成を更新する手順を詳しく説明しています.
https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/#migrate-helm-v2-configuration
Jenkins、TeamCity、TravisCIなどのCIシステムの構築エージェントでHelmを実行する場合は、この手順を実行します.ローカルマシンまたは永続ファイルシステムのある中央サーバでHelmを実行する場合は、特に独自のHelm repoを持っている場合やカスタムプラグインを使用している場合は、構成全体で移行する必要があります.いずれにしても、この部分を通読して、あなたと関係があるかどうかを確認してください.
バージョンの移行(Tillerの保持)
現在、移行を実現する方法はいくつかあります.特定のバージョンをHelm 3に移行してテストを行うことができます.具体的な操作はHelmの公式ブログで見つけることができます.また、多くのバージョンを移行してTillerからすべて削除することもできます.個人的には、すべてのバージョンを一度に既定の環境に移行するのは簡単ですが、私たちの環境でHelm 2を使用する場所がないと判断するまで、パブリケーションデータをTillerに保持する必要があります.これにより、ブラインドポイントは発生せず、すべてのものが同じバージョンのHelmを使用します.
満足したら、
注意:私が述べたように、ここには
Tillerを除去する前に...
この一歩は私が最も省略したくない一歩で、万が一に備えてHelm 2に戻る必要があります.この場合、CIシステムとチームメンバーがHelm 3を使用している限り、Tillerを保持する理由はありません.しかし、コンポーネントがまだ古いバージョンを使用していないことを完全に確認したい場合は、Tillerを数時間保持し、helmlsの出力結果を観察して
バージョンをHelm 3に移行した後、Helm 2によって変更された場合は、関連するリソースを削除せずに、バージョン情報が保存されているHelm 3 Kubernetes secretを削除する必要があります.
Helm 3を使用して
誰がまだHelm 2を使用しているかを明らかにした後、移行プロセスを再実行することができます.この問題を解決したら、
Tillerとそれに関連するRBACロールとデータを完全に削除できると判断したら、
移行バージョン-TillerのないHelm
Helm 3バイナリファイルのダウンロード
Helm 2と最新バージョンをテストするので、Helm 2が完全にアンインストールされる前に、2つのバージョンのバイナリファイルを用意する必要があります.最新のStableバージョンのバイナリファイルをダウンロードし、PATHに追加します.既存のv 2バイナリファイルの名前をhelm 2に変更し、最新バージョンの名前をhelm 3に変更します.2つのバージョンを
/usr/local/binに保存して、いつでも切り替えることができます.➜ helm2 version
Client: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
➜ helm3 version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}CIスクリプトとChartの準備
アップグレードプロセスを実行する前に、CIスクリプトとカスタムChartがHelm 3と互換性があるかどうかを確認する必要があります.私は前に文章を書いたことがあります.https://itnext.io/breaking-changes-in-helm-3-and-how-to-fix-them-39fea23e06ff)、文章には注意すべきことが含まれており、そのほとんどが簡単に解決できます.OpenAPIの検証メカニズムは興味深いが、手が回らない可能性が高い.
➜ helm install prometheus .
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(Deployment.spec.template.spec.containers\[0\].volumeMounts\[0\]): unknown field "defaultMode" in io.k8s.api.core.v1.VolumeMountこれらの面倒な問題をすべて解決すれば、Helm 3に移行することができます.
Helm構成の移行
冒頭のHelmブログの記事では、Helm 3が使用できるようにすべてのローカル構成を更新する手順を詳しく説明しています.
https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/#migrate-helm-v2-configuration
Jenkins、TeamCity、TravisCIなどのCIシステムの構築エージェントでHelmを実行する場合は、この手順を実行します.ローカルマシンまたは永続ファイルシステムのある中央サーバでHelmを実行する場合は、特に独自のHelm repoを持っている場合やカスタムプラグインを使用している場合は、構成全体で移行する必要があります.いずれにしても、この部分を通読して、あなたと関係があるかどうかを確認してください.
バージョンの移行(Tillerの保持)
現在、移行を実現する方法はいくつかあります.特定のバージョンをHelm 3に移行してテストを行うことができます.具体的な操作はHelmの公式ブログで見つけることができます.また、多くのバージョンを移行してTillerからすべて削除することもできます.個人的には、すべてのバージョンを一度に既定の環境に移行するのは簡単ですが、私たちの環境でHelm 2を使用する場所がないと判断するまで、パブリケーションデータをTillerに保持する必要があります.これにより、ブラインドポイントは発生せず、すべてのものが同じバージョンのHelmを使用します.
# List Helm 2 Releases
# omit --tls flag if you're not using TLS
RELEASES=$(helm list --tls -aq)
# Loop through releases and, for each one, test conversion
while IFS= read -r release; do
helm3 2to3 convert $release --dry-run
done <<< "$RELEASES"満足したら、
--dry-runフラグを削除し、2to3プラグインの役割を静観することができます. 注意:私が述べたように、ここには
--delete-v2-releasesのフラグがあります.これはバージョンを移行し、Tillerから削除します.自分がもう情報を必要としないと確信したら、この操作を実行して、リスクを負担することができます. Tillerを除去する前に...
この一歩は私が最も省略したくない一歩で、万が一に備えてHelm 2に戻る必要があります.この場合、CIシステムとチームメンバーがHelm 3を使用している限り、Tillerを保持する理由はありません.しかし、コンポーネントがまだ古いバージョンを使用していないことを完全に確認したい場合は、Tillerを数時間保持し、helmlsの出力結果を観察して
UPDATEDcolumnのタイムスタンプが完全に変更されているかどうかを確認することをお勧めします.変更されると、Helm 3を使用していないコンポーネントがある/あることを意味します. バージョンをHelm 3に移行した後、Helm 2によって変更された場合は、関連するリソースを削除せずに、バージョン情報が保存されているHelm 3 Kubernetes secretを削除する必要があります.
➜ kubectl get secret -n dev
NAMESPACE NAME TYPE DATA AGE dev sh.helm.release.v1.postgres.v1 helm.sh/release.v1 1 36d
➜ kubectl delete secret -n dev sh.helm.release.v1.postgres.v1
secret "secret "sh.helm.release.v1.postgres.v1" deletedHelm 3を使用して
devネーミングスペースにリストされているバージョンを使用すると、それらのバージョンはもう存在しません.NAME NAMESPACE REVISION UPDATED
STATUS CHART APP VERSION誰がまだHelm 2を使用しているかを明らかにした後、移行プロセスを再実行することができます.この問題を解決したら、
helm3 2to3 convertを使用して移行してください.Tillerとそれに関連するRBACロールとデータを完全に削除できると判断したら、
helm 2to3 cleanupを実行できます. 移行バージョン-TillerのないHelm
--tiller-out-clusterフラグを以前に提供したスクリプトに直接追加し、2to3プラグインはローカルTillerインスタンスからバージョン情報を削除します. # List Helm 2 Releases
# omit --tls flag if you're not using TLS
RELEASES=$(helm list --tls -aq)
# Loop through releases and, for each one, test conversion
while IFS= read -r release; do
helm3 2to3 convert $release --tiller-out-cluster
done <<< "$RELEASES"