LASSIC Media らしくメディア

Kubernetesを本番環境で使い始めると、避けて通れないのが定期的なバージョンアップです。Kubernetesは新しい版が年に3回ほど公開され、各版のサポート期間はおおよそ14か月と短めです。放っておくとサポートの切れた版のまま動かし続けることになり、既知の不具合や脆弱性への修正が受けられなくなります。だからこそ、一度きりの移行ではなく「回り続ける更新運用」として捉える姿勢が欠かせません。

とはいえ、この更新運用は「Kubernetesへの移行（導入）」や「コスト最適化」、あるいは「SREによる信頼性運用」と、しばしば同じ話にまとめられがちです。担う中身は別物で、混同したまま体制を組むと更新がずるずると先送りになります。本記事では、自社でKubernetesを運用する情報システム部門やSREの担当者に向けて、バージョンアップ運用の位置づけ・やること・つまずきやすい難所・外注の勘所を整理していきます。

Kubernetesのバージョンアップ運用とは——移行・コスト最適化との違い

Kubernetesのバージョンアップ運用とは、すでに稼働しているクラスタを、新しい版へ計画的に上げ続ける運用を指します。導入して終わりではなく、公開される新しい版に合わせて、決まった周期で更新をかけ続けるのが特徴です。似た文脈で語られる3つの取り組みと並べると、担う役割の違いがはっきりします。

コンテナ化・Kubernetes移行の開発は、既存のアプリをコンテナにして初めてKubernetesへ載せる、いわば一度きりの導入プロジェクトです。Kubernetes・コンテナのコスト最適化は、使うリソースの量を見直して費用を下げる取り組みで、更新とは目的が異なります。そしてSREによる運用は、監視やSLO、障害対応といった信頼性全般を受け持ちます。これらに対してバージョンアップ運用は、「動かし続けるために版を上げ続ける」という一点に絞られた作業です。

導入（移行）でも、コスト調整でも、信頼性全般でもなく、周期的にやってくる版の更新をさばく——ここに違いがあります。自社がKubernetesまわりの何に困っているのか、載せ替えなのか、費用なのか、信頼性なのか、それとも更新の回し方なのかを見極めておくと、体制や依頼の範囲を絞り込みやすくなります。

なぜ定期的なバージョンアップが避けられないのか

Kubernetesは、おおよそ年に3回のペースで新しい版が公開されます。そして各版のサポート期間は約14か月で、他のソフトウェアと比べると短いほうです。サポートが切れた版を使い続けると、新たに見つかった不具合や脆弱性への修正が届かなくなり、リスクを抱えたまま運用することになります。

やっかいなのは、更新を溜め込むと不利になりやすい点です。Kubernetesはひと版ずつ順に上げていくのが基本で、いくつもの版を一気に飛び越える上げ方は想定されていません。更新を後回しにするほど、追いつくために連続して版を上げる作業が必要になり、そのあいだに廃止された機能も積み重なっていくのが実情です。期限に追われてまとめて上げるより、周期を決めて少しずつ上げ続けるほうが、結果として負担は軽くなります。

クラウド各社のマネージドサービス（Amazon EKS・Azure AKS・Google GKEなど）を使えば、クラスタの管理側（コントロールプレーン）の更新は任せやすくなります。ただ、その場合でも古い版を使い続ければ追加費用がかかったり、いずれ強制的に上げられたりすることがあります。何より、アプリのマニフェストが古いAPIを使っていないか、周辺のアドオンが新しい版に対応しているかといった確認は、利用者側に残る仕事です。「マネージドだから何もしなくてよい」とは言い切れないのです。

バージョンアップ運用でやること

バージョンアップ運用は、行き当たりばったりで進めると事故につながります。おおまかには次のような工程を、版が上がるたびに繰り返します。自社でどこまで回せているかと照らし合わせてみてください。

まず、上げる先の版で何が変わるのかを調べます（影響調査）。廃止・非推奨になったAPIを自社のマニフェストやHelmチャート、自作のコントローラが使っていないか、そして周辺のアドオンが対応版を出しているかを洗い出す工程です。次に、本番と同じ構成の検証環境で先に試し、問題が出ないかを確かめます。そのうえで、管理側であるコントロールプレーンをひと版だけ上げ、続いて処理を担うノードを順に入れ替えていきます。ノードの入れ替えでは、動いているアプリをいったん別のノードへ退避（drain）させ、止めずに差し替えるのが定石です。最後に動作を確認し、記録を残します。想定と違う挙動があれば切り戻し、気づいた点は次回の手順に反映します。この一連の流れを図にすると次のとおりです。

つまずきやすい難所

バージョンアップ運用を回すうえで、あらかじめ想定しておきたい難所がいくつかあります。着手前に押さえておくと、更新のたびに慌てずに済みます。

一つ目は、非推奨・廃止されたAPIへの対応です。古い書き方のマニフェストや、しばらく更新していないHelmチャートが、新しい版で動かなくなることがあります。二つ目は、周辺のアドオンやツールの互換です。Ingressコントローラ、ネットワーク（CNI）、ストレージ連携（CSI）、証明書管理、サービスメッシュなど、クラスタの上で動く部品も、それぞれ版に追随させる必要があります。どれか一つが未対応だと、更新の足が止まります。三つ目は、データベースのような状態を持つワークロードの扱いです。ノードを入れ替える際、状態を持つ処理はただ移せばよいわけではなく、退避のさせ方に気を配る必要があります。四つ目は、コンポーネント間で許容される版差（スキューポリシー）の範囲を外さないよう、上げる順序を守ることです。これらは、更新を溜めるほど絡み合って難しくなります。だからこそ、周期的にこまめに回す運用が現実的なのです。

進め方の選択肢——インプレースとクラスタ入れ替え

バージョンアップの進め方は、大きく二つに分けられます。同じクラスタをその場で上げる「インプレース更新」と、新しい版のクラスタを別に立てて移す「クラスタ入れ替え（ブルーグリーン）」です。加えて、マネージドサービスの自動更新をどこまで頼るかという判断も絡みます。それぞれの向き不向きを整理しました。

どれか一つが正解というわけではありません。基盤の規模や、止められない度合い、いまどれだけ版が遅れているかによって、組み合わせて選ぶのが現実的です。遅れが大きいクラスタは思い切って入れ替え、以降はこまめなインプレース更新で維持する、といった使い分けもよくとられます。

外注時に確認しておきたい点

バージョンアップ運用を外部に委託する場合は、次の点を事前にすり合わせておくと、認識のずれを防ぎやすくなります。まず、対象のクラスタと、いまの版がどれだけ遅れているかという現状です。遅れ具合によって、最初にやるべきことが変わってきます。次に、どこまでを任せるか。影響調査だけなのか、検証や本番での実施まで含めるのか、あるいは毎回の更新を定例業務として回してもらうのかで、契約の形が変わります。

さらに、更新をかける頻度と、作業を行う時間帯（メンテナンスの窓）、問題が起きたときの切り戻しの手順と判断の分担も、あらかじめ決めておきたいところです。そして忘れずに確認したいのが、手順書の整備と引き継ぎです。バージョンアップ運用は続いていく仕事なので、いずれ内製に戻せるように記録を残してもらえるかどうかは、後々の助けになります。開発や移行までを切り出すのか、更新の定例運用まで含めて依頼するのかを明確にしておくと、任せたあとのつまずきを抑えやすくなります。

まとめ：バージョンアップ運用で押さえる3つの視点

Kubernetesのバージョンアップ運用は、一度きりの移行（導入）や、費用を見直すコスト最適化、信頼性全般を担うSRE運用とは役割の異なる、「版を上げ続ける」ための取り組みです。検討するうえで押さえたい視点は3つに整理できます。第一に、移行・コスト最適化・SRE運用・バージョンアップ運用を切り分け、自社がいま困っているのがどれなのかを見極めること。第二に、年3回ほどの新版とサポート約14か月という周期を前提に、期限に追われる前に定期的に上げる段取りを組むこと。第三に、非推奨APIやアドオンの互換といった難所を想定し、影響調査と検証を挟んでから本番に反映する流れを守ることです。この3点を踏まえておけば、「気づいたら何版も遅れていて、一気に上げられない」という手詰まりを避けやすくなります。自社だけで周期を回しきるのが難しいと感じたら、更新の定例運用から外部の手を借りるのも一つの選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Kubernetes公式ドキュメント「Releases／Version Skew Policy」（https://kubernetes.io/releases/）

Tweet