ゼロバンク・デザインファクトリー株式会社(ZDF)のSRE張です、kubernetesのスペシャリストとして日々GKEの世話をしています、出会った問題や経験を共有したいと思い、この記事を書くとこになりました。
背景
SRE、インフラエンジニアの皆さん、kubernetesクラスタのバージョンアップをどうされているでしょうか？
毎回たくさんの変更内容があってリリースノートを読むのが大変でしたね、また1年に何度もアップデートがあり、常にアップデート準備中かどこかのクラスターがアップデート中の状態で運用も大変でしたね。
その声はコミュニティ側もちゃんと認識して色々改善が行われております。例えばアップデートの頻度は年4回から3回に減りました。
昨日Kubernetes v1.28: Planternetes がリリースされまして、今回その辺の改善が行われましたので、その詳細を展開して説明していきたいと思います。
P.S. Kubernetesはバージョンことにコードネームとアイコンが用意されて可愛いですね。
説明
Kubernetesクラスタはコントロールプレーンとノードのアーキテクチャが分離しているため、クラスタをデプロイする際には通常、同じバージョンのコントロールプレーンと同じバージョンのノードをデプロイすることを選択します。しかし、クラスタのバージョンをアップデートしたい場合、アップデートの過程でコントロールプレーンとノードが同じバージョンを維持できないことがわかります。
例えば
現在運用中のv1.25のKubernetesクラスタをv1.26にアップデートしようとします。
コントロールプレーンを先にv1.26にアップデートします。 その時ノードはまだv1.25のままです。コントロールプレーンのアップデートが完了後ノードをv1.26にアップデートし、最終的に両方ともv1.26になります。このアップデートプロセスの間、しばらくの間、コントロールプレーンとノードが同じバージョンではありません。
一般的に言えば、このような分散アーキテクチャを持つほとんどのソフトウェアでは、バージョンの不一致が問題になる可能性が高いです。しかし、上記のアップデートプロセスによるバージョン不一致は不可避なので、Kubernetesはこの点に関して互換性を持たせるように対処し、このポリシーをKubernetesのVersion Skew ポリシーと呼びます。
Kubernetesでは、コントロールプレーンのバージョンとノードのバージョンの間にn-2のずれが許容されます。 例えば
コントロールプレーンのバージョンがv1.26の場合、ノードバージョンはv1.26、v1.25、v1.24のバージョンの運用がサポートされてます。v1.28以降は、このVersion Skewポリシーがn-3まで拡張されます。
コントロールプレーンのバージョンがv1.28の場合、ノードバージョンはv1.28、v1.27、v1.26、v1.25がサポートされます。
このVersion Skewポリシーについて説明した後、これがどれほど重要な改善なのかを見てみましょう。
コントロールプレーンと比べて、ノードのアップデートはノード上で動作していたPodを再スケジュール／再構築する必要があり、負荷が大きいため、できるだけその回数を減らしたいです。
Kubernetesの現在のリリース＆サポートポリシーでは1年間サポートなので、最低限でいうと1年に1回のノードアップデートが必要です。
しかしコントロールプレーンが1年に3回バージョンアップされ、ノードとの差が2バージョンしか許容されないとすると1年以内に1回（2年で3回）ノードをアップデートしなければなりません。
例えば、
2023~24のkubernetesアップデートのシナリオ(仮の時期実際の発表時期と異なる)は以下になります(v1.24 => v1.27)
| 時期 | コントロールブレーン | ノード | アップデート作業 |
|---|---|---|---|
| 年度初 | v1.24 | v1.24 | |
| 4月 | v1.25 | v1.24 | コントロールプレーンアップデート v1.24 => v1.25 |
| 6月 | v1.26 | v1.24 | コントロールプレーンアップデート v1.25 => v1.26 |
| 8月 | v1.26 | v1.26 | ノードアップデート v1.24 => v1.26 |
| 10月 | v1.27 | v1.26 | コントロールプレーンアップデート v1.26 => v1.27 |
| 12月 | v1.27 | v1.27 | ノードアップデート v1.25 => v1.27 |
ノードは2回アップデートする必要があります。
実際、Kubernetesクラスタのメンテナンス中、ノードのバージョンをアップデートすることによる影響は大きく、これらのノード上で動作していたPodを再スケジュール／再構築する必要があり、理想的には業務に影響を与えないように工夫する必要があります（が、厳密には影響がでる...）。さらに、クラスタサイズが大きくなると、このノードのアップデートの作業負荷も非常に大きくなります。
新しいn-3ポリシーが適用場合、その効果を見てみましょう：
| 時期 | コントロールブレーン | ノード | アップデート作業 |
|---|---|---|---|
| 年度初 | v1.24 | v1.24 | |
| 4月 | v1.25 | v1.24 | コントロールプレーンアップデート v1.24 => v1.25 |
| 6月 | v1.26 | v1.24 | コントロールプレーンアップデート v1.25 => v1.26 |
| 10月 | v1.27 | v1.24 | コントロールプレーンアップデート v1.26 => v1.27 |
| 12月 | v1.27 | v1.27 | ノードアップデート v1.24 => v1.27 |
このように、ノードのアップグレードは1回で済むため、作業量が大幅に削減され、ビジネスへの影響も軽減されるのは明らかです。
注意してほしいのはn-3ポリシーが初めてサポートされるのはkubernetes v1.28で、コントロールブレーンv1.28とノードv1.25の運用がサポートされます。
各コンポーネントの詳しいVersion Skew ポリシーはこちらのドキュメント参考してください。