Pod が終了するときに起きること / What happens when the pod exits

Transcript

1. Pod が終了するときに起きること 1

2. 確認したい処理パターン 2  パターン1  Pod の削除と同時にエンドポイントに接続された新規コネクションが 削除中の Pod に振り分けられること

    パターン2  Pod の削除と同時にエンドポイントに接続された新規コネクションが削除中の Pod に振り分けられること  preStop のスリープ処理により新規コネクションの処理を待ってから Terminate 処理に入ること  パターン3  Pod の削除から若干の時間が経過後(=Service からの切り離し後)、 エンドポイントに接続された新規コネクションが削除中の Pod に振り分けられないこと  新規コネクションが新しい Pod で処理されること  パターン4  SIGTERM 処理を適切に行っているアプリケーションがコネクションを強制的に切断しないこと

3. パターンの詳細 3 パターン アプリケーションの動き 通信と操作 ReplicaSet/Pod のパラメーター 1 1 リクエストに必要な処理時間

   = 10 秒 SIGTERMにかかる時間 = 15 秒 コネクション1の接続 →5 秒後: Pod の削除 と コネクション 2 の新規接続 terminationGracePeriodSeconds: 既定(30秒) preStop: 設定なし ReplicaSet のスケール = 1 2 terminationGracePeriodSeconds: 既定(30秒) preStop: 11 秒間のスリープ + SIGTERMの送信 ReplicaSet のスケール = 1 3 コネクション1 の接続 →5 秒後: Pod の削除 →さらに 1 秒後: コネクション 2 の新規接続 terminationGracePeriodSeconds: 既定(30秒) preStop: 設定なし ReplicaSet のスケール = 1 4 1 リクエストに必要な処理時間 = 20 秒 SIGTERMにかかる時間 = 5 秒 ReplicaSet のスケール = 1 コネクション1の接続 →5 秒後: Pod の削除 terminationGracePeriodSeconds: 既定(30秒) preStop: 設定なし ReplicaSet のスケール = 1

4. アプリケーションのコード  処理の流れ 1. HTTP サーバーの起動(TCP 80番ポート) 2. シグナルの監視 3.

   HTTP コネクション発生時の処理 • リクエストに対する処理(DBアクセス等)を想定 • -d オプションで指定秒数スリープ 4. シグナル受信時の処理 • 終了処理(DBのコネクションクローズ等)を想定 • -t オプションで指定秒数スリープ 5. Web サーバーの動作 • 処理中のコネクションがクローズするまで待機 • 新規接続は受け付けない 4 https://github.com/tsubasaxZZZ/aks-testpod

5. パターン1 5

6. 確認したいこと 6  Pod の削除と同時にエンドポイントに接続された新規コネクションが削除中の Pod に振り分けられること

7. ReplicaSet  ReplicaSet  レプリカ数: 1  イメージ: tsubasaxzzz/signal 

   引数 • -d : 1リクエストに必要な処理時間(秒) = 10 • -t : シグナル処理に必要な処理時間(秒)= 15  Service  80 番ポートで待ち受ける LoadBalancer 7

8. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 8  パターン1 (初期状態)

   Pod A Service コネクション 1 が新規接続 <時間の流れ> Pod Aの時間の流れ 処理残り時間: 10 秒

9. 9 <Pod> <実行コマンド> k logs $(k get po -ojsonpath="{.items[0].metadata.name}") -f

   <ログ確認用コマンド>

10. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 10  パターン1 (5

    秒後) Pod A Service コネクション 2 が新規接続 Pod Aの削除開始 • SIGTERMの受信 Pod Aの時間の流れ <時間の流れ> 処理残り時間: 5 秒 処理残り時間: 10 秒 SIGTERM 処理残り時間: 15 秒 Pod B Service からの切り離し 開始 Pod B の作成開始 Pod B のService の追加開始

