KubernetesのEviction（退去）を修正する：「Pod ephemeral local storage usage exceeds the total limit」

クイックフィックス

もし現在Podがクラッシュしている場合は、デプロイメント・マニフェスト内の ephemeral-storage の制限を引き上げる必要があるでしょう。512Miから1Giや2Giへ素早く増量することで、根本原因を調査するための十分な猶予を確保できます。

spec:
  containers:
  - name: my-app
    resources:
      limits:
        ephemeral-storage: "2Gi" # 即時のEvictionを止めるために制限を2倍にする
      requests:
        ephemeral-storage: "1Gi"

このエラーの原因は？

エフェメラルストレージとは、ノードの物理ディスク上の「一時的な作業領域」のことだと考えてください。Persistent Volume（永続ボリューム）とは異なり、この領域は揮発性です。Kubeletは主に以下の3つの領域を監視しています。

ログファイル: stdout や stderr に出力されるすべてのログ。通常は /var/log/pods に保存されます。
書き込み可能レイヤー: PDF生成時に作成される200MBの一時ファイルなど、コンテナのファイルシステムに直接加えられた変更。
EmptyDir ボリューム: RAMを使用するように明示的に設定されていない emptyDir マウントに保存されたローカルデータ。

Kubeletが、Podが limits.ephemeral-storage の境界を超えたことを検知すると、**Eviction（退去）**をトリガーします。これはノードのディスク容量が100%に達してノード全体がクラッシュするのを防ぐため、Podを即座に強制終了させる仕組みです。

容量を圧迫しているものは何か？

1. 大量のアプリケーションログ

Javaアプリケーションが無限ループに陥ったり、DEBUG モードで動作している場合、数分で500MBものログを生成することがあります。Kubernetesは、ログがローテーションされるまで、これらのログをストレージ使用量としてカウントします。

2. 隠れたキャッシュと一時ファイル

Pythonの pip やNode.jsの npm は、実行時に動的なビルドを行う際、/root/.cache や /tmp に数百メガバイトのデータをダウンロードすることがよくあります。これらのファイルはコンテナの書き込み可能レイヤーに存在し、制限の対象となります。

3. 非圧縮の画像処理

4Kビデオの処理や高解像度画像の一括処理を行うと、/tmp の使用量が数ギガバイトに膨れ上がり、標準的なデフォルト値である 512Mi を容易に超えてしまうことがあります。

修正方法

方法1：リソース制限を増やす

ETLジョブなどでワークロードに2GBのスクラッチスペースが本当に必要な場合は、YAMLを更新してください。kubectl apply -f deployment.yaml を実行して更新を適用し、余裕を持たせた状態でPodを再起動します。

resources:
  requests:
    ephemeral-storage: "1Gi"
  limits:
    ephemeral-storage: "4Gi" # スパイクに備えて十分な上限を設定する

方法2：一時ファイルにRAMを使用する

小規模で高速な一時ファイルの場合は、ディスクの代わりにノードのメモリを使用します。これによりエフェメラルストレージの制限を完全に回避できますが、Podの RAM 制限としてカウントされる点に注意してください。

volumes:
- name: cache-volume
  emptyDir:
    medium: Memory
    sizeLimit: "512Mi"

方法3：Persistent Volume（永続ボリューム）にオフロードする

データベースのバックアップや大規模なMLモデルのダウンロードなど、負荷の高いタスクにエフェメラルストレージを使用しないでください。代わりに PersistentVolumeClaim (PVC) をマウントしましょう。PVCには専用のストレージがあるため、容量がいっぱいになってもKubeletのEvictionはトリガーされません。

方法4：ログの出力量を抑える

アプリのログレベルを DEBUG から INFO に変更することで、ディスクへの負荷を軽減します。本番環境では、ログの90%が不要なノイズであり、それが文字通りPodを停止させている可能性があります。

検証：解決したか？

Metrics Serverを使用して、コンテナの現在のディスク使用量を確認します。

kubectl top pod <pod-name> --containers

以前にPodが強制終了された理由を確認するには、イベントを調査します。「usage exceeds the total limit」というテキストを含む Reason: Evicted メッセージを探してください。

kubectl describe pod <pod-name> | grep -A 3 "Annotations:"

修正が成功すれば、Podは Running 状態を維持し、kubectl get events のログにストレージ関連の警告が表示されなくなります。