【OCHaCafe#5】その Pod 突然落ちても大丈夫ですか？

Kubernetes基盤において、
Podが終了する際の挙動と、安全に落とす方法について調査・検証しました。
また、安全に終了する設定がなされていないPodをChaos Meshで炙り出すデモをしました。

Transcript

1. - 2022/05/11
   - NTT DATA
   - Keisuke SAKASAI @k6s4i53rx
   © 2022 NTT DATA Corporation
   Oracle Cloud Hangout Cafe #5
   LT: その Pod 突然落ちても大丈夫ですか　　
   !?
   

   View Slide

2. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
   Who am I
   - 2022/05/11 Oracle Cloud Hangout Cafe -
   逆 井 啓 佑
   さかさ い
   © 2022 NTT DATA Corporation
   　Company：
   - NTT DATA Corporation
   　Work：
   - 決済システムの Product Owner と 非機能 Test (約半年間)
   - Kubernetes を始めとするモダンな技術スタック ...
   　Description：
   - 先日、業務内の GKE Upgrade 時に勉強した、
   「Pod の正常終了」について
   簡単にまとめて、LT しようと思います。
   　　　
   k8s 超基本!!
   なお話になります...
   が大事なTopicです
   逆 井 啓 佑
   

   View Slide

3. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
   商用環境でバンバン Request が飛んできている Pod、
   突然、落ちても大丈夫ですか？？
   Introdaction
   

   View Slide

4. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
   「突然」とは言わないまでも...
   例えば、GKE Upgrade の際には、Pod を落とす 場合もあります。※ Upgrade 戦略による
   Introdaction
   Old New
   ❶ 新 Node 作成
   ❷ 新 Node に Pod 作成
   ❸ 旧 Node の Pod 落とす
   ❹ 旧 Node 削除
   

   View Slide

5. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
   「突然」とは言わないまでも...
   例えば、GKE Upgrade の際には、Pod を落とす 場合もあります。※ Upgrade 戦略による
   Introdaction
   Old New
   ❶ 新 Node 作成
   ❷ 新 Node に Pod 作成
   ❸ 旧 Node の Pod 落とす
   ❹ 旧 Node 削除
   落とした Pod が決済リクエストを処理中だった場合、
   そのリクエストはどうなるのか？正常に決済は終了できるのか？
   上記ついて、「Pod が落ちる」を踏み込んで理解することで考えます。
   

   View Slide

6. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
   Pod が落ちる
   Pod が落ちる際の挙動
   Pod の Shutdown
   プロセス実行
   ❶
   Service から Pod への
   ルーティング削除
   ReplicaSet や
   Deployment
   管理下からの除外
   ❷ ❸
   replicas=3
   New!!
   これら３つの処理が、非同期に実行される。
   ここで、❷ のルーティング削除 => ❶ の Shutdown プロセス実施といった 順序制御はない 。
   preStop SIGTERM
   SIGKILL
   削除開始
   強制終了
   .terminationGracePeriodSeconds
   デフォルト: 30 秒
   preStop は
   最期にコンテナで
   実行される処理
   Pod に .deletionTimestamp が設定
   

   View Slide

7. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
   Pod が落ちる際の挙動
   Pod
   Status
   Running Terminating
   Pod
   削除開始
   deletionTimestamp
   設定
   コンテナ
   強制終了
   (設定されていたら)
   preStop 処理
   (preStop が終わったら)
   SIGTERM 処理
   terminationGracePeriodSeconds
   経過後
   SIGKILL 処理
   Service から
   Pod へのルーティングが除外
   .terminationGracePeriodSeconds
   デフォルト: 30 秒
   参考(神資料)：アルパカでもわかる安全なPodの終了
   

   View Slide

8. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
   Pod が落ちる際の挙動
   Pod
   Status
   Running Terminating
   Pod
   削除開始
   deletionTimestamp
   設定
   コンテナ
   強制終了
   (設定されていたら)
   preStop 処理
   (preStop が終わったら)
   SIGTERM 処理
   terminationGracePeriodSeconds
   経過後
   SIGKILL 処理
   Service から
   Pod へのルーティングが除外
   .terminationGracePeriodSeconds
   デフォルト: 30 秒
   preStop 処理が不適な場合、
   SIGTERM 処理中に Pod に Request
   => Request エラーになり得る
   仕掛かり中の Request がある状態で、
   SIGTERM / SIGKILL 処理が走る 場合がある
   => Request エラーになり得る
   

   View Slide

9. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
   Pod が落ちる際のアプローチ
   Pod
   Status
   Running Terminating
   Pod
   削除開始
   deletionTimestamp
   設定
   コンテナ
   強制終了
   ❶ preStop 処理
   => Request を受け付けなく
   なるまで十分 sleep
   SIGTERM 処理
   terminationGracePeriodSeconds
   経過後
   SIGKILL 処理
   Service から
   Pod へのルーティングが除外
   .terminationGracePeriodSeconds
   デフォルト: 30 秒 => 十分長く
   ❷ Request 処理中のプロセスは、
   完了してから Shutdown する
   => Graceful Shutdown
   ❸ Request の処理が十分終わる
   terminationGracePeriodSeconds を設定し、
   SIGKILL されないようにチューニング
   

   View Slide

10. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
    Pod が落ちる際のアプローチ
    この対応により、基本的に Request エラーとならず、Pod を落とすことができる
    ■ Kubernetes 側の設定：
    ● 適切な時間 preStop 処理で sleep 設定する
    ● Pod が落ちる際に、仕掛かり中のリクエストが処理し切れる時間に、
    terminationGracePeriodSeconds をチューニングする
    ■ Application 側の設定：
    ● SIGTERM を受領しても、
    仕掛かり中のプロセスが完了してから、Shutdown するように実装
    今回は、終了にフォーカスしていますが、
    　 Pod の同時存在最低数を定義する、Pod Disruption Budget や、
    　 Pod が Ready になってから Request を受け付ける、Rediness Probe もあります (基本)
    !
    

    View Slide

11. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
    最後に、展開として
    このような設定を、システムを構成する各 MS で行い、
    商用影響なく Pod が落とすことができる(前述した戦略での GKE Update 等も乗り切れる) 必要がある。
    => 大規模な場合、MS の数/新規追加される MS の数、
    　 .
    またそれら開発チームも膨大となり、横並びでの確認/統制が課題となる。
    .
    =>　　　Chaos Mesh　で無作為に Pod に擬似障害(=突然落とす)を起こし、設定漏れ/ミスを把握する
    Pod 障害
    詳細は Main Session で !!
    => 自動的に 設定漏れを炙り出す仕組み が必要
    

    View Slide

12. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
    DEMO の設定
    10 秒間隔でランダムに
    Pod を落とす
    ❶ preStop
    処理実装
    ❷ preStop
    処理未実装
    HTTP Request
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: graceful
    labels:
    app: graceful
    spec:
    replicas: 3
    selector:
    matchLabels:
    app: graceful
    template:
    metadata:
    labels:
    app: graceful
    spec:
    containers:
    - name: graceful
    lifecycle:
    preStop:
    exec:
    command: ["sh", "-c", "sleep 3"]
    preStop 処理を実装した Pod の Manifest
    ❶ preStop で 3 秒 sleep するため、ルーティング除外後に SIGTERM
    ❷ preStop がないため、SIGTERM 処理中にリクエストが来る可能性
    => リクエストエラーとなり得る
    

    View Slide

13. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
    DEMO
    📹 https://drive.google.com/file/d/1igm4DHoiK7lm6PcfTUZSDhpIMRke8w7q/view?usp=sharing
    

    View Slide

14. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
    終わり
    ✔ GKE Upgrade などで、
    　 商用環境の Pod を落とさなければいけないユースケースがある
    ✔ 適切な設定をすることで、Request 処理中の Pod でも
    　 エラーなく正常に落とすことができる。基本的な設定であるので忘れずに...
    ✔ 設定漏れがないか横並びで確認するために、Chaos Mesh は有効かも 👀 !?
    

    View Slide

15. - 2022/05/11 Oracle Cloud Hangout Cafe - © 2022 NTT DATA Corporation
    記載されている会社名、商品名、
    またはサービス名は、各社の商標登録または商標です。
    

    View Slide