環境
プラットフォーム: AWS
kubernetes: v1.11.5
現象
kubernetesのnodeで使用しているインスタンスのread operationが不定期で大爆発を起こす
その間cpu微増、他のメトリクスには目立った動きなし
EBSの上限に達してreadが制限されるため、nodeのstatusがunknownになったり、展開しているpodのレスポンスが悪化したりなどの障害になる
cloudwatchメトリクス
cadvisorメトリクス（readがEBSの制限に引っかかりprometheusで取得できていない…）
リアルタイムで遭遇したことはないが運良く出くわしたとしても制限に引っかかってる以上ログインもできなさそう
起こる条件調査
- あるアプリケーションのpodを展開しているnodeでのみ起きる
- モニタリング用やcontrollerのnodeでは起きたことがない
- 起動後しばらく経ったnodeで起きる
- 10日以上
- アプリケーションの起動時間は無関係
- ちょくちょくpodを作り直しても起きる
アプリケーションpodを展開しているnodeでしか起きてないので何かしら関係があるのは確実
しかしcadvisorメトリクスを見る感じだとkubeletや各pod全体的にreadが増えていたのでアプリケーションのpodだけが直接の原因ではなさそう
手がかり
それっぽいやつ
うやむや
https://github.com/kubernetes/kubernetes/issues/47928
似てるけど違うっぽいやつ
貼られてるメトリクスはそっくりだがとにかく古い
https://github.com/kubernetes/kubernetes/issues/23255
これもまた多少古いしdeviceも違う
https://github.com/kubernetes/kubernetes/issues/61999
メモリ不足が原因の可能性…？
たしかに現象が起きているnodeはメモリを一杯に使った運用をしている
実験
ローカルでvagrantを使ってclusterを作成
workerにはmemoryを4GiB割り振る
メモリを消費するpodをdeployしながらiotopで様子を見る
平時
一定以上メモリを消費すると…
一応47928と同じような状況にはなったが、これが本番環境で起きていることと同じかは確定していない
しかしいずれにせよきちんと対策しないといけない問題なのも間違いない
メモリ不足が問題なようだけど果たしてkubernetesの問題なのかなこれは
現在の結論と対策
pod領域がsystem領域のメモリを圧迫して発生する症状の可能性が高い
（起動後しばらく経ったnodeでしか起きないのも感覚的にはなんとなく納得できる）
それにしてもOOM Killer先生は何をやっているのか
47928にあるようにkubeletのflag、kube-reservedやsystem-reservedでリソースを確保して様子を見る
無駄にたくさんあげたくないし、どのくらい確保すればいいのか調べないと…