Helm Chartのバージョンアップにどう取り組むか

こんにちは永倉です。今回の投稿はFLINTERSブログ祭りの記事です。テーマは #Kubernetes #Helmです。

HelmというKubernetsのパッケージマネージャーがあります。 HelmではChartの単位でKubernetesへのアプリケーションのインストールや更新を行います。アプリケーションのライブラリのバージョンアップについての重要さはよく言われているのと同様に、Helm Chartのバージョンアップも重要です。

特に公式やコミュニティが提供するHelm Chartを使ってインストールするアプリケーションにはKubernetes Cluster全体に影響を与えるようなものも少なくありません。時間が経てば経つほどバージョンアップは難しくなってくるため、できるだけバージョンアップに追従できると良いでしょう。

本記事では、公式やコミュニティが提供するHelm Chartなど、自分達では管理していないHelm Chartのバージョンアップにどう取り組むのかを書いています。

Helm Chartのバージョンアップに気づく

Helm Chartのバージョンアップを適切なタイミングで行うためには、まずHelm Chartのバージョンアップがあったことに気づく必要があります。どういった方法で気づくのかは例えば以下のような方法があります。

Helm Chartが置かれているGitHubやGitLabのリポジトリ、Artifact HubなどHelm Chartのバージョンアップが知れる場所を定期的にチェックする
Renovateを使いHelm Chartのバージョンアップがあったら自動的にHelm Chartのバージョンを更新したPull Requestを作成する
Novaを使い最新のHelm Chartバージョンを検知する

Helm Chartのバージョンアップによる影響を調査する

バージョンアップが検知できたら、次はその影響を調査します。大まかには対象のHelm ChartのChangelogやリリースノートを探します。変更内容によってはIssueやPull Request,コミット等から影響がないかを調べることもあります。

Helm ChartごとにどこにChangelogやリリースノートがあるのかはまちまちです。いくつかのHelm Chartで例を挙げてみます。

DatadogのHelm Chart
Chartのディレクトリ内にCHANGELOG.mdファイルがあり、ここに変更内容が書かれています。
ingress-nginxのHelm Chart
Chartのディレクトリ内にchangelogディレクトリがあり、Chartのバージョンごとに変更内容が書かれたファイルがあります。
kube-state-metricsのHelm Chart
GitHubのリリースノート(例としてバージョン5.20.0のもの)に変更内容が書かれています。
metrics-serverのHelm Chart
Chartのディレクトリ内にCHNAGELOG.mdファイルがあり、ここに変更内容が書かれています。また、Artifact Hubのページからも変更内容が確認できます。

このように、Helm Chartによってどこから情報を得られるのかは変わってくるので、どこを調べれば良いのかというのをHelm Chartごとにまとめておくと良いと思います。

Renovateを使いHelm Chartのバージョンを更新したPull Requestを作成する場合には、renovateのprBodyNotesの設定を使い、どこで変更内容を確認すると良いかをPull Requestの説明に書いておくといった方法も取れるでしょう。

どんな点に注目してHelm Chartのバージョンアップの影響を調べるか

Helm Chartのバージョンが上がることによる変更には大きく3つあると思っています。主にこの3つの点に注目して影響を調べます。バージョンを上げるとこれら全ての変更が一緒に起こる場合もあります。

Chart.yamlのappVersionの変更
Helm Chartを通じてインストールされるアプリケーションのバージョンが変わる可能性があります。Helm Chartと合わせて、アプリケーションのChangelogやリリースノートを確認します。
values.yamlファイルの内容の変更
インストールされるアプリケーションのバージョンや設定が変更される可能性があります。生成されるKubernetesのmanifestが変わる可能性もあります。
templates directory の中のファイルの変更
生成されるKubernetesのmanifestが変わる可能性があります。インストールされるアプリケーションの設定が変更される可能性もあります。

ツールの活用

さすがにバージョンアップによる影響をすべて人の目で確認することは難しいです。ツールを使って影響がないかを調べるのも効果的です。ここではいくつかアイデアを紹介します。

helmのtemplateやlintコマンドを使いバージョンアップ後のHelm ChartでKubernetes manifestが生成できるかどうかを確認する
helm-diffプラグインを使いバージョンアップ前後に予期せぬ差分が発生していないかを確認する
kubeconformを使い生成されるKubernetes manifestの検証をする
plutoを使い生成されるKubernetes manifestフェスト内で現在のKubernetesのバージョンではサポートされていないAPIバージョンを使っていないかを検証する

バージョンアップの判断

影響調査の結果を踏まえ、バージョンアップの判断をします。大体以下のような判断のパターンがあるでしょう。

Helm Chartのバージョンを上げてリリースする
Helm Chartのバージョンは上げてリリースする
合わせてインストールする際に渡しているvaluesを変更し、Helm Chartのバージョンアップによる変更へ追従する
Helm Chartのバージョンを上げるのを後回しにする
バージョンアップしたいHelm Chart以外の箇所で変更が必要な場合などすぐにバージョンを上げることが難しい場合もあります

実際にどうやっているか

私が所属しているチームでの取り組みを紹介します。

RenovateによってHelm Chartのバージョンアップを検知し、バージョンアップ用のPull Requestを自動的に作成する。
そのPull Requestに対してCI上でhelmコマンドやkubeconform等を使いバージョンアップの影響がないかをチェックする。
CIの実行結果とChangelog、リリースノート等の変更内容を確認してバージョンアップするかどうかを判断する。

残念ながら上に書かれているのはある種理想的な流れで、必ずしも最新のHelm Chartへバージョンアップが行えない時もあります。
例えば、Helm Chartのバージョンアップの前に、対象のHelm Chart以外の箇所でKubernetesのマニフェストを書き換える必要がある。Kubernetesのバージョンアップを先に行う必要があるということもあります。