Kubernetes disk-pressure で Pod が起動しない場合

Kubernetes で Pod が起動しなくなり、node.kubernetes.io/disk-pressure の taint が原因になっていた時のメモです。ノードのディスクが逼迫すると、Kubernetes は Pod のスケジューリングや起動を止めることがあります。

出ていたメッセージ

0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.

原因

この時は、Pod 内のデータを毎日バックアップしており、そのバックアップデータでノード側のディスクが単純にいっぱいになっていました。アプリケーションや Kubernetes の設定不備というより、ノードの空き容量不足が直接の原因です。

確認すること

kubectl describe node <node-name>
kubectl get pod -A -o wide
df -h
sudo du -xh /var/lib/containerd | sort -h | tail
sudo du -xh /var/lib/kubelet | sort -h | tail

復旧の考え方

• 不要なバックアップや一時ファイルを削除する。
• コンテナイメージや古いログが肥大化していないか確認する。
• 必要に応じて node を再起動する。
• バックアップ保存先を Pod / node のローカルディスクに置き続けない。
• 監視でディスク使用率を見て、disk-pressure になる前に気づけるようにする。

まとめ

disk-pressure は Kubernetes の問題というより、ノードのリソース不足が Kubernetes に表面化した状態です。Pod が起動しない時は、まず scheduler のエラー、node condition、ディスク使用量、container runtime の保存領域を確認します。

関連記事

Kubernetes Multus の導入 – Pod に複数 NIC を接続する Kubernetes Nginx コンテナの実行 – Deployment で Pod を管理する Kubernetes クラスタの初期化 – kubeadm reset の基本 古い Kubernetes クラスター構築メモ – kubeadm 手順を現在の記事へ読み替える Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する Kubernetes / コンテナ環境で MariaDB の /var/lib/mysql を永続化する Kubernetes に Docker / Podman のような stop/start がない理由 Kubernetes コントロールプレーンノードを追加できない場合 – kubeadm-certs を再生成する