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
ZOZOTOWNにおけるKubernetes Cluster Upgradeの これまでとこれから
Search
ksudate
December 15, 2023
1
1.5k
ZOZOTOWNにおけるKubernetes Cluster Upgradeの これまでとこれから
ZOZO Kubernetes Night (
https://zozotech-inc.connpass.com/event/299357/
) の登壇資料になります。
ksudate
December 15, 2023
Tweet
Share
More Decks by ksudate
See All by ksudate
KubeCon + CNCon Europe 2023 Recap Flux Beyond Git: Harnessing the Power of OCI
ksudate
1
16k
KubeCon + CNCon Europe 2022 Recap ~ Istio Today and Tomorrow: Sidecars and Beyond
ksudate
1
500
分散負荷試験の自動化を実現するGatling Operatorの紹介
ksudate
1
4.3k
PodのAZ分散を実現する Pod Topology Spread ConstraintsとDescheduler
ksudate
1
700
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Side Projects
sachag
452
42k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
Raft: Consensus for Rubyists
vanstee
137
6.7k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
A Modern Web Designer's Workflow
chriscoyier
693
190k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Rails Girls Zürich Keynote
gr2m
94
13k
Transcript
ZOZOTOWNにおけるKubernetes Cluster Upgradeの これまでとこれから ZOZO Kubernetes Night #1 株式会社ZOZO 技術本部
SRE部 ECプラットフォーム基盤SREブロック 巣立 健太郎 Copyright © ZOZO, Inc. 1
© ZOZO, Inc. 株式会社ZOZO 技術本部 SRE部 ECプラットフォーム基盤SREブロック 巣立 健太郎 /
Kentaro Sudate 新卒SRE3年目。 EKS上で稼働するマイクロサービス基盤の運用に従事。 最近は、CI/CDの改善も頑張っています。 ついに最強のCI/CDが完成した 〜巨大リポジトリで各チー ムが独立して・安全に・高速にリリースする〜 - ZOZO TECH BLOG Twitter: @ksudate 2
© ZOZO, Inc. Agenda • EKS Upgradeの手法を決める上で重視すること • ZOZOTOWNのEKS Upgradeのこれまで
• EKS Upgradeを少しだけ楽にする取り組み
© ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること • サービス影響 • 作業コスト •
ロールバック • 頻度 • 実行時間
© ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること サービス影響 • アップグレードの前・中・後でユーザーへの影響がない
© ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること 作業コスト • 変更内容がシンプル • アップグレード作業の自動化
• 総作業量が少ない
© ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること ロールバック • Data Plane /
Control Planeのロールバックが可能 • ロールバックにかかる時間が短い
© ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること 頻度 • 一度に複数バージョンのアップグレードが可能
© ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること 実行時間 • Data Plane /
Control Planeのアップグレード時間が短いこと • クラスタの規模が拡大してもアップグレード時間が増加しないこと
© ZOZO, Inc. ZOZOTOWNのEKS Upgradeのこれまで 2020/4 2020/7 EKS Cluster 誕生
構築当初のEKS Versionはv1.15 でした。 Nodegroup B/G Upgrade 2021/9 In-place Upgrade 現在 新たな手法 模索中
© ZOZO, Inc. ZOZOTOWNのEKS Upgradeのこれまで 2020/4 2020/7 EKS Cluster 誕生
構築当初のEKS Versionはv1.15 でした。 Nodegroup B/G Upgrade 初のEKS Upgradeを実施した。 Control PlaneはIn-place Upgrade、Nodegroupは Blue/Green Upgradeを採用し た。 2021/9 In-place Upgrade 現在 新たな手法 模索中
© ZOZO, Inc. Nodegroup B/G Upgrade Control plane API ServerやetcdがAWSによって自動的にアップグレードされる。
© ZOZO, Inc. Nodegroup B/G Upgrade Data plane 新規Nodegroupを作成して、NodeAffinityに新規Nodegroupを指定する。
© ZOZO, Inc. ZOZOTOWNのEKS Upgradeのこれまで 2020/4 2020/7 EKS Cluster 誕生
構築当初のEKS Versionはv1.15 でした。 Nodegroup B/G Upgrade 初のEKS Upgradeを実施した。 Control PlaneはIn-place Upgrade、Nodegroupは Blue/Green Upgradeを採用し た。 2021/9 In-place Upgrade 工数削減のためv1.19からは NodegroupについてもIn-place Upgradeを実施した。 Nodegroup B/G Upgradeでは、 NodeAffinity切り替えの作業コ ストがアプリケーションが増え るにつれ高まっていた。 現在 新たな手法 模索中
© ZOZO, Inc. In-place Upgrade Control plane NodegroupのBlue/Green Upgradeと同様にIn-place Upgrade
© ZOZO, Inc. Data plane NodegroupがAWSによって自動的にアップグレードされる。 In-place Upgrade
© ZOZO, Inc. Data plane Autoscaling Groupの起動テンプレートを最新バージョンにした上でNodeを作成 In-place Upgrade
© ZOZO, Inc. In-place Upgrade Data plane PodをDrainして新規バージョンのNodeへ移動。Defaultで1度に1Nodeずつ移動
© ZOZO, Inc. In-place Upgrade Data plane Drainが完了したNodeは60秒待機した後に削除される。
© ZOZO, Inc. In-place Upgrade Data plane Drainを繰り返し、全てのNodeが入れ替わるとアップグレードは完了。
© ZOZO, Inc. ZOZOTOWNのEKS Upgradeのこれまで 2020/4 2020/7 EKS Cluster 誕生
構築当初のEKS Versionはv1.15 でした。 Nodegroup B/G Upgrade 初のEKS Upgradeを実施した。 Control PlaneはIn-place Upgrade、Nodegroupは Blue/Green Upgradeを採用し た。 2021/9 In-place Upgrade 工数削減のためv1.19からは NodegroupについてもIn-place Upgradeを実施した。 Nodegroup B/G Upgradeでは、 NodeAffinity切り替えの作業コ ストがアプリケーションが増え るにつれ高まっていた。 現在 新たな手法 模索中 クラスタの規模が拡大すると より安全なEKS Upgradeが求め られる。 そこで、Cluster Migrationによ るUpgradeを検討中。
© ZOZO, Inc. Cluster Migration Upgrade
© ZOZO, Inc. TargetGroupBindingとは? aws-load-balancer-controllerが提供するCustom Resource。 ELBのTargetGroupへTargetの登録をKuberntes上で可能にする。
© ZOZO, Inc. Cluster Migration Upgrade TargetGroupBindingを使う方法のメリット • TargetGroupBindingを作成するだけでトラフィックの切り替えが可能 ◦
クラスタ構築時に新規でELBの作成が不要。 • ELBの加重ルーティングによりトラフィックを切り替え可能
© ZOZO, Inc. Cluster Migration Upgrade TargetGroupBindingを使う方法のデメリット • ELBの数だけTargetGroupBindingを作成する必要がある •
既存のクラスタがIngressでALBを作成している場合、移行が必要
© ZOZO, Inc. Cluster Migration Upgrade
© ZOZO, Inc. Cluster Migration Upgrade Route53を使うメリット • Route53の加重ルーティングによりトラフィックを切り替え可能 •
aws-load-balancer-controllerを利用してIngressでALBを管理できる
© ZOZO, Inc. Cluster Migration Upgrade Route53を使うデメリット • クラスタ構築時に新規でELBの作成が必要 ◦
場合によっては、SSL証明書やRoute53のレコード変更も必要 • DNSリゾルバのキャッシュにより設定の反映に時間がかかる ◦ それに伴い、ロールバックの際も時間がかかる
© ZOZO, Inc. それぞれの観点から各手法を比較する
© ZOZO, Inc. それぞれの手法を比較する サービス影響 Nodegroup B/G Upgrade In-place Upgrade
Cluster Migration Upgrade NodeAffinityの修正を 行なってアップグレー ドするためアプリケー ションごとにリリース できる。 In-placeでNodegroup ごとにUpgradeが実施 されるため、 Nodegroup B/G Upgradeに比べて障害 発生時の影響範囲が大 きい。 クラスタごと移行する ため事前に新しいクラ スタで動作確認ができ る。 そのため、他の手法に 比べて安全。
© ZOZO, Inc. それぞれの手法を比較する 作業コスト Nodegroup B/G Upgrade In-place Upgrade
Cluster Migration Upgrade NodeAffinityの切り替 えが必要 CloudFormationで管理 されている場合、バー ジョンを修正するだけ 新規クラスタを構築す る必要がある トラフィックの切り替 え作業が必要
© ZOZO, Inc. それぞれの手法を比較する ロールバック Nodegroup B/G Upgrade In-place Upgrade
Cluster Migration Upgrade Control planeのロール バックができない Data planeは、 NodeAffinityの切り替 えにより古い Nodegroupに移動する ことでロールバック可 能 Control planeのロール バックができない Data planeは、 Nodegroupの更新中に 問題が発生すると自動 的にロールバックが実 施される Control planeのロール バックが可能 Trafficの切り替え方法 によってロールバック の方法も異なる
© ZOZO, Inc. それぞれの手法を比較する 頻度 Nodegroup B/G Upgrade In-place Upgrade
Cluster Migration Upgrade Control plane・Data planeのどちらも 1versionずつしかアッ プグレードできないた め、アップグレードの 頻度も多くなる Control plane・Data planeのどちらも 1versionずつしかアッ プグレードできないた め、アップグレードの 頻度も多くなる 新規クラスタを構築す るため、1度にアップグ レードできるバージョ ンに上限がない そのため、他の手法に 比べてアップグレード の頻度を少なくできる
© ZOZO, Inc. それぞれの手法を比較する 実行時間 Nodegroup B/G Upgrade In-place Upgrade
Cluster Migration Upgrade Control planeの Upgradeは、10分程度 Data planeは、 NodeAffinityの変更な のでImage更新などのリ リース時間と同じ Control planeの Upgradeは10分程度 Data planeについて は、updateConfigの設 定で変動 Trafficの切り替え方法 で実行時間は変動
© ZOZO, Inc. それぞれの手法を比較する サービス影響 Nodegroup B/G Upgrade In-place Upgrade
Cluster Migration Upgrade 作業コスト ロールバック 頻度 実行時間
© ZOZO, Inc. 結局、どれがいいの?
© ZOZO, Inc. それぞれの手法を比較する Nodegroup B/G Upgrade 工数を抑えつつアプリケーションごとにUpgradeを実施 In-place Upgrade
最小限の工数で、NodegroupごとにUpgradeを実施 Cluster Migration Upgrade 事前にアプリケーションの動作を確認し、より安全に実施
© ZOZO, Inc. 正直、どの手法もそれなりに大変です…
© ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み
© ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み updateConfigの設定 updateConfigでは、並列でアップグレードするNodeの最大数を決める。 一度に最大100Nodeまで並列でアップグレードが可能になる。 デフォルト値が1NodeなのでIn-placeでアップグレードを実施している大規模 なクラスタでは、updateConfigを設定することで、高速化が期待できる。
NodegroupUpdateConfig - Amazon EKS
© ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み EKS Addonの導入 kube-proxyやamazon-vpc-cni、corednsなどをAWSが管理してくれる。 EKS Addonで管理されるリソースは、Server-side
Applyを利用している。 そのため、ユーザーがアドオンに対して独自の設定を追加できる。 Kubernetes フィールド管理 - Amazon EKS
© ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み Plutoによる非推奨APIの確認 K8sはバージョンアップに伴い、非推奨・廃止予定のAPIが発生する。 Plutoは静的マニフェストをチェックし、非推奨・廃止予定のAPIを出力する。 Plutoの類似ツールとしてKube-no-troubleなどがある。 Plutoを使えば、Upgradeの度にRelease
Noteを見て、変更のあるAPIを修正 する手間が省ける。
© ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み Plutoによる非推奨APIの確認
© ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み RenovateによるEcosystemのバージョンアップ EKSのアップグレードに伴い、クラスタ上で稼働するアプリケーション (cluster-autoscaler、cert-managerなど)のバージョンアップも必要になる。 Renovateを利用すると、バージョンアップが必要なアプリケーションに対し て修正を行いGitHub上にPull
Requestを作成してくれる。
© ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み RenovateによるEcosystemのバージョンアップ
© ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み その他にも・・・ • PodTopologySpreadConstraintsによるAZ分散 • PodDisruptionBudgetによる最低Pod数の設定
• アクセスピーク時間を避けたEKS Upgradeの実施 • etc…
© ZOZO, Inc. まとめ これまでマイクロサービス基盤の規模に応じて柔軟に手法を変えてアップグ レードを実施してきました。 それぞれのメリット・デメリットを理解した上で組織にあった手法を選択する ことでEKS Upgradeを少しずつ楽にしてくれます。
None