11. 11 <Pod> <signal-5gt84 のログ> • delete と同時に Terminating 状態と なり、また新しい

    Pod が作成され始める ※delete 実行から数秒後に作成開始 • 5秒間はコネクション1のみ • 5秒後にコネクション2と同時に SIGTERM の受信 $ ./pattern_1-2.sh Connection start: duration=10, hostname=signal-5gt84, requestURI=/client1 Connection start: duration=10, hostname=signal-5gt84, requestURI=/client2 pod "signal-5gt84" deleted <curl の出力> • 5秒後にコネクション2が出力 • どちらも 同じ Pod で処理されてい ることが分かる • Pod の削除開始

12. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 12  パターン1 (10

    秒後) Pod A Service Pod Aの削除中 • SIGTERM の処理中 Pod Aの時間の流れ <時間の流れ> 処理終了 処理残り時間: 5 秒 SIGTERM 処理残り時間: 10 秒 コネクション 1の処理終了 コネクション 2の処理中 Pod B Service からの切り離し 完了 Pod B の作成完了 Pod B のService の追加完了

13. 13 <Pod> <signal-5gt84 のログ> • コネクション1の処理終了 • コネクション2の処理中(5秒経過) • SIGTERM

    処理中(5秒経過) • signal-pq9k2 の作成完了 ※厳密に10秒後ではない

14. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 14  パターン1 (15

    秒後) Pod A Service Pod Aの削除中 • SIGTERM の処理中 Pod Aの時間の流れ <時間の流れ> 処理終了 処理終了 SIGTERM 処理残り時間: 5 秒 コネクション 2の処理終了 Pod B

15. 15 • コネクション2の処理終了 • SIGTERM 処理中(10秒経過) <Pod> <signal-5gt84 のログ>

16. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 16  パターン1 (20

    秒後) Service Pod Aの削除完了 Pod Aの時間の流れ <時間の流れ> 処理終了 処理終了 SIGTERM 処理終了 Pod B

17. 17 • SIGTERM 処理終了 <signal-5gt84 のログ> • signal-5gt84 の削除完了 ※実際はさらに数秒後に削除

    <Pod>

18. パターン2 18

19. 確認したいこと 19  Pod の削除と同時にエンドポイントに接続された新規コネクションが削除中の Pod に振り分けられること  preStop のスリープ処理により新規コネクションの処理を待ってから

    Terminate 処理に入ること

20. ReplicaSet  ReplicaSet  レプリカ数: 1  イメージ: tsubasaxzzz/signal 

    引数 • -d : 1リクエストに必要な処理時間(秒) = 10 • -t : シグナル処理に必要な処理時間(秒)= 15  preStop • コネクションの処理を待つための 11 秒間の待機  Service  80 番ポートで待ち受ける LoadBalancer 20

21. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 21  パターン2 (初期状態)

    Pod A Service コネクション 1 が新規接続 <時間の流れ> Pod Aの時間の流れ 処理残り時間: 10 秒

22. 22 <Pod> <実行コマンド> k logs $(k get po -ojsonpath="{.items[0].metadata.name}") -f

    <ログ確認用コマンド>

23. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 23  パターン2 (5

    秒後) Pod A Service Pod Aの時間の流れ <時間の流れ> 処理残り時間: 5 秒 preStop 処理開始 Pod B Pod B の作成開始 Pod B の Service の追加 開始 Service からの切 り離し開始 Pod Aの削除開始 • preStop 処理の開始 • SIGTERMの待機 • preStop 処理により Service からの切り離し 開始から切り離し終了ま で待機 • Service からの切り離し 中に入ってきた新規コネ クションの処理を完了さ せる • preStop 処理が完了す るまで SIGTERM の送信 は待機される コネクション 1 の処理中 コネクション 2 がエンドポイン トに新規接続

24. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 24  5.x 秒後

    Pod A Service Pod Aの時間の流れ <時間の流れ> 処理残り時間: 5 秒 Pod B Pod B の作成開始 Pod B の Service の追加 開始 Service からの切 り離し開始 Service からの切り 離し中に Pod に入っ てくるコネクション2 コネクション 1 の処理中 • Service からの切り離し 中に Pod に入ってくるコ ネクションの処理が完了 するまで待つ 処理残り時間: 10 秒 Pod Aの削除開始 • preStop 処理中 • SIGTERMの待機 preStop 処理中 処理残り時間: 11 秒

25. 25 <Pod> <signal-pn6pv のログ> • preStop 処理(11秒間のスリープ)により、 "Terminate start"のログは無い

26. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 26  10秒後 Pod

    A Service Pod B Pod B の作成完了 Pod B のService の追加完了 Pod Aの時間の流れ <時間の流れ> 処理終了 Service からの切 り離し完了 Service からの切り 離し中に Pod に入っ てくるコネクション2 コネクション 1 の処理完了 処理残り時間: 5 秒 preStop 処理中 処理残り時間: 6秒 Pod Aの削除開始 • preStop 処理中 • SIGTERMの待機

27. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 27  16 秒後(preStop

    処理の終了) Service Pod B Pod Aの時間の流れ <時間の流れ> 処理終了 Service からの切り 離し中に Pod に入っ てくるコネクション2の 処理が完了 処理終了 preStop 処理終了 Pod Aの削除開始 • preStop 処理完了 • SIGTERM送信 Pod A SIGTERM 送信開始

28. 28 • delete コマンドの実行 • preStop の実行開始(11秒のスリープ) • preStop の終了

    • Terminate の開始 • コネクション2の処理終了

29. パターン3 29

30. 確認したいこと 30  Pod の削除から若干の時間が経過後(=Service からの切り離し後)、エンドポイ ントに接続された新規コネクションが削除中の Pod に振り分けられないこと 

    新規コネクションが新しい Pod で処理されること

31. ReplicaSet  ReplicaSet  レプリカ数: 1  イメージ: tsubasaxzzz/signal 

    引数 • -d : 1リクエストに必要な処理時間(秒) = 10 • -t : シグナル処理に必要な処理時間(秒)= 15  Service  80 番ポートで待ち受ける LoadBalancer 31

32. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 32  パターン3 (初期状態)

    Pod A Service コネクション 1 が新規接続 <時間の流れ> Pod Aの時間の流れ 処理残り時間: 10 秒

33. 33 <Pod> <実行コマンド> k logs $(k get po -ojsonpath="{.items[0].metadata.name}") -f

    <ログ確認用コマンド>

34. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 34  パターン3 (5

    秒後) Pod A Service Pod Aの削除開始 • SIGTERMの受信 Pod Aの時間の流れ <時間の流れ> 処理残り時間: 5 秒 SIGTERM 処理残り時間: 15 秒 Pod B Service からの切り離し 開始 Pod B の作成開始 Pod B のService の追加開始 コネクション 1の処理中

35. 35 <Pod> <signal-wpvjc のログ> • delete と同時に Terminating 状態と なり、また新しい

    Pod が作成され始める ※delete 実行から数秒後に作成開始 • 5秒間コネクション1のみ • 5秒後にSIGTERM の受信 ※コネクション2のログは無い $ ./pattern_3.sh Connection start: duration=10, hostname=signal-wpvjc, requestURI=/client1 pod "signal-wpvjc" deleted <curl の出力> • Pod の削除開始

36. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 36  パターン3 (6

    秒後) Pod A Service Pod Aの時間の流れ <時間の流れ> 処理残り時間: 4 秒 SIGTERM 処理残り時間: 14 秒 Pod B Pod B の作成開始 Pod B のService の追加開始 Service からの切り離し 完了 コネクション 2 が新規接続試行 ※Pod Bが作成されるまでコネク ションは保留 コネクション 1の処理中 Pod Aの削除中 • SIGTERM の処理中

37. 37 <signal-wpvjc のログ> • コネクション2のログは無い

38. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 38  パターン3 (Pod

    B の作成完了後) Pod A Service Pod B Pod B の作成完了 Pod B のService の追加完了 コネクション 2 が新規接続 コネクション 1の処理終了 Pod Aの削除中 • SIGTERM の処理中 Pod Aの時間の流れ <時間の流れ> 処理終了 SIGTERM 処理残り時間: 10 秒 (コネクション 2 は Pod B で処理開始)

39. 39 <Pod> コネクション 2 の処理 <signal-rj2rr のログ> 新しく作られた Pod ！

40. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 40  パターン3 (15

    秒後) Pod A Service Pod Aの削除中 • SIGTERM の処理中 Pod Aの時間の流れ <時間の流れ> 処理終了 SIGTERM 処理残り時間: 5 秒 コネクション 2の処理中 Pod B

41. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 41  パターン3 (20

    秒後) Service Pod Aの削除完了 Pod Aの時間の流れ <時間の流れ> 処理終了 SIGTERM 処理終了 コネクション 2の処理中 Pod B

42. パターン4 42

43. 確認したいこと 43  SIGTERM 処理を適切に行っているアプリケーションがコネクションを強制的に切 断しないこと

44. ReplicaSet  ReplicaSet  レプリカ数: 1  イメージ: tsubasaxzzz/signal 

    引数 • -d : 1リクエストに必要な処理時間(秒) = 20 • -t : シグナル処理に必要な処理時間(秒)= 5  Service  80 番ポートで待ち受ける LoadBalancer 44

45. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 45  パターン4 (初期状態)

    Pod A Service コネクション 1 が新規接続 <時間の流れ> Pod Aの時間の流れ 処理残り時間: 10 秒

46. 46 <Pod> <実行コマンド> k logs $(k get po -ojsonpath="{.items[0].metadata.name}") -f

    <ログ確認用コマンド>

47. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 47  パターン4 (5

    秒後) Pod A Service Pod Aの削除開始 • SIGTERMの受信 Pod Aの時間の流れ <時間の流れ> 処理残り時間: 15 秒 SIGTERM 処理残り時間: 5 秒 Pod B Service からの切り離し 開始 Pod B の作成開始 Pod B のService の追加開始 コネクション 1の処理中

48. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 48  パターン4 (10

    秒後) Pod A Service Pod Aの削除開始 • SIGTERMの処理終了 • コネクションの受付不可 Pod Aの時間の流れ <時間の流れ> 処理残り時間: 10 秒 SIGTERM 処理終了 Pod B Service からの切り離し 終了 Pod B の作成開始 Pod B のService の追加開始 コネクション 1の処理中

49. ReplicaSet スケールイン時の動作・手順について kubectl delete pod をした時の流れ 49  パターン4 (20

    秒後) Pod A Service Pod Aの削除完了 Pod Aの時間の流れ <時間の流れ> 処理終了 SIGTERM 処理終了 Pod B Service からの切り離し 終了 Pod B の作成開始 Pod B のService の追加開始 コネクション 1の処理終了

50. 50 • delete コマンドの実行 • Terminate 処理の開始 • Terminate 処理の終了

    • 処理中のコネクションは継続

51. 番外編: terminationGracePeriodSeconds の動き 51

52. 52 • delete コマンドの実行 • Terminate 処理の開始 • 30秒で強制的に終了 terminationGracePeriodSeconds

    の既定の 30 秒を過ぎると KILL が 送られる Connection start: duration=40, hostname=signal-2plwk, requestURI=/client1 pod "signal-2plwk" deleted curl: (18) transfer closed with outstanding read data remaining 強制的にコネクションが終 了した場合の curl の出力

53. 53 • delete コマンドの実行 • Terminate 処理の開始 • 全ての処理が完了 terminationGracePeriodSeconds

    の値を 60 秒に設定