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.3k
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
480
分散負荷試験の自動化を実現するGatling Operatorの紹介
ksudate
1
4.2k
PodのAZ分散を実現する Pod Topology Spread ConstraintsとDescheduler
ksudate
1
670
Featured
See All Featured
A Tale of Four Properties
chriscoyier
156
23k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Six Lessons from altMBA
skipperchong
26
3.5k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Optimizing for Happiness
mojombo
376
69k
Measuring & Analyzing Core Web Vitals
bluesmoon
1
41
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Facilitating Awesome Meetings
lara
49
6k
GitHub's CSS Performance
jonrohan
1030
460k
KATA
mclloyd
29
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