実験編2020/12/18に公開2020/12/22Kubernetestechこれはなにこの記事はアルパカでもわかる安全なPodの終了の続編です。前回は、Podの終了時の動作をKubernetesの各種コンポーネントの仕組みを踏まえつつ考察しました。Deploymentのローリングアップデートを行うとPodの再起動を伴うことになりますが、このときリクエストを欠損なく処理するために、以下2つの対策が有効であることが分かりました。Shutdownこの記事では、Deploymentのローリングアップデートをオンラインで実際に行い、上記対策が本当に有効かどうかを確かめていきます。2020の18日目です。上述のとおり、Podが安全に終了するためにできることは大きく2つがあります。以下にそれぞれの概要を記します。内部的な動作の詳細については、前回の記事を参照ください。preStopフックでのスリープpreStopフックは、コンテナを停止する前に実行される前処理(フック)を定義する機能です。行うと、コンテナが停止される前に指定した時間だけ待機する動作になります。これによって、Podへのトラフィックの配送が止まってから(サービスアウトしてから)終了処理に入るようにすることができます。ここで注意すべき点は、サービスアウトとpreStopフックに依存関係は持たせられず、サービスアウトを確認してからpreStopフックを抜けるといったような制御はできないことです。このため、コンテナの終了処理をサービスアウトの後に行う、ということを保証することはできません。Shutdownをアプリケーションに実装すると、アプリケーションのシャットダウンが開始されたとき、その時点で受け付けているリクエストが処理されてからプロセスを終了するということが保証できます。アプリケーションのシャットダウンが開始されて以降は、新たにリクエストを受け付けることはできないことに注意してください。それでは、これら2つの対策がローリングアップデート中のエラーの抑制に役立つのか、実験して確かめていきたいと思います。実験してみた!実験の流れ実験用のアプリケーションをKubernetesクラスターにデプロイしておき、一定量のトラフィックを送ります。