DMMプラットフォームでは共通インフラ基盤としてk8sを利用しているが、 自チームでアプリケーションのCPU/Memoryの request, lilmitを最適化したらポッドが落とされたので、それをまとめる。
CPU, Memoryの最適化について
以下の記事にあるように事前に負荷試験をして必要なCPU, Memoryを試算した。 CPU使用率でいうと、最適化前は30-60%を推移していたが、最適化後は60-80%で推移するようになった。
OOMで複数個のポッドが落ちた
最適化してからしばらくは元気に動いていたが、Memoryのrequest, limitの値を攻めすぎてしまったせいか、OOMによって複数個のポッドが落ちてしまった（k8sあるある）。
k8sはkube-proxyによって各ポッドにHTTPリクエストが負荷分散されるが、 アプリケーションが載っているGKEはラウンドロビンのように各ポッドに順番に振り分けるのではなく、 ランダムで特定のポッドが選択される（多分）。
- https://kubernetes.io/ja/docs/concepts/services-networking/service/#proxy-mode-iptables
- https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview?hl=ja#kube-proxy
そのため特定のポッドにリクエストが偏り、Memory の limit を超過した結果、ポッドが落ちてしまった（多分）。
でもすぐに回復した
当たり前だが、k8sはポッドが落ちてもすぐに起動してくれる（回復性を備えている）。 今回も数十秒ほどで新規のポッドが立ち上がり、何事もなかったようにリクエストをさばいていた。
こーゆートラブルを経験すると、改めてk8s（というかコンテナ技術）ってスゴイなーと思った。 アプリケーションがGo言語で書かれているので、起動が早いというのも被害を最小限に抑えられた大きな要因になっていると思う。
対策について
今回ダウンしたアプリケーションはそれなりのRPSをさばいており、 数十秒とはいえ落ちると困るので、普通に request, limit を見直しました。
まとめ
今回のような設定ミスに限らず、開発者の意図しない形でポッドが落ちてしまうことはあると思うので、 そういった問題をすぐに回復してくれるコンテナ技術ってスゴイんだなと思いました。
