Kubernetes が Docker イメージを自動削除するのを緩和する方法
はじめに
Linux などで kubernetes（k8s）を使用していると，気づいたら作成した docker image が無くなっている！ なんてことありませんか？
私はそれで何度も作り直しました．
よくよく調べてみると，k8s で，ストレージの使用率によって自動で削除する設定になっているようです．
今回は k8s による自動削除を緩和する方法を記載します．
※ この方法は一時的な回避策で，実際はストレージを増やすことをお勧めします
k8s によるイメージ自動削除
k8s にはストレージの逼迫状況によってイメージに対するガベージコレクションが働く機能があります．
ドキュメントによると下記のような記載があります．
| 設定 | 説明 |
|---|---|
| imageGCHighThresholdPercent |
imageGCHighThresholdPercent は，ディスク使用率がこの値を超えたときに，イメージのガベージコレクション（不要なイメージの削除）が実行される閾値のことです． この値は imageGCLowThresholdPercent より大きくなければなりません．デフォルト値は 85 です． |
| imageGCLowThresholdPercent | ガベージコレクションが目指すディスク使用率の下限 |
つまり，ディスク使用率が imageGCHighThresholdPercent% を超えたとき GC が開始され，imageGCLowThresholdPercent% を下回るまで不要なイメージを削除するということです．
また，GC の詳細については下記に記載があります．
まとめると...
- kubelet が 5 分毎に使用していないイメージを削除
- kubelet が 1 分毎に使用していないコンテナを削除
- 外部の GC ツールは非推奨
- kubelet の config ファイルから設定可能
- HighThresholdPercent・LowThresholdPercent でも GC が走る
- LRU でイメージ削除される
設定ファイルの修正
前述の設定を変更することで，ストレージ逼迫によるイメージ削除を少し緩和できそうです．
設定ファイルの確認
$ ps aux | grep kubelet
上記を実行すると --config という起動引数があると思います．
この引数に設定されているパスが設定ファイルのパスです．
--config=/var/lib/kubelet/config.yaml のような形で指定されているはずです．
設定変更
上記の設定ファイルを開き，設定を変更します．
もし既に imageGCHighThresholdPercent・imageGCLowThresholdPercent が存在する場合，その値を変更してください．
存在しない場合は追記してください．
※ 事前にコピーしてバックアップ推奨
imageGCHighThresholdPercent: 95
imageGCLowThresholdPercent: 90
上記の設定の場合，ストレージ使用率 95% に達したときに GC が走り，90% になるまでイメージを削除します．
値を高めに設定することで，イメージが自動で削除されるタイミングを遅らせることができます．
最後に kubelet の再起動をします．
$ sudo systemctl restart kubelet
これで変更が適用されます．
Pod 退避について
上記の設定をしたけどまだ Pod の停止・削除が走る場合，eviction（退避） によるものの可能性が高いです．
eviction は kubelet がノードリソース（ディスク・メモリなど）の逼迫を検出し，Pod を強制停止する仕組みです．
ここにも imagefs という似たような設定があります．
先ほどと同様に kubelet の設定ファイルを開き，下記のような記載を変更・追記します．
evictionHard:
imagefs.available: 10%
上記の設定では， imagefs の空き容量が 10% 未満になった場合に Pod の退避が発生します．
設定を変更したら，kubelet の再起動を行います．
$ sudo systemctl restart kubelet
この辺りの変更でストレージ逼迫による image 削除・Pod の強制停止などは避けられると思います．
最後に
今回は k8s を使っていて，ストレージ使用率によりイメージが削除されたり，Pod が急に幾つもストップする時の一時的な回避策を紹介しました．
k8s のログにイメージを削除しようとしていたログなどが出ていた場合，この方法で解決できる可能性が高いです．
ただ，過度なカスタマイズは思わぬ副作用を引き起こす可能性があるため，恒久的な対策としてはストレージの増設や不要データの削除をおすすめします．