ZOZOTOWNにおけるKubernetes Cluster Upgradeの これまでとこれから

ZOZO Kubernetes Night (https://zozotech-inc.connpass.com/event/299357/) の登壇資料になります。

1. ZOZOTOWNにおけるKubernetes Cluster Upgradeの これまでとこれから ZOZO Kubernetes Night #1 株式会社ZOZO 技術本部 SRE部 ECプラットフォーム基盤SREブロック 巣立 健太郎 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 株式会社ZOZO 技術本部 SRE部 ECプラットフォーム基盤SREブロック 巣立 健太郎 / Kentaro Sudate 新卒SRE3年目。 EKS上で稼働するマイクロサービス基盤の運用に従事。 最近は、CI/CDの改善も頑張っています。 ついに最強のCI/CDが完成した 〜巨大リポジトリで各チー ムが独立して・安全に・高速にリリースする〜 - ZOZO TECH BLOG Twitter: @ksudate
 2
3. © ZOZO, Inc. Agenda • EKS Upgradeの手法を決める上で重視すること • ZOZOTOWNのEKS Upgradeのこれまで • EKS Upgradeを少しだけ楽にする取り組み
4. © ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること • サービス影響 • 作業コスト • ロールバック • 頻度 • 実行時間
5. © ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること サービス影響 • アップグレードの前・中・後でユーザーへの影響がない
6. © ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること 作業コスト • 変更内容がシンプル • アップグレード作業の自動化 • 総作業量が少ない
7. © ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること ロールバック • Data Plane / Control Planeのロールバックが可能 • ロールバックにかかる時間が短い
8. © ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること 頻度 • 一度に複数バージョンのアップグレードが可能
9. © ZOZO, Inc. EKS Upgradeの手法を決める上で重視すること 実行時間 • Data Plane / Control Planeのアップグレード時間が短いこと • クラスタの規模が拡大してもアップグレード時間が増加しないこと
10. © ZOZO, Inc. ZOZOTOWNのEKS Upgradeのこれまで 2020/4 2020/7 EKS Cluster 誕生 構築当初のEKS Versionはv1.15 でした。 Nodegroup B/G Upgrade 2021/9 In-place Upgrade 現在 新たな手法 模索中
11. © 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 現在 新たな手法 模索中
12. © ZOZO, Inc. Nodegroup B/G Upgrade Control plane API ServerやetcdがAWSによって自動的にアップグレードされる。
13. © ZOZO, Inc. Nodegroup B/G Upgrade Data plane 新規Nodegroupを作成して、NodeAffinityに新規Nodegroupを指定する。
14. © 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切り替えの作業コ ストがアプリケーションが増え るにつれ高まっていた。 現在 新たな手法 模索中
15. © ZOZO, Inc. In-place Upgrade Control plane NodegroupのBlue/Green Upgradeと同様にIn-place Upgrade
16. © ZOZO, Inc. Data plane NodegroupがAWSによって自動的にアップグレードされる。 In-place Upgrade
17. © ZOZO, Inc. Data plane Autoscaling Groupの起動テンプレートを最新バージョンにした上でNodeを作成 In-place Upgrade
18. © ZOZO, Inc. In-place Upgrade Data plane PodをDrainして新規バージョンのNodeへ移動。Defaultで1度に1Nodeずつ移動
19. © ZOZO, Inc. In-place Upgrade Data plane Drainが完了したNodeは60秒待機した後に削除される。
20. © ZOZO, Inc. In-place Upgrade Data plane Drainを繰り返し、全てのNodeが入れ替わるとアップグレードは完了。
21. © 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を検討中。
22. © ZOZO, Inc. Cluster Migration Upgrade
23. © ZOZO, Inc. TargetGroupBindingとは？ aws-load-balancer-controllerが提供するCustom Resource。 ELBのTargetGroupへTargetの登録をKuberntes上で可能にする。
24. © ZOZO, Inc. Cluster Migration Upgrade TargetGroupBindingを使う方法のメリット • TargetGroupBindingを作成するだけでトラフィックの切り替えが可能 ◦ クラスタ構築時に新規でELBの作成が不要。 • ELBの加重ルーティングによりトラフィックを切り替え可能
25. © ZOZO, Inc. Cluster Migration Upgrade TargetGroupBindingを使う方法のデメリット • ELBの数だけTargetGroupBindingを作成する必要がある • 既存のクラスタがIngressでALBを作成している場合、移行が必要
26. © ZOZO, Inc. Cluster Migration Upgrade
27. © ZOZO, Inc. Cluster Migration Upgrade Route53を使うメリット • Route53の加重ルーティングによりトラフィックを切り替え可能 • aws-load-balancer-controllerを利用してIngressでALBを管理できる
28. © ZOZO, Inc. Cluster Migration Upgrade Route53を使うデメリット • クラスタ構築時に新規でELBの作成が必要 ◦ 場合によっては、SSL証明書やRoute53のレコード変更も必要 • DNSリゾルバのキャッシュにより設定の反映に時間がかかる ◦ それに伴い、ロールバックの際も時間がかかる
29. © ZOZO, Inc. それぞれの観点から各手法を比較する
30. © ZOZO, Inc. それぞれの手法を比較する サービス影響 Nodegroup B/G Upgrade In-place Upgrade Cluster Migration Upgrade NodeAffinityの修正を 行なってアップグレー ドするためアプリケー ションごとにリリース できる。 In-placeでNodegroup ごとにUpgradeが実施 されるため、 Nodegroup B/G Upgradeに比べて障害 発生時の影響範囲が大 きい。 クラスタごと移行する ため事前に新しいクラ スタで動作確認ができ る。 そのため、他の手法に 比べて安全。
31. © ZOZO, Inc. それぞれの手法を比較する 作業コスト Nodegroup B/G Upgrade In-place Upgrade Cluster Migration Upgrade NodeAffinityの切り替 えが必要 CloudFormationで管理 されている場合、バー ジョンを修正するだけ 新規クラスタを構築す る必要がある トラフィックの切り替 え作業が必要
32. © 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の切り替え方法 によってロールバック の方法も異なる
33. © ZOZO, Inc. それぞれの手法を比較する 頻度 Nodegroup B/G Upgrade In-place Upgrade Cluster Migration Upgrade Control plane・Data planeのどちらも 1versionずつしかアッ プグレードできないた め、アップグレードの 頻度も多くなる Control plane・Data planeのどちらも 1versionずつしかアッ プグレードできないた め、アップグレードの 頻度も多くなる 新規クラスタを構築す るため、1度にアップグ レードできるバージョ ンに上限がない そのため、他の手法に 比べてアップグレード の頻度を少なくできる
34. © 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の切り替え方法 で実行時間は変動
35. © ZOZO, Inc. それぞれの手法を比較する サービス影響 Nodegroup B/G Upgrade In-place Upgrade Cluster Migration Upgrade 作業コスト ロールバック 頻度 実行時間
36. © ZOZO, Inc. 結局、どれがいいの？
37. © ZOZO, Inc. それぞれの手法を比較する Nodegroup B/G Upgrade 工数を抑えつつアプリケーションごとにUpgradeを実施 In-place Upgrade 最小限の工数で、NodegroupごとにUpgradeを実施 Cluster Migration Upgrade 事前にアプリケーションの動作を確認し、より安全に実施
38. © ZOZO, Inc. 正直、どの手法もそれなりに大変です…
39. © ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み
40. © ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み updateConfigの設定 updateConfigでは、並列でアップグレードするNodeの最大数を決める。 一度に最大100Nodeまで並列でアップグレードが可能になる。 デフォルト値が1NodeなのでIn-placeでアップグレードを実施している大規模 なクラスタでは、updateConfigを設定することで、高速化が期待できる。 NodegroupUpdateConfig - Amazon EKS
41. © ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み EKS Addonの導入 kube-proxyやamazon-vpc-cni、corednsなどをAWSが管理してくれる。 EKS Addonで管理されるリソースは、Server-side Applyを利用している。 そのため、ユーザーがアドオンに対して独自の設定を追加できる。 Kubernetes フィールド管理 - Amazon EKS
42. © ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み Plutoによる非推奨APIの確認 K8sはバージョンアップに伴い、非推奨・廃止予定のAPIが発生する。 Plutoは静的マニフェストをチェックし、非推奨・廃止予定のAPIを出力する。 Plutoの類似ツールとしてKube-no-troubleなどがある。 Plutoを使えば、Upgradeの度にRelease Noteを見て、変更のあるAPIを修正 する手間が省ける。
43. © ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み Plutoによる非推奨APIの確認
44. © ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み RenovateによるEcosystemのバージョンアップ EKSのアップグレードに伴い、クラスタ上で稼働するアプリケーション (cluster-autoscaler、cert-managerなど)のバージョンアップも必要になる。 Renovateを利用すると、バージョンアップが必要なアプリケーションに対し て修正を行いGitHub上にPull Requestを作成してくれる。
45. © ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み RenovateによるEcosystemのバージョンアップ
46. © ZOZO, Inc. EKS Upgradeを少しだけ楽にする取り組み その他にも・・・ • PodTopologySpreadConstraintsによるAZ分散 • PodDisruptionBudgetによる最低Pod数の設定 • アクセスピーク時間を避けたEKS Upgradeの実施 • etc…
47. © ZOZO, Inc. まとめ これまでマイクロサービス基盤の規模に応じて柔軟に手法を変えてアップグ レードを実施してきました。 それぞれのメリット・デメリットを理解した上で組織にあった手法を選択する ことでEKS Upgradeを少しずつ楽にしてくれます。