概要
Kubernetesで、高負荷な作業をすると、ノードがNot Readyとなり、操作を受け付けなくなったということはありませんか。
私はよくあります。
ここでは、このように高負荷な作業をしても、ノードが不安定にならないための方法を紹介します。
環境
- Kubernetes 1.8
原因
そもそも、なぜノードがNot Readyになるのかを考えてみました。
いくつか原因はあると思いますが、高負荷の場合では、メモリが枯渇する、またはPodの方の処理にCPUが使われてKubernetesのマスターサーバとの疎通ができていないということが考えられます。
メモリが枯渇するというのは、ノードのメモリを増やしたり、使っているイメージや使い方を工夫してメモリをあまり使わないようにするということしか、対処法が考えられないので、ここでは触れません。
では、CPUへの不可の場合はどうしたらいいのでしょうか。
調べてみると、kube-reserved
とsystem-reserved
というものがあり、これを使うと解決できそうだということが分かりました。
対策
kube-reserved
は、Kubernetesシステムデーモンで利用するリソースを予約するものです。
system-reserved
は、sshdやudevなどのOSのシステムデーモンが利用するリソースを予約するためのものです。
これをkubeletのフラグに指定することで、ノードの安定のために使われるリソースの予約ができます。
--kube-reserved=cpu=200m,memory=100Mi,ephemeral-storage=1Gi
--system-reserved=cpu=200m,memory=100Mi,ephemeral-storage=1Gi
実際には、これは1行で書くことになると思いますが、ここでは分かりやすいように改行を入れています。
cpu=
には、予約しておくCPU、memory=
には、予約しておくメモリ、ephemeral-storage=
には、一時的に利用するストレージの量を指定します。
こうすることで、Podが高負荷になってマスターサーバとの通信に支障をきたしそうになっても、ノードの安定のためにリソースが予約されているため、ノードがNot Readyにはなりにくくなりました。
リソースが予約されているため、今回cpu=200m,memory=100Mi
を指定した場合、CPU2コア(2000m)、メモリ4GBのノードを実際に使えるのは、CPU1600m、メモリ3.6GBになります。
このように、Podが使えるリソースの量が減るので気をつけておいたほうがいいでしょう。
さいごに
Kubernetesは、環境が仮想化されているため、デバッグが難しいです。
そのため、デバッグをしなくても済むように不具合が発生しないような対策をして、なるべく安定して動くことを目指していけたらと思います。