経験としてはいい話かもしれないが、あまりぶち当たりたくないので、先に結論を書いておく。
CPUはケチるな、CPUがノードに用意できないなら、ノードを追加して、総数を増やせ！
と言いたい。
普段の検証の時に、わざわざマルチコントールプレーン、まるちノードを立てる必要がないので、シングルノードでテストしている。とはいえ、minikubeやkindを使いたくないので、k3sがライトウェイトで１ノードできるから便利で使っている。
コンテナの構築が結構簡単なので、打ち出の小槌のようにバンバン立ててしまうこともある。しかし、シングルノードなので、リソースは限られている。つまり、「底なし沼」のように見えてしまうが、明らかに「底」がある。なので、そういう使い方だとこれでもかぁというくらい大きいリソースで作った方がいいような気がする。
シングルノードで作る場合、やってしまうトラブルの１つとして、リソースが足りなくてコンテナが立ち上がらないことがある。
閑話休題
リソースの利用状況は以下のコマンドで確認可能である。ただし、Vanilla Kubernetesでは、metric serverをどうにかしてインストールする必要がある。（結構どうにかする必要があった気がする。）
k3sはデフォルトで入っているのでkubectl topは普通に使える。
ノードのリソースを表示
kubectl top node
Podのリソースの表示
kubectl top pod -A
しかし、このkubectl topは、実はあんまり役に立たなかったりする。実際は、kubernetes daashboard向けにつくっているのではないかと。
CPUのリソースが不足しているケース
さて、実際にリソースを枯渇させてみた。デモとして、CPUを枯渇させてみる。
kubectl get pod -n postgres6-test
Pendingになってしまっている。
kubectl -n postgres6-test describe pod my-release-postgresql-0
CPUのリソースが足りないと出ている。実際kubectl topで調べてみるとリソースは全然ガラ空きである。
krewをインストールして、resource-capacityをインストールして、Resource-capacityを表示させてみると
この環境は、2CPU(つまりKubernetesのリソース単位で2000m)のノードで、予約済みリソースが枯渇している。なので、立ち上がらないことがわかる。
つまり、リソースにはやはり「底」がある。
こうみると、このようなユースケースの場合、メモリよりもCPUなのかもしれない。ノードを追加すれば解決する可能性がある。
ノードの空き容量が不足しているケース
次に、もう一つやらかす（自分だけかもしれないが）のが、ノードの空き領域がすくなくて、展開できないケース。
自分のUbuntuのVMテンプレートは、16GB HDDで、半分しかLVMでアロケートしていないので実質8GBしかなく、空き容量は4GB程度しかない。なので、HDDとLVM、ファイルシステムを拡張して使う必要がある。忘れると。。。
kubectl get pod
エラーとなっている。
kubectl -n longhorn-system describe pod csi-resizer-6d8cf5f99f-2sdtx
ディスクが足りないと表示されているのがわかる。ノードの空き領域が足らないために起きる。
また、以下のような状態のときもノードの空き領域が足りないために起こる。
ノードには、コンテナイメージが置かれるので、ノードの空き領域はかなり多く必要となる。不要になった領域が定期的に削除されるので、無尽蔵に消費されるわけではない。
ディスク容量が少ない場合も内蔵ディスクが大きいノードを追加すれば解決すると思われるが、内臓ディスクが小さいノードはいくらCPUを積んでいても使われる可能性がすくないので、そのノードを一旦削除して、内臓ディスクを増強してから再度、クラスタに参加させるといいと思う。
あとは、コンテナを作る時、リソースの定義をちゃんとしておくべきかなと思う。
https://kubernetes.io/ja/docs/tasks/configure-pod-container/assign-cpu-resource/
https://kubernetes.io/ja/docs/concepts/configuration/manage-resources-containers/
まぁ知っておいた方がいい話だが、あまり遭遇したい話でした。