コンテナランタイム（コンテナを実際に起動・管理するソフトウェア）レイヤーで、見落としがちな断絶系アップグレードが進行している。Kubernetes 1.36（2026年4月22日リリース）はcgroup v1（Linuxのリソース制御機能の旧バージョン）サポートを完全削除した[1]。cgroup v1のまま残るノードではkubelet（Kubernetesノードエージェント）が起動を拒否し、クラスターがサービス不能に陥る。同時にcontainerd（OSSのコンテナランタイム）の2.0系移行も求められ、containerd 1.6.xを使うノードはK8s 1.36以降で動作しない[2]。EKS・AKS・GKEの各マネージドサービスとセルフホストノードでは対応状況とタイムラインが異なる。今すぐ確認すべきノードのcgroupバージョンと移行手順を整理する。
Kubernetes 1.36とcontainerd 2.0が同時に引き起こす断絶
Kubernetes 1.35（2025年12月リリース）はcgroup v1サポートをデフォルト無効化し、警告を出す予行演習だった[1]。1.36でその猶予は終了した。cgroup v1のままのノードはkubeletが起動を完全に拒否するため、「K8s 1.36にアップグレードしたらノードが全滅」という事態が起きうる。
containerdのバージョン制約も重なる。K8s 1.35がcontainerd 1.x系をサポートする最後のバージョンであり、K8s 1.36ではcontainerd 1.7.x以上が最低要件、推奨は2.0.x以上だ[2]。containerd 1.6.xを使い続けているノードは1.36に上げた瞬間に動作が止まる。
| K8sバージョン | cgroup v1 | containerd 1.6.x | containerd 1.7.x | containerd 2.0.x |
|---|---|---|---|---|
| 1.35 | 無効化デフォルト（警告） | 非推奨 | 対応 | 対応 |
| 1.36 | 削除 | 非対応 | 最小要件 | 推奨 |
マネージドK8s各社の対応状況
マネージドKubernetesでも対応タイミングは異なる。自社環境の確認ポイントを整理する。
EKS（Amazon Elastic Kubernetes Service）：K8s 1.32がAmazon Linux 2（AL2）をサポートする最後のバージョンで、AWS公式はAL2023またはBottlerocketへの移行を推奨している[3]。AL2023はcgroup v2がデフォルト有効。AL2のノードグループを持つ場合は、K8s 1.33以降へのアップグレード前にAL2023への置き換えが必要だ。
GKE（Google Kubernetes Engine）：Container-Optimized OS（COS）ノードは2023年以降からcgroup v2がデフォルトで有効になっており、特別な対応は不要なケースが多い。ただしカスタムLinuxイメージを使ったノードプールは個別確認が必要。
AKS（Azure Kubernetes Service）：標準のUbuntuノードはAKS 1.25以降からcgroup v2がデフォルト有効。古いノードプールが残っている場合はAKSのノードイメージバージョンを確認する。
セルフホストノード：オンプレ・プライベートクラウドの自前ノードが最もリスクが高い。後述の手順で今すぐcgroupバージョンを確認する。
自前ノードのcgroup v2移行手順
以下の手順は、セルフホストのLinuxノード（RHEL/CentOS/Ubuntuを想定）をcgroup v2に移行し、containerd 2.0を設定するための手順だ。本番前に必ずステージング環境で検証すること。
Step 1 — cgroupバージョンの確認
stat -fc %T /sys/fs/cgroup/
出力が cgroup2fs なら cgroup v2 有効。tmpfs または cgroupfs なら cgroup v1 のまま[3]。
Step 2 — cgroup v2の有効化（GRUB設定）
Linuxカーネルの起動パラメーターを変更してcgroup v2を有効化する。distroによって設定ファイルの場所が異なるため、ディストリビューションのドキュメントを参照する。変更後はノードを再起動する。
Step 3 — containerd設定更新
containerdの設定ファイル（/etc/containerd/config.toml）で、SystemdCgroup = true を設定する[3]。その後containerdを再起動し、kubeletを再起動する。
Step 4 — ノードのdrain→アップグレード→uncordon
移行作業中はノードをcordonして新規スケジューリングを止め、既存Podをdrainしてから作業する。作業完了後にuncordonしてノードをクラスターに戻す。ローリング更新で1ノードずつ実施することを推奨する。
まとめ：K8s 1.36アップグレード前の確認チェックリスト
cgroup v2とcontainerd 2.0への移行は「やれば終わる作業」だが、準備なしにK8s 1.36にアップグレードすると本番クラスターが停止する。以下の3点を今すぐ確認する。①全ノードのcgroupバージョン（stat -fc %T /sys/fs/cgroup/）、②containerdのバージョン（1.7.x以上か）、③マネージドサービス利用の場合はノードOS（EKSはAL2→AL2023の要否）。K8s 1.35以前のバージョンを使っている場合も、次のアップグレードサイクルに備えて今から移行計画を立てることを勧める。
よくある質問（FAQ）
Q1. containerd 1.7.xを使えばK8s 1.36に対応できますか？
最低要件は containerd 1.7.x ですが、推奨は 2.0.x 以上です。containerd 2.0 はcgroup v2対応の最適化が含まれているため、可能であれば 2.0.x への移行が望ましいです。
Q2. EKSでAmazon Linux 2を使い続けることはできますか？
K8s 1.32までのサポートです。K8s 1.33以降に上げる場合はAL2023またはBottlerocketへのノードグループ置き換えが必要です。
Q3. GKEはcgroup v2に自動で移行されていますか？
Container-Optimized OSを使うノードプールは2023年以降から cgroup v2 がデフォルトです。カスタムイメージを使用している場合は個別確認が必要です。
