Kubernetes再起動30分問題をどう潰すか: fsGroupChangePolicyに学ぶPlatform SRE実装

Cloudflareが公開した「fsGroupChangePolicy調整で再起動を30分→30秒に短縮した事例」は、Kubernetes運用で繰り返し起こる本質的な問題を示しています。つまり、安全寄りデフォルトがスケール時に高コスト化するという問題です。

参考: https://blog.cloudflare.com/one-line-kubernetes-fix-saved-600-hours-a-year/

再起動遅延は“慢性的な業務停止”を作る

Statefulな制御系コンポーネント（例: Terraform運用基盤、内部CI制御面）が再起動に20〜30分かかると、次の損失が蓄積します。

• デプロイ待ちによる開発停滞
• メンテ時のオンコール負担増
• 再起動が怖くなり、必要更新を先送り

短く言えば、運用品質が徐々に腐っていきます。

なぜfsGroup周りで遅延が急増するのか

Kubernetesは整合性確保のため、Pod起動時にボリューム権限整合を行います。ファイル数が増えたPVでは、この処理が大きな遅延要因になります。特に、長期運用でinodeが増え続けるsingleton系ワークロードで顕著です。

早期検知のシグナル

• PodがContainerCreatingで長時間停止
• 再起動時間がPV容量・inode増加と相関
• Secret更新など軽微変更でも長時間停止
• “再起動したくない”運用文化が生まれている

この兆候があるなら、アプリ以前にストレージ前処理を疑うべきです。

実装手順（安全重視）

1) 起動時間の分解観測

スケジューリング、Volume Attach、権限調整、アプリ初期化を分離して計測します。遅延の真因を可視化しないままチューニングすると再発します。

2) 検証環境でポリシー比較

本番近いデータ量でfsGroupChangePolicyを比較し、起動時間とアクセス制御の両方を評価します。

3) 段階リリースとロールバック条件

環境ごとに順次適用し、起動失敗率・Permission Denied増加を監視。閾値超過時の即時復帰手順を先に用意します。

4) テンプレート標準化

有効だったsecurityContextを共通テンプレート化し、新規ワークロードにもデフォルト適用します。

セキュリティ妥協を防ぐ確認項目

性能改善時に必ず確認する点:

• 実効所有者/権限が想定どおりか
• 不要な書き込み権限拡大がないか
• ワークロードIDとデータアクセス方針が整合しているか

速くなったが危険になった、は失敗です。

効果測定KPI

• Stateful基盤の再起動時間 p50/p95
• 月間の“再起動待ち工数”
• メンテ完了までのリードタイム
• 再起動起因インシデント件数

KPI化すると、単発改善ではなく運用標準に昇格できます。

まとめ

今回の学びは「一行変更が重要」ではなく、「デフォルトの前提を定期的に再検証する文化が重要」という点です。Kubernetes運用は、安全性と効率性の両立を継続的に調整してこそ、長期運用で強くなります。