Kubernetes fsGroupChangePolicyと再起動SLO: 2026信頼性プレイブック
Kubernetes運用では、再起動時間が「なんとなく遅い」で済まされがちです。しかし実際には、再起動遅延はデプロイ安全性や障害復旧速度に直結するSLO要素です。
その中でも見落とされやすいのが fsGroupChangePolicy です。
PVCを使うワークロードでマウント時の再帰的所有権変更が走ると、起動が秒単位から分単位に膨らみます。本稿では、セキュリティ要件を維持しつつ再起動SLOを守るための適用手順を整理します。
2026年に重要性が増した背景
AI/分析系を含むステートフル処理では、大容量ボリュームをマウントするケースが増えています。ノード再配置やローリング更新時に所有権更新がボトルネック化し、次に影響します。
- リリース失敗時の復旧時間
- フェイルオーバー収束
- オートスケール追従
- メンテ時間の予測精度
fsGroupChangePolicy の基本
主に次の2値を使います。
Always: 毎回再帰的に所有権変更OnRootMismatch: ルート不一致時のみ変更
大容量ボリュームでは OnRootMismatch により起動短縮が期待できますが、前提条件（初期所有権整備、権限モデル）が重要です。
リスク別の適用判断
全クラスタ一括変更は避け、ワークロードを階層化します。
Tier A: 低遅延重視 + 信頼済みイメージ経路
OnRootMismatchを優先- イメージ来歴を固定
- ボリューム初期化で所有権を整える
Tier B: 所有権履歴が混在
- 一時的に
Always継続 - 所有権是正ジョブを実施
- 計画的にTier Aへ移行
Tier C: 厳格なマルチテナント分離要件
- Namespace単位で慎重適用
- Admission制御と併用
- 所有権ドリフト定期検査
まず計測: 再起動経路を可視化する
変更前に以下の時刻を収集します。
- スケジューリング時刻
- ボリュームマウント開始/終了
- コンテナ起動
- Ready到達
ボリュームサイズとワークロード種別で分解しないと、改善効果を説明できません。
安全な展開パターン
- Helm値や注釈でオプトイン化
- 対象の5〜10%をカナリア
- restart p50/p95とエラー率を比較
- Namespace単位で波状展開
- ロールバック条件を明文化
同一期間にストレージドライバ更新を重ねないのも重要です。
セキュリティ懸念への先回り
OnRootMismatch への変更は監査で質問されやすいので、以下をセットで提示します。
- ワークロードごとのUID/GID設計書
- 可能な範囲で非root運用
- 所有権ドリフト検出ジョブ
- Admission時のポリシー選択ログ
「制御を弱める」のではなく「毎回の破壊的変更を減らし、定常検知へ移す」と説明できます。
再起動SLOとの接続
カテゴリ別SLOを明示します。
- ステートレスAPI: p95 20秒未満
- 中程度状態保持: p95 60秒未満
- 重状態保持: p95 180秒未満
fsGroupChangePolicy は、このSLO達成に対する具体施策として管理すると優先順位がぶれません。
想定インシデント: ピーク時ノードドレイン
ピーク時に40Podが同時再配置されたとき、各Podで90秒の所有権再帰変更が走れば復旧は長引きます。OnRootMismatch を前提整備のうえ適用できていれば、復旧時間と通知ノイズを大きく下げられます。
45日導入計画
1-10日
- 再起動経路の計測開始
- fsGroup + PVC利用ワークロード棚卸し
- Tier分類
11-25日
- Tier Aカナリアで
OnRootMismatch - ドリフト検査運用
- SRE/セキュリティ合同レビュー
26-45日
- Tier A全面展開
- Tier Bの是正完了
- 再起動SLOダッシュボード公開
まとめ
fsGroupChangePolicy は地味ですが、再起動遅延が支配的な環境では効果が大きい設定です。前提整備と段階展開を行えば、セキュリティ要件を守りながら可用性を改善できます。
再起動時間をSLOとして扱う運用に切り替えることが、結果として障害耐性を押し上げます。
