---
title: 'Kubernetesのcgroup v1はいつ止まる？ v2移行前に確認すべき5項目'
url: 'https://automationse.net/kubernetes-cgroup-v2-migration-checklist-2026'
markdown: 'https://automationse.net/kubernetes-cgroup-v2-migration-checklist-2026.md'
date: '2026-10-08'
description: '<style> .cg-hero{padding:clamp(26px,5vw,48px);border-radius:23px;color:#fff;background:linear-gradient(125deg,#102c3d,#17677b 60%,#46a7a5)}.cg-hero h2{color:#fff;margin:.3em 0}.cg-kicker{color:#b8efdf;font-size:.79rem;font-weight:800;letter-spacing:.13em}.cg-grid{display:grid;grid-template-colum…'
taxonomy:
  category:
    - クラウド・インフラ
  tag:
    - Kubernetes
    - 'cgroup v2'
    - kubelet
    - コンテナー運用
---

# Kubernetesのcgroup v1はいつ止まる？ v2移行前に確認すべき5項目

## [Kubernetesのcgroup v1はいつ止まる？ v2移行前に確認すべき5項目](https://automationse.net/kubernetes-cgroup-v2-migration-checklist-2026)

  公開日 2026.10.08 更新日 2026.10.08  [Kubernetes](https://automationse.net/tag:Kubernetes#body-wrapper) [cgroup v2](https://automationse.net/tag:cgroup%20v2#body-wrapper) [kubelet](https://automationse.net/tag:kubelet#body-wrapper) [コンテナー運用](https://automationse.net/tag:%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%83%BC%E9%81%8B%E7%94%A8#body-wrapper)  

 <style> .cg-hero{padding:clamp(26px,5vw,48px);border-radius:23px;color:#fff;background:linear-gradient(125deg,#102c3d,#17677b 60%,#46a7a5)}.cg-hero h2{color:#fff;margin:.3em 0}.cg-kicker{color:#b8efdf;font-size:.79rem;font-weight:800;letter-spacing:.13em}.cg-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.cg-card{padding:18px;background:#eef8f7;border:1px solid #b9dcd9;border-radius:14px}.cg-card strong{display:block;color:#176c6b;font-size:1.3rem}.cg-flow{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:10px;margin:20px 0}.cg-step{padding:15px;background:#eaf5f6;border-top:4px solid #50a6aa;border-radius:10px}.cg-step b{display:block;color:#1b6d79}.cg-table{overflow:auto;margin:20px 0}.cg-table table{border-collapse:collapse;width:100%;min-width:610px}.cg-table th,.cg-table td{padding:11px;border:1px solid #bfd9d9;text-align:left;vertical-align:top}.cg-table th{background:#e5f3f3}.cg-note{padding:17px 19px;margin:20px 0;background:#fff7e8;border-left:5px solid #d49439;border-radius:10px}@media(max-width:760px){.cg-grid,.cg-flow{grid-template-columns:1fr}} </style> KUBERNETES / NODE OPERATIONS

## 次の更新でノードが戻らない？

cgroupはPodのCPUやメモリーを制御するLinuxの基盤。v1を残したままKubernetesを更新すると、kubeletの起動条件にぶつかる可能性がある。

## 3行で要約

- Kubernetes公式ブログは**2026年10月6日**、cgroup v2への移行に必要な条件と注意点を整理した。新しい変更がこの日に発効したという意味ではない。\[1\]
- cgroup v2のサポートはKubernetes v1.25から安定。v1.35以降は`failCgroupV1`が標準で`true`となり、v1ノードではkubeletが起動しない。\[1\]\[2\]
- 一時的に`false`へ戻す設定はあるが恒久策ではない。OS・カーネル・ランタイム・ドライバーを点検してから、ノード単位で移す。\[1\]\[2\]

## 背景：cgroup v1とv2の違い

cgroup（control groups）は、Linuxがプロセス群のCPU・メモリーなどの資源を管理する仕組み。Kubernetesのkubeletとコンテナーランタイムはこれを使い、Podに指定された要求量や上限を適用する。v2では複数の資源を1つの階層で扱い、委譲や資源の会計が整理された。Pressure Stall Information（PSI）など、新しい監視・制御機能の基盤にもなる。\[1\]\[2\]

## 何が新しいのか：公式が移行条件を再整理

10月6日の公式記事は新バージョンのリリース告知ではなく、既に進んでいる**v1からv2への移行**を説明する運用ガイドだ。v1.31でv1サポートは保守段階に入り、v1.35では標準設定のkubeletがcgroup v1を拒否する。kubeadm管理の環境では初期化・参加・更新時の事前検査もより厳しくなる。公式記事はv1の一時的なフォールバックを示しつつ、将来の削除を予定している。\[1\]

**v1.25**cgroup v2サポートが安定

**v1.35**標準でcgroup v1を拒否

**Linux 5.8+**公式文書の最小カーネル要件

ノード移行前の5項目
| 項目 | 確認すること | 理由 |
|---|---|---|
| 1. OS | cgroup v2を有効にしているか | v2非対応のままではkubeletが利用できない |
| 2. カーネル | 5.8以上。Memory QoSを試すなら5.9以上を推奨 | 必要なcgroup機能・修正を確保する |
| 3. ランタイム | containerd 1.4以上、またはCRI-O 1.20以上など | v2を扱える実装が必要 |
| 4. ドライバー | kubeletとランタイムのcgroupドライバーを一致させる | 不一致によるノード障害を避ける |
| 5. 運用・監視 | Pod退避、CPU重み、OOM、監視指標を試験 | 起動成功だけでは挙動の変化を見落とす |

## 技術的なポイント

公式文書は、cgroup v2で**systemd cgroupドライバー**を使うことを推奨する。kubeletとランタイムの設定が合っていなければならない。containerd 2.0以降など、`RuntimeConfig`を実装するランタイムではkubeletがドライバーを自動検出できるが、旧ランタイムでは設定の確認が必要だ。\[1\]\[2\]\[3\]

v2では`cpu.shares`から`cpu.weight`へ対応が変わり、OOM（メモリー不足）時にはコンテナー内のプロセス群をまとめて終了させる標準動作がある。正確なCPU重みを監視・ポリシーで前提にしている環境や、複数プロセスを含むコンテナーは移行テストが重要だ。なお、このOOM処理は**コンテナー単位**でありPod全体を常に終了させるという意味ではない。\[1\]

## 実践例：まず読み取り専用で棚卸し

Linuxノードで次のコマンドを実行する。`cgroup2fs`ならv2、`tmpfs`など別の結果ならv1・混在構成を疑う。OS配布版によって差があるため、変更前に実機で確認する。\[1\]\[2\]

```bash
stat -fc %T /sys/fs/cgroup/
uname -r
```

**棚卸し**全Linuxノードの方式と構成

**試験**代表的なPodを検証用ノードで実行

**切替**Podを退避しノードを段階更新

**観測**OOM・CPU・再起動を比較

本番では一括変更せず、対象ノードのPodを退避できるか、PodDisruptionBudgetが移行を妨げないか、ロールバック用のノードイメージがあるかを確認する。OSのcgroup方式を切り替える手順は配布版ごとに異なるため、公式のOS手順に従う。ここに示したコマンドは**確認のみ**で設定を変更しない。

## リスクと限界、今後の注目点

v2に変えるだけで全てのメモリープレッシャーが解消するわけではない。公式記事はI/Oが多いワークロードでの`active_file`に関する退避判定の問題が、v2移行だけでは変わらないと注意している。またMemory QoSなどの機能は、利用中のKubernetes版と機能ゲートの状態を別途確認する必要がある。\[1\]

次の更新前には、利用中のKubernetesリリースのアップグレード文書、OSのデフォルトcgroup方式、ランタイムの対応表を再確認したい。管理サービスではノードイメージや更新手順が事業者ごとに異なるため、提供元の手順も優先する。

**最終確認日：2026年10月8日（日本時間）**

### 参照元

1. [Kubernetes公式ブログ「The Shift to cgroup v2 in Kubernetes」](https://kubernetes.io/blog/2026/10/06/kubernetes-cgroups-v2-shift/) — 移行時期、挙動、検査と注意点。
2. [Kubernetes公式文書「About cgroup v2」](https://kubernetes.io/docs/concepts/architecture/cgroups/) — 最小要件、確認方法、移行の基本。
3. [Kubernetes公式文書「Container Runtimes」](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) — cgroupドライバーとランタイム構成。

  Previous Post Next Post

---

## Navigation

- Previous: [GitLab Dependency Firewall登場：危険な依存パッケージをビルド前に止める仕組みと限界](https://automationse.net/gitlab-dependency-firewall-early-access-guide-2026.md)