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
段階的リリースを実現する kube canary
Search
Hayato Kawai
February 25, 2025
1
64
段階的リリースを実現する kube canary
Wantedly Tech Night #8 での登壇資料です
イベントページ:
https://wantedly.connpass.com/event/341010/
Hayato Kawai
February 25, 2025
Tweet
Share
More Decks by Hayato Kawai
See All by Hayato Kawai
Trace Metrics と Istio Metrics でサービス健全性を監視する
fohte
0
44
巨大 tfstate に立ち向かう技術
fohte
1
400
RubyKaigi で LT 初登壇したきっかけと感想
fohte
1
990
Datadog Logs を活用して SLO 監視基盤を構築する
fohte
3
1.5k
The Journey of rubocop-daemon into RuboCop
fohte
1
1.2k
Ruby as Shell script
fohte
1
540
rubocop-daemon 裏話: OSS の苦悩
fohte
2
610
RuboCop Server Mode の仕組み
fohte
1
310
Ruby を使ったプロダクト開発を支えるオブザーバビリティ基盤
fohte
2
160
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
GitHub's CSS Performance
jonrohan
1030
460k
How to Think Like a Performance Engineer
csswizardry
22
1.4k
Fireside Chat
paigeccino
34
3.2k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
4 Signs Your Business is Dying
shpigford
182
22k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
Bash Introduction
62gerente
611
210k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
560
Art, The Web, and Tiny UX
lynnandtonic
298
20k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
A designer walks into a library…
pauljervisheath
205
24k
Transcript
© 2025 Wantedly, Inc. 段階的リリースを実現する kube canary Wantedly Tech Night
#8 2025-02-25 - Hayato Kawai (@fohte)
© 2025 Wantedly, Inc. 自己紹介 名前 Fohte (ふぉーて) 本名: 川井
颯人 (Hayato Kawai) 所属 ウォンテッドリー株式会社 Infra Squad 趣味 🎮 🎹
© 2025 Wantedly, Inc. 持ち帰ってほしいこと • canary release というデプロイ手法が便利 ◦
ウォンテッドリーではこれを実現するためのツールを内製している
© 2025 Wantedly, Inc. canary release とはなにか
© 2025 Wantedly, Inc. canary release って何? • 新しいバージョンの実装を、 本番環境に部分的に反映していく
リリース手法 ◦ 本番稼動している既存バージョンのトラフィックの数 % だけ新しいバージョンのものを流す • 「カナリアリリース」とも呼ばれる 新 バージョン 旧来 バージョン エンドユーザー 3 % 97 %
© 2025 Wantedly, Inc. どういうときに便利か • 影響範囲の広い変更をリリースしたいとき ◦ 仮にバグがあったとしてもユーザー影響が最小限に抑えられる •
テスト環境で検証しきれないとき ◦ 本番で検証したほうがよい場面もある ▪ 本番にしかデータがない、リアルユーザーの操作が再現しきれない等
© 2025 Wantedly, Inc. どういうときに便利かざっくりとした例 • パッケージ/ライブラリのバージョンを上げるとき • 大きなリリースをしようとしているとき •
影響が見えていなくて不安なとき
© 2025 Wantedly, Inc. 実際に便利だった事例 • Ruby, Rails をアップグレードするとき ◦
影響範囲が大きい & 全てを調査するのは大変 ◦ テスト環境でざっくり確認して問題なさそう => 本番で検証というフロー
© 2025 Wantedly, Inc. kube canary の利用イメージ
© 2025 Wantedly, Inc. ウォンテッドリーでは kube canary コマンドを用意している • kube
canary start <rev> で <rev> に指定したもの が canary release (デプロイ) される ◦ rev: ブランチ、commit hash master を canary release する例
© 2025 Wantedly, Inc. 工夫ポイント: モニタリング用の dashboard を用意している Datadog に
canary release の 状況を確認するための dashboard を用意 canary start 時に dashboard のリンクを出して アクセスしやすいように
© 2025 Wantedly, Inc. k8s レイヤーでのモニタリング • 内部的には canary pod
が 1 つ立っているだけなので 普通の pod と同じ debug ができる ◦ kubectl get po や kubectl log <pod> で見られる (普通の pod と同じ)
© 2025 Wantedly, Inc. kube canary stop • kube canary
stop で canary release を終了する ◦ canary release で問題ないことを確認できたら canary stop → master に merge してデプロイする、というイメージ canary stop する例
© 2025 Wantedly, Inc. kube canary の内部実装
© 2025 Wantedly, Inc. kube canary start をしてからユーザーからリクエストされるまでの流れ
© 2025 Wantedly, Inc. kube canary start をしてからユーザーからリクエストされるまでの流れ
© 2025 Wantedly, Inc. canary stop の流れ
© 2025 Wantedly, Inc. deployment-duplicator • 既存の Deployment に少しパッチを当てた Deployment
を複製する custom controller ◦ どういうパッチを当てるかは DeploymentCopy manifest に書く ◦ この manifest を呼んで deployment-duplicator が Deployment を複製 実装は公開しています https://github.com/wantedly/deployment-duplicator
© 2025 Wantedly, Inc. 補足: 現状の canary release の設計は改善の余地がある •
本当は右の図のように canary の 割合をコントロールしたい 新 バージョン 旧来 バージョン (master) エンドユーザー 3 % 97 %
© 2025 Wantedly, Inc. namespace 補足: 現状の canary release の設計は改善の余地がある
• 実際はただ pod が立っているだけ ◦ たくさんある pod からランダムにリクエストされる ◦ 旧来バージョンの pod の中に 1 pod だけ canary pod が立つ ◦ つまり: もともと 40 pods ある namespace だと 1/40 (2.5 %) の確率で canary にリクエストされる ▪ 3 pods なら 1/3 (33.3 %) になる エンドユーザー
© 2025 Wantedly, Inc. 持ち帰ってほしいこと • canary release というデプロイ手法が便利 ◦
ウォンテッドリーではこれを実現するためのツールを内製している