つけてバックグラウンドで複数常駐させてオラオラしていく。有りでメモリオーバーした場合こんな制限のPod。一緒で、Nodeと同じ容量がみえる。され、後発のスクリプトは正常に処理が完了したそのあと、シェルはどちらも操作できるようになったdmesgちょっと長いけど、メモなので該当部を記載しておく。先生がしゃしゃり出てきて殺られたのがわかる。正常に機能している、ということを確認できた。プロセスを常駐させていくと、7~8個目でどうなるか、という実験。memory.py無事、7プロセス目で死亡を確認。長過ぎるけど、大事なのでファイルで添付しておく。先生が走ったようなログが観測できた。ぶった切られているのがわかる。childわかったことここでわかったフリしても何もないので、次へ行く。予想外のログをみたことで動揺したので、メモリ容量は実体と監視であっているのか、の確認をしておいた。2610Mi気を取り直して、次へ行く。追加で死ぬって状況で、2Pod目を起動してみる。そもそも起動するのか。的には、実体と関係ないただの要求容量の合計値なので、これは想定通り。それが見えるので共通した内容になる。同様のプロセスを1つ起動してみる。検証と同じような結果になった。あとは処理が正常に完了し、シェルも操作できるようになる。時間を含めた完全に同じ内容が記録されていた。Node上ではどのようなことが起きているかまず、メモリオーバーが起きる前の、Node上でのプロセスの下の方を記録。5まさに死んだ瞬間を記録。Pod同様、一時的にフリーズするので、フリーズ解除直後の記録。復活の儀をしているのがわかる。/usr/lib/systemd/systemd-udevdさらに数秒後、何事もなかったようにしれっと色んなプロセスが復活した。完全に同じ内容である。大雑把だけどこんな感じ。全てが殺られる対象となる。よって次のPodが起動するまでに余っているリソースを扱えることは、一見強度が上がるように見える。食った場合はどうなるだろうか。するかによって、無事で済むか、Node破壊が起こるか、のような不安定な運用は採用できるはずがない。アプリケーションのメモリ変動そもそも、WEBサーバーやアプリケーション・サーバーといったデーモンが、どのようにメモリを扱うのか、が先にくる話だったりする。常駐プロセス(やスレッド)数が一定なのか、動的なのか。動的ならば最大値はいくらなのか、不要になった分はどれくらいの期間で削減されていくのか。容量を上回らないように増減する・・・そんなものは存在しないし、工夫で確実になんとかなるものでもないだろう。ただでさえ、アプリケーション・プロセスのメモリ容量は、想定以上に膨れることが多いのに、さらに不安定要素を組み込んでいくのは、あまりに現実的ではない。死にかけるとそこのリソースが一時的にいなくなり、スケールアウトとして機能しないことになる。起動してリソース的にも限界だとしても、スケールアウトしてリソースが増加しているという事実は変わらない。生き死にが不安定ということは、スケールアウトの機能も不安定になるということなので、たとえ全体のキャパシティオーバーが地獄だとしても、少しずつスケールアウトして解決に向かっていくという安定さだけは確保したいところだ。