Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kubernetes Meetup Tokyo #69 LT - PreStopによるSlee...
Search
na2na
February 05, 2025
0
35
Kubernetes Meetup Tokyo #69 LT - PreStopによるSleep中に何が起きているか:~安全なRollingUpdateの実施のために~
na2na
February 05, 2025
Tweet
Share
More Decks by na2na
See All by na2na
OAuth 2.1 + PKCEのススメ ~Spotify APIを通して理解する、OAuth 2.1 + PKCEの基礎と実践~
na2na
2
490
Oracle Cloudで自宅クラウド構築:ブロックボリュームのスループット改善編
na2na
0
53
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
32
6.4k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
6
220
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
520
A Philosophy of Restraint
colly
203
16k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
11
900
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
GraphQLとの向き合い方2022年版
quramy
44
13k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.2k
Done Done
chrislema
182
16k
Transcript
合同会社DMM.com プラットフォーム開発本部 なずな (@na2na_chang) 1 PreStopによるSleep中に何が起きているか ~安全なRollingUpdateの実施のために~
⾃⼰紹介 なずな(@na2na_chang) ➢ 合同会社DMM.com(2024年新卒) ◦ プラットフォーム開発本部 マイクロサービスアーキテクトグループ 認可チーム ➢ 認可プロダクトをリプレースするお仕事
◦ PHP → Go ◦ MySQL → TiDB Cloud ◦ オンプレ → GKE ➢ 最近の悩み: おうちKubernetesのコスパのいい監視基盤の作り⽅ 2
今⽇話すこと preStopのSleep中にPodへのトラフィックが⽌まる仕組み 3
調査のきっかけ 保守しているアプリケーションは、Kubernetesを利⽤して運⽤しています。 無停⽌での更新を⾏う必要があるため、基本的にはRollingUpdateを採⽤しています。 RollingUpdateの最中に起きていることについて調べる中で、 preStop中にServiceから外れるという話⾃体はみかけるものの、仕組みまではわかりませんでした。 詳しく知りたかったのでKubernetesコードを⾒たり、GKEで実験したりしました。 4
ポイント preStop • コンテナを停⽌する前に実⾏される 前処理を定義できる機能 ◦ 任意のコマンドを実⾏するExec ◦ コンテナ上の任意のエンドポイントに リクエストを送るHttp
◦ 指定秒数の間「何もしない」をするSleep 5
PreStopによるSleep中に何が起きているか 結論 Podが終了する前に、終了予定Podが トラフィックの対象から外れるまでの時間稼ぎをしている 6
PreStopによるSleep中に何が起きているか 具体的には、 1. Podの更新イベントが発⽕する(.metadata.deletionTimestampが付与される) 2. 1のイベントを受けてEndpointSlice Controllerが削除予定Podを⽰すEndpointの Conditions.readyをfalseに変える 3. 2のイベントを受けてkube-proxyが削除予定Podをiptablesのエントリに含めないようにする
という処理になっています 7
PodにdeletionTimestampが付与されます これにより、PodがTerminatingとして 扱われるようになります これは、Podの更新イベントです。 ArgoCDから⾒る Podのmetadataフィールドに deletionTimestampがセットされた時の様⼦→ 削除予定PodがTrafficの対象から外れるまで: その1 8
削除予定PodがTrafficの対象から外れるまで: その2 Podの更新イベントを受けて、 EndpointSlice Controllerが 該当EndpointのConditions.readyを falseにセットします。 Podがterminatingであればreadyはfalseになる、という処理 kubernetes/kubernetes master(5aeea45
modified): staging/src/k8s.io/endpointslice/utils.go:L42付近→ 9
削除予定PodがTrafficの対象から外れるまで: その3 EndpointSliceの更新をうけて、 kube-proxyがEndpointの再評価と、 iptablesに書き込むルールの組み⽴てと 更新をします。 EndpointとしてReadyでなければルーティングの対象にしない処理 kubernetes/kubernetes master(5aeea45 modified):
pkg/proxy/topology.go:L46-L48付近→ ※他に通信を受けるべきPodがServiceに存在しない場合はその限りでない 10
参考: 実験していた様⼦の⼀部 以下の条件 - GKE 通常クラスター - v1.30系 - Dataplane
V2無効 - CNIはCalico - PreStop: PodLifecycleSleepAction 30s HTTP KeepAlive無効にしたクライアントで Pod→Serviceでひたすらにリクエスト& Nodeに潜り込んでiptablesのエントリ確認 11
おわりに この登壇を⾒た⽅が、 「Sleepの間に古いPodがServiceから外れるまで待つ」というのはよく⾒るんだけれども、 どういう原理になっていたのかは今初めて理解できた、 という感想になったら嬉しいです。 OSSでGoのソースコードリーディングは初めてなので苦戦しました。 ここ間違っているよ!等あればX ( @na2na_chang )まで教えていただけますと幸いです。
12
Appendix 13
RollingUpdate発⽕後の全体の流れ 14 各コンポーネント間の前後関係は厳密なものではありません。