1. 事の起こり — 「パッチだから安全」のはずのK3sアップグレード
Kubernetesの運用で染み付いた感覚がある。「マイナーバージョンのアップグレードは慎重に。でもパッチバージョンなら、バグ修正とセキュリティパッチが入るだけだから、さっさと当てておけばいい」というものだ。
K3sクラスタでcontainerdの挙動をカスタマイズしていた、あるチームの話をしよう。レジストリのミラー設定や独自のランタイムハンドラを、containerdの設定テンプレート（config.toml.tmpl）に書き込んで運用していた。ある日、パッチバージョンのK3sアップグレードを自動化パイプラインで流した。バージョン番号は1つしか変わっていない。ところが、アップグレード後に独自のcontainerd設定が反映されなくなっていることに気づく。
原因を遡ると、Kubernetes本体のマイナーバージョンは一切変わっていないのに、同梱されているcontainerdがメジャーバージョンごと切り替わっていたことが判明した。これは特定の環境固有の不具合ではなく、K3sの公式リリースノートに実際に記録されている既知の変更だ。
2. Kubernetes公式のバージョンスキューポリシーは「マイナーバージョン」の話しかしていない
まず前提を整理したい。Kubernetesには公式のバージョンスキューポリシーがあり、kubeletとkube-apiserverの間でどこまでバージョン差を許容するかが明記されている。要点は次の通りだ。
- kubeletはkube-apiserverより新しいバージョンであってはならない
- Kubernetes 1.25以降は、kubeletがkube-apiserverより最大3マイナーバージョン古くても動作する
- それより古いKubernetesでは、許容されるのは2マイナーバージョンまで
この「n-3」までの許容は、もともとKEP-3935として提案され、v1.28で安定機能として実装された経緯がある。KEPの狙いは明快で、「ノードのアップグレードはワークロードに対してより破壊的なので、その頻度を減らしたい」というものだ。コントロールプレーンだけ先に上げて、ノード側は後からまとめて追従できる余地を広げる、という発想である。
ここで重要なのは、このポリシーがカバーしているのはKubernetesコア自体のマイナーバージョン差だけだという点だ。kubeletやkube-apiserverのバージョンについては明確なルールがあるが、ディストリビューションが同梱している周辺コンポーネント（コンテナランタイム、CNI、DNS、Ingressコントローラ等）のバージョンについては、このポリシーは一言も触れていない。
3. パッチリリースでcontainerdがv1→v2に切り替わった実例
ここで、冒頭のシナリオの裏付けとなる実例を見てみよう。K3s公式のGitHubリリースによれば、v1.32.1+k3s1（2025年1月28日リリース）が同梱していたcontainerdは v1.7.23-k3s2 だった。
ところがその次のv1.32.2+k3s1（2025年2月27日リリース）では、containerdが v2.0.2-k3s2 に切り替わっている。Kubernetesのバージョン表記は v1.32.1 から v1.32.2 へと、パッチ番号が1つ進んだだけだ。にもかかわらず、公式リリースノート自身が「containerdをバージョン2.0にバンプした」「新しい設定ファイルスキーマが導入されたため、カスタム設定を使っているユーザーはテンプレートの移行が必要」と明記している。
つまりこれは不具合ではなく、K3sが公式に告知していた仕様変更だ。ただし、その告知は「Kubernetesのバージョンスキューポリシー」という読者が普段チェックしている情報源には一切現れない。リリースノートの細部を読んでいなければ、パッチ番号の見た目通り「軽微な更新」として扱ってしまうのも無理はない。
4. containerd 2.0の非互換変更 — 何が静かに壊れるのか
containerd公式ドキュメントは、2.0での主要な破壊的変更を次のように説明している。
- Docker Schema 1イメージの取得がデフォルトで無効化される（
application/vnd.docker.distribution.manifest.v1+prettyjws形式） - containerd 1.4で非推奨となっていた旧ランタイムシム（
io.containerd.runtime.v1.linuxとio.containerd.runc.v1）が完全に削除され、io.containerd.runc.v2への移行が必須になる io_uring系のシステムコールがデフォルトで許可されなくなる- CRI v1alpha2 APIやAUFSスナップショッターなど、旧来のコンポーネントが削除される
設定テンプレートの移行漏れだけでなく、古い形式のコンテナイメージを使い続けている環境や、独自のランタイムハンドラを指定している環境では、イメージの取得エラーやコンテナ起動エラーという形で影響が表面化する可能性がある点にも注意したい。
同じ理屈で、最新のK3s v1.36ラインでも同梱コンポーネントのセットはリリースのたびに更新され続けている。たとえばv1.36.5+k3s1ではcontainerd v2.3.4-k3s1.36、etcd v3.6.14-k3s3、Flannel v0.28.4、CoreDNS v1.14.7、Traefik v3.7.13、local-path-provisioner v0.0.37が同梱されている。1つのバージョン文字列の裏に、これだけの数のコンポーネントがバンドルされていることを意識しておく必要がある。
5. 安全なK3sアップグレード手順 — 公式ドキュメントが既に警告していたこと
公平を期すために言うと、K3s公式のアップグレードガイドは、はじめからリスクを織り込んだ手順を案内している。
- アップグレード計画でマイナーバージョンを飛ばさないこと（Kubernetesのバージョンスキューポリシーに準拠するため）
- サーバーノードを1台ずつアップグレードし、その後にエージェントノードをアップグレードすること
- APIサーバーの一時停止に敏感なワークロードがある場合は、事前にノードをdrain/cordonしてからアップグレードし、完了後にuncordonすること
この手順自体は正しい。問題は、この手順が守っている「スキューポリシー」と、今回のcontainerdのような同梱コンポーネントの非互換変更は、そもそも別のレイヤーの話だということだ。前者はKubernetes本体のマイナーバージョン差の話であり、後者はディストリビューションが選んだ依存関係のバージョン管理の話である。どちらか一方を守っていても、もう一方で事故は起きうる。
実際、クラスタアップグレード中にノードが応答しなくなる・不安定になるという事象は、K3sに限らず起こりうる。たとえばRed Hatのナレッジベースでも、OpenShiftのクラスタアップグレード中にkubeletの証明書や設定ファイルの不整合でノードがNotReadyに陥る事例が報告されている。原因は様々でも、「アップグレードのたびにリリースノートの隅々まで確認する」という地味な作業の重要性は変わらない。
K3sを採用する以上、リリースノートの「Urgent Upgrade Notes」や変更点セクションを、パッチバージョンであっても毎回確認する運用をルール化しておくべきだろう。CIパイプラインで自動アップグレードを組んでいるなら、なおさらこのチェックを自動化できないか検討する価値がある。
6. まとめ — "検証された組み合わせ"を自分で背負うか、任せるか
「Kubernetes標準のバージョンスキューポリシーを守っている」ことと、「K3sのパッチリリースが安全である」ことは、別の話だ。K3sはKubernetesコアだけでなく、containerd・Flannel・CoreDNS・Traefik・local-path-provisionerといった周辺コンポーネントを1つのバージョン文字列にまとめて配布する。その利便性の裏側で、パッチ番号という"見た目"だけでは判断できない非互換変更が混ざり込む余地がある。
この検証作業をすべて自前のオペレーションチームで担うのか、それとも検証済みの組み合わせとして提供してもらうのかは、運用コストに直結する判断だ。KuboはK3sベースのマネージドKubernetesとして、K3sのバージョンと同梱コンポーネントの組み合わせをHexabase側で検証した状態で提供している。「アップグレードのたびにリリースノートを全部読み込む」という作業を運用者が個別に背負わずに済む設計だ。
もし自社のK3sクラスタで、アップグレードのたびに「本当にこのパッチは安全か」を確認するコストが馬鹿にならないと感じているなら、Kubo Cloudの検証済みアップグレードパスを一度比較してみてほしい。EKSやAKSと比べたコスト構造だけでなく、こうした「検証工数込みのTCO」で比較すると見え方が変わってくるはずだ。AI駆動のデプロイメントや可視化されたCaptain UIと合わせて、料金プランのページで具体的な比較ができる。
セキュリティ要件やデータ主権の観点から自社環境での運用を手放せない場合でも、Kubo On-Premiseであれば、検証済みのバージョンの組み合わせをオンプレミスでも適用できる。アップグレード戦略について相談したい場合は、お問い合わせから気軽に声をかけてほしい。