【第五弾】Kubernetesベストプラクティス：Graceful Shutdown

ベストプラクティス第五弾

こんにちは、jackです。

Kubernetesベストプラクティスも後半戦です。
今回はKubernetesがどのようにPodを終了するのか、1ステップずつ見ていきます。

Kubernetes best practices: terminating with grace

TL;DR

• 常に正常終了処理するアプリケーションを作れ
• Kubernetesのtermination lifecycleは
  • Terminating State
  • preStop Hook
  • SIGTERM
  • terminationGracePeriod (30秒)
  • SIGKILL

もっと詳しく

Kubernetesのtermination lifecycle

Kubernetesはアプリケーションのモニタリングはもちろんのこと、複数マシーンにアプリケーションをデプロイしたり、違うバージョンを同時に走らせたり、多くの面倒を見てくれます。

その中で、Kubernetesは異常のないPodを終了することがあります。
どういったことかと言うと、例えばアプリケーションのアップデートがありrolling updateを行えば、Kubernetesは次第に古いPodを落としつつ、アップデートされたバージョンのPodを作成します。また、Nodeのリソースが足りなくなればPodを終了し、不足したリソースを確保することもあります。

つまり、アプリケーションがいかなる状態でも正常終了の処理することが重要になります。実際には、SIGTERMを受け取り、データを保存し、コネクションをクローズするといった処理をしっかり考慮することです。

では、実際にPodが終了する時系列順に見ていきましょう。

Terminating State

PodがTerminatingというステータスになります。この時点で、新しいトラフィックの受信はなくなります。

preStop Hook

Terminatingと同時。
このpreStop HookはContainer hooksの一種で、PodがTerminatingステータスになったと同時に送られます。

SIGTERM

Terminatingと同時。
SIGTERMシグナルがPod内のコンテナに送られます。
アプリケーションはこのSIGTERMを受け取り、正常終了するようにしましょう。

*preStop hookを使っている場合でも、SIGTERMを受け取ったときの処理をしっかりテストしましょう。

terminationGracePeriod

PodがTerminatingステータスになってからカウントダウンされる時間です。デフォルトで30秒です。
preStop hookとSIGTERMの挙動にかかわらず、指定時間内に正常終了されるように注意しましょう。
デフォルトの30秒以上の時間が必要な場合は、terminationGracePeriodをPodのYAMLに定義しましょう。以下は60秒の例です。

pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: busybox
  terminationGracePeriod: 60

SIGKILL

terminationGracePeriodが終わったら、SIGKILLシグナルがPodに送られます。この時点で、Kubernetesのオブジェクトがクリーンアップされます。

まとめ

さて、Podが終了する過程を時系列順に見てきましたが、見ていくと意外とシンプルだったのではないでしょうか。
いかなる状況でも正常終了する処理をすることを忘れず、terminationGracePeriodを過ぎそうなら時間を伸ばせばよいですね。

それでは、また次回。