その Pod 突然落ちても大丈夫ですか！？（OCHaCafe5 #5 実験！カオスエンジニアリング発表資料）

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

- 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です
逆井啓佑

商用環境でバンバン Request が飛んできている Pod、
突然、落ちても大丈夫ですか？？
Introdaction

「突然」とは言わないまでも...
例えば、GKE Upgrade の際には、Pod を落とす場合もあります。※ Upgrade 戦略による
Introdaction
Old New
❶ 新 Node 作成
❷ 新 Node に Pod 作成
❸ 旧 Node の Pod 落とす
❹ 旧 Node 削除

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

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

Pod
Status
Running Terminating
Pod
削除開始
deletionTimestamp
設定
コンテナ
強制終了
(設定されていたら)
preStop 処理
(preStop が終わったら)
SIGTERM 処理
terminationGracePeriodSeconds
経過後
SIGKILL 処理
Service から
Pod へのルーティングが除外
参考(神資料)：アルパカでもわかる安全なPodの終了

Pod
Status
Running Terminating
Pod
削除開始
deletionTimestamp
設定
コンテナ
強制終了
(設定されていたら)
preStop 処理
(preStop が終わったら)
SIGTERM 処理
経過後
SIGKILL 処理
Service から
preStop 処理が不適な場合、
SIGTERM 処理中に Pod に Request
=> Request エラーになり得る
仕掛かり中の Request がある状態で、
SIGTERM / SIGKILL 処理が走る場合がある
=> Request エラーになり得る

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

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

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

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 処理中にリクエストが来る可能性
=> リクエストエラーとなり得る

DEMO
📹 https://drive.google.com/file/d/1igm4DHoiK7lm6PcfTUZSDhpIMRke8w7q/view?usp=sharing

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

記載されている会社名、商品名、
またはサービス名は、各社の商標登録または商標です。

その Pod 突然落ちても大丈夫ですか！？（OCHaCafe5 #5 実験！カオスエンジニアリング 発表資料）

More Related Content

What's hot

More from NTT DATA Technology & Innovation