[{"data":1,"prerenderedAt":423},["ShallowReactive",2],{"blog-ja-k3s-containerd-v1-v2-patch-version-skew-policy":3,"blog-related-ja-k3s-containerd-v1-v2-patch-version-skew-policy":362,"blog-ja-k3s-containerd-v1-v2-patch-version-skew-policy-alt":351},{"id":4,"title":5,"author":6,"body":7,"date":345,"description":346,"extension":347,"image":348,"locale":349,"meta":350,"navigation":351,"path":352,"seo":353,"stem":354,"tags":355,"__hash__":361},"blog\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy.md","K3sの\"ただのパッチ\"アップデートで、containerd設定テンプレートが効かなくなった。v1→v2移行はバージョンスキューポリシーの外側で起きる","Kubo Team",{"type":8,"value":9,"toc":335},"minimark",[10,18,23,26,34,42,48,52,63,80,89,96,102,106,119,144,151,157,161,169,212,215,224,230,234,243,261,268,277,284,290,294,297,306,320],[11,12,13],"p",{},[14,15],"img",{"alt":16,"src":17},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy\u002Fsection01.webp",[19,20,22],"h2",{"id":21},"_1-事の起こり-パッチだから安全のはずのk3sアップグレード","1. 事の起こり — 「パッチだから安全」のはずのK3sアップグレード",[11,24,25],{},"Kubernetesの運用で染み付いた感覚がある。「マイナーバージョンのアップグレードは慎重に。でもパッチバージョンなら、バグ修正とセキュリティパッチが入るだけだから、さっさと当てておけばいい」というものだ。",[11,27,28,29,33],{},"K3sクラスタでcontainerdの挙動をカスタマイズしていた、あるチームの話をしよう。レジストリのミラー設定や独自のランタイムハンドラを、containerdの設定テンプレート（",[30,31,32],"code",{},"config.toml.tmpl","）に書き込んで運用していた。ある日、パッチバージョンのK3sアップグレードを自動化パイプラインで流した。バージョン番号は1つしか変わっていない。ところが、アップグレード後に独自のcontainerd設定が反映されなくなっていることに気づく。",[11,35,36,37,41],{},"原因を遡ると、Kubernetes本体のマイナーバージョンは一切変わっていないのに、",[38,39,40],"strong",{},"同梱されているcontainerdがメジャーバージョンごと切り替わっていた","ことが判明した。これは特定の環境固有の不具合ではなく、K3sの公式リリースノートに実際に記録されている既知の変更だ。",[11,43,44],{},[14,45],{"alt":46,"src":47},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy\u002Fsection02.webp",[19,49,51],{"id":50},"_2-kubernetes公式のバージョンスキューポリシーはマイナーバージョンの話しかしていない","2. Kubernetes公式のバージョンスキューポリシーは「マイナーバージョン」の話しかしていない",[11,53,54,55,62],{},"まず前提を整理したい。Kubernetesには",[56,57,61],"a",{"href":58,"rel":59},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fsetup\u002Frelease\u002Fversion-skew-policy\u002F",[60],"nofollow","公式のバージョンスキューポリシー","があり、kubeletとkube-apiserverの間でどこまでバージョン差を許容するかが明記されている。要点は次の通りだ。",[64,65,66,70,77],"ul",{},[67,68,69],"li",{},"kubeletはkube-apiserverより新しいバージョンであってはならない",[67,71,72,73,76],{},"Kubernetes 1.25以降は、kubeletがkube-apiserverより",[38,74,75],{},"最大3マイナーバージョン","古くても動作する",[67,78,79],{},"それより古いKubernetesでは、許容されるのは2マイナーバージョンまで",[11,81,82,83,88],{},"この「n-3」までの許容は、もともと",[56,84,87],{"href":85,"rel":86},"https:\u002F\u002Fwww.kubernetes.dev\u002Fresources\u002Fkeps\u002F3935\u002F",[60],"KEP-3935","として提案され、v1.28で安定機能として実装された経緯がある。KEPの狙いは明快で、「ノードのアップグレードはワークロードに対してより破壊的なので、その頻度を減らしたい」というものだ。コントロールプレーンだけ先に上げて、ノード側は後からまとめて追従できる余地を広げる、という発想である。",[11,90,91,92,95],{},"ここで重要なのは、",[38,93,94],{},"このポリシーがカバーしているのはKubernetesコア自体のマイナーバージョン差だけ","だという点だ。kubeletやkube-apiserverのバージョンについては明確なルールがあるが、ディストリビューションが同梱している周辺コンポーネント（コンテナランタイム、CNI、DNS、Ingressコントローラ等）のバージョンについては、このポリシーは一言も触れていない。",[11,97,98],{},[14,99],{"alt":100,"src":101},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy\u002Fsection03.webp",[19,103,105],{"id":104},"_3-パッチリリースでcontainerdがv1v2に切り替わった実例","3. パッチリリースでcontainerdがv1→v2に切り替わった実例",[11,107,108,109,114,115,118],{},"ここで、冒頭のシナリオの裏付けとなる実例を見てみよう。",[56,110,113],{"href":111,"rel":112},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fk3s\u002Freleases\u002Ftag\u002Fv1.32.1%2Bk3s1",[60],"K3s公式のGitHubリリース","によれば、v1.32.1+k3s1（2025年1月28日リリース）が同梱していたcontainerdは ",[30,116,117],{},"v1.7.23-k3s2"," だった。",[11,120,121,122,127,128,131,132,135,136,139,140,143],{},"ところがその次の",[56,123,126],{"href":124,"rel":125},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fk3s\u002Freleases\u002Ftag\u002Fv1.32.2%2Bk3s1",[60],"v1.32.2+k3s1（2025年2月27日リリース）","では、containerdが ",[30,129,130],{},"v2.0.2-k3s2"," に切り替わっている。Kubernetesのバージョン表記は ",[30,133,134],{},"v1.32.1"," から ",[30,137,138],{},"v1.32.2"," へと、",[38,141,142],{},"パッチ番号が1つ進んだだけ","だ。にもかかわらず、公式リリースノート自身が「containerdをバージョン2.0にバンプした」「新しい設定ファイルスキーマが導入されたため、カスタム設定を使っているユーザーはテンプレートの移行が必要」と明記している。",[11,145,146,147,150],{},"つまりこれは不具合ではなく、",[38,148,149],{},"K3sが公式に告知していた仕様変更","だ。ただし、その告知は「Kubernetesのバージョンスキューポリシー」という読者が普段チェックしている情報源には一切現れない。リリースノートの細部を読んでいなければ、パッチ番号の見た目通り「軽微な更新」として扱ってしまうのも無理はない。",[11,152,153],{},[14,154],{"alt":155,"src":156},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy\u002Fsection04.webp",[19,158,160],{"id":159},"_4-containerd-20の非互換変更-何が静かに壊れるのか","4. containerd 2.0の非互換変更 — 何が静かに壊れるのか",[11,162,163,168],{},[56,164,167],{"href":165,"rel":166},"https:\u002F\u002Fcontainerd.io\u002Fdocs\u002F2.3\u002Fcontainerd-2.0\u002F",[60],"containerd公式ドキュメント","は、2.0での主要な破壊的変更を次のように説明している。",[64,170,171,181,200,209],{},[67,172,173,176,177,180],{},[38,174,175],{},"Docker Schema 1イメージの取得がデフォルトで無効化","される（",[30,178,179],{},"application\u002Fvnd.docker.distribution.manifest.v1+prettyjws"," 形式）",[67,182,183,184,187,188,191,192,195,196,199],{},"containerd 1.4で非推奨となっていた旧ランタイムシム（",[30,185,186],{},"io.containerd.runtime.v1.linux"," と ",[30,189,190],{},"io.containerd.runc.v1","）が",[38,193,194],{},"完全に削除","され、",[30,197,198],{},"io.containerd.runc.v2"," への移行が必須になる",[67,201,202,205,206],{},[30,203,204],{},"io_uring"," 系のシステムコールが",[38,207,208],{},"デフォルトで許可されなくなる",[67,210,211],{},"CRI v1alpha2 APIやAUFSスナップショッターなど、旧来のコンポーネントが削除される",[11,213,214],{},"設定テンプレートの移行漏れだけでなく、古い形式のコンテナイメージを使い続けている環境や、独自のランタイムハンドラを指定している環境では、イメージの取得エラーやコンテナ起動エラーという形で影響が表面化する可能性がある点にも注意したい。",[11,216,217,218,223],{},"同じ理屈で、最新のK3s v1.36ラインでも同梱コンポーネントのセットは",[56,219,222],{"href":220,"rel":221},"https:\u002F\u002Fdocs.k3s.io\u002Frelease-notes\u002Fv1.36.X",[60],"リリースのたびに更新され続けている","。たとえば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つのバージョン文字列の裏に、これだけの数のコンポーネントがバンドルされていることを意識しておく必要がある。",[11,225,226],{},[14,227],{"alt":228,"src":229},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy\u002Fsection05.webp",[19,231,233],{"id":232},"_5-安全なk3sアップグレード手順-公式ドキュメントが既に警告していたこと","5. 安全なK3sアップグレード手順 — 公式ドキュメントが既に警告していたこと",[11,235,236,237,242],{},"公平を期すために言うと、K3s公式の",[56,238,241],{"href":239,"rel":240},"https:\u002F\u002Fdocs.k3s.io\u002Fupgrades\u002Fmanual",[60],"アップグレードガイド","は、はじめからリスクを織り込んだ手順を案内している。",[64,244,245,252,258],{},[67,246,247,248,251],{},"アップグレード計画で",[38,249,250],{},"マイナーバージョンを飛ばさない","こと（Kubernetesのバージョンスキューポリシーに準拠するため）",[67,253,254,257],{},[38,255,256],{},"サーバーノードを1台ずつアップグレードし、その後にエージェントノード","をアップグレードすること",[67,259,260],{},"APIサーバーの一時停止に敏感なワークロードがある場合は、事前にノードをdrain\u002Fcordonしてからアップグレードし、完了後にuncordonすること",[11,262,263,264,267],{},"この手順自体は正しい。問題は、",[38,265,266],{},"この手順が守っている「スキューポリシー」と、今回のcontainerdのような同梱コンポーネントの非互換変更は、そもそも別のレイヤーの話","だということだ。前者はKubernetes本体のマイナーバージョン差の話であり、後者はディストリビューションが選んだ依存関係のバージョン管理の話である。どちらか一方を守っていても、もう一方で事故は起きうる。",[11,269,270,271,276],{},"実際、クラスタアップグレード中にノードが応答しなくなる・不安定になるという事象は、K3sに限らず起こりうる。たとえば",[56,272,275],{"href":273,"rel":274},"https:\u002F\u002Faccess.redhat.com\u002Fsolutions\u002F7098391",[60],"Red Hatのナレッジベース","でも、OpenShiftのクラスタアップグレード中にkubeletの証明書や設定ファイルの不整合でノードがNotReadyに陥る事例が報告されている。原因は様々でも、「アップグレードのたびにリリースノートの隅々まで確認する」という地味な作業の重要性は変わらない。",[11,278,279,280,283],{},"K3sを採用する以上、",[38,281,282],{},"リリースノートの「Urgent Upgrade Notes」や変更点セクションを、パッチバージョンであっても毎回確認する","運用をルール化しておくべきだろう。CIパイプラインで自動アップグレードを組んでいるなら、なおさらこのチェックを自動化できないか検討する価値がある。",[11,285,286],{},[14,287],{"alt":288,"src":289},"section06","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy\u002Fsection06.webp",[19,291,293],{"id":292},"_6-まとめ-検証された組み合わせを自分で背負うか任せるか","6. まとめ — \"検証された組み合わせ\"を自分で背負うか、任せるか",[11,295,296],{},"「Kubernetes標準のバージョンスキューポリシーを守っている」ことと、「K3sのパッチリリースが安全である」ことは、別の話だ。K3sはKubernetesコアだけでなく、containerd・Flannel・CoreDNS・Traefik・local-path-provisionerといった周辺コンポーネントを1つのバージョン文字列にまとめて配布する。その利便性の裏側で、パッチ番号という\"見た目\"だけでは判断できない非互換変更が混ざり込む余地がある。",[11,298,299,300,305],{},"この検証作業をすべて自前のオペレーションチームで担うのか、それとも検証済みの組み合わせとして提供してもらうのかは、運用コストに直結する判断だ。",[56,301,304],{"href":302,"rel":303},"https:\u002F\u002Fkubo.hexabase.io\u002F",[60],"Kubo","はK3sベースのマネージドKubernetesとして、K3sのバージョンと同梱コンポーネントの組み合わせをHexabase側で検証した状態で提供している。「アップグレードのたびにリリースノートを全部読み込む」という作業を運用者が個別に背負わずに済む設計だ。",[11,307,308,309,313,314,319],{},"もし自社のK3sクラスタで、アップグレードのたびに「本当にこのパッチは安全か」を確認するコストが馬鹿にならないと感じているなら、",[56,310,312],{"href":302,"rel":311},[60],"Kubo Cloud","の検証済みアップグレードパスを一度比較してみてほしい。EKSやAKSと比べたコスト構造だけでなく、こうした「検証工数込みのTCO」で比較すると見え方が変わってくるはずだ。AI駆動のデプロイメントや可視化されたCaptain UIと合わせて、",[56,315,318],{"href":316,"rel":317},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[60],"料金プラン","のページで具体的な比較ができる。",[11,321,322,323,328,329,334],{},"セキュリティ要件やデータ主権の観点から自社環境での運用を手放せない場合でも、",[56,324,327],{"href":325,"rel":326},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[60],"Kubo On-Premise","であれば、検証済みのバージョンの組み合わせをオンプレミスでも適用できる。アップグレード戦略について相談したい場合は、",[56,330,333],{"href":331,"rel":332},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[60],"お問い合わせ","から気軽に声をかけてほしい。",{"title":336,"searchDepth":337,"depth":337,"links":338},"",2,[339,340,341,342,343,344],{"id":21,"depth":337,"text":22},{"id":50,"depth":337,"text":51},{"id":104,"depth":337,"text":105},{"id":159,"depth":337,"text":160},{"id":232,"depth":337,"text":233},{"id":292,"depth":337,"text":293},"2026-10-22","K3sのパッチリリースでcontainerdがv1からv2に切り替わり、カスタム設定テンプレートが効かなくなった実例から、Kubernetes公式のバージョンスキューポリシーが見ていない場所で起きる非互換変更を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy",{"title":5,"description":346},"blog\u002Fja\u002Fk3s-containerd-v1-v2-patch-version-skew-policy",[356,357,358,359,360],"k3s","kubernetes","containerd","version-skew","patch-upgrade","VuMR8BKVa_I_czMlv3E-KQIlUDvUvwW9M0NFVBovmYw",[363,373,383,395,405,415],{"path":364,"title":365,"description":366,"date":367,"tags":368},"\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant","K3sもKubernetesも\"デフォルトのServiceAccount\"が同じ罠を持っている。マルチテナント環境でautomountを放置すると何が起きるか","K3s vs K8sを比較しても、defaultのServiceAccountが抱えるautomountの罠は変わらない。マルチテナント環境での権限昇格リスクと、実際のCVEを交えた4層の対策を解説する。","2026-10-23",[356,357,369,370,371,372],"rbac","serviceaccount","multi-tenancy","security",{"path":374,"title":375,"description":376,"date":377,"tags":378},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[356,357,379,380,381,382],"hpa","containerresource","autoscaling","service-mesh",{"path":384,"title":385,"description":386,"date":387,"tags":388},"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison","K3s vs 標準Kubernetes、CNIの出発点はここまで違う。Flannel標準搭載とCNI選択制が生む差","K3sはFlannelをデフォルト同梱し、標準KubernetesはCNI未選定の状態から始まる。この出発点の違いがNetworkPolicyの可否や通信性能にどう影響するかを、K3s\u002FKubernetes\u002FCalico\u002FCiliumの公式ドキュメントをもとに比較・解説する。","2026-10-20",[356,357,389,390,391,392,393,394],"cni","flannel","calico","cilium","networkpolicy","networking",{"path":396,"title":397,"description":398,"date":399,"tags":400},"\u002Fblog\u002Fja\u002Fk3s-topology-spread-constraints-poddisruptionbudget-node-drain-pending","ノードをdrainしたらPodがPendingのまま戻らなかった。K3sでTopology Spread ConstraintsとPodDisruptionBudgetが衝突する理由","K3s本番でノードをdrainしたら一部PodがPendingのまま戻らなかった。原因はTopology Spread ConstraintsのmaxSkewとPodDisruptionBudgetの衝突。drainがノード数不足を自ら作り出す仕組みを公式ドキュメントベースで検証する。","2026-10-19",[356,357,401,402,403,404],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",{"path":406,"title":407,"description":408,"date":409,"tags":410},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[356,357,411,412,413,414],"validatingadmissionpolicy","kyverno","cel","admission-control",{"path":416,"title":417,"description":418,"date":419,"tags":420},"\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup","VPAをInPlaceOrRecreateにしたのに、Podはまだ再起動していた。K3sでInPlacePodVerticalScalingの\"無停止\"を検証する","VPAのInPlaceOrRecreateモードとIn-Place Pod ResizeでPodは本当に再起動しないのか。K3s環境でQoSクラス制約とcgroup v1の罠を実際の設定例とkubectlコマンドで検証する。","2026-10-17",[356,357,421,381,422],"vpa","cgroup",1792736036055]