システム化で乗り切る1200クラスタのKaaS運用

CloudNative Days Summer 2024 プレイベント@東京 (ハイブリッド開催)に登壇した際の資料です。
https://cloudnativedays.connpass.com/event/318627/

Transcript

1. システム化で乗り切る 1200 クラスタの KaaS 運⽤ LINEヤフー株式会社 サービスインフラグループ クラウド統括本部 Cloud Native 本部 Kento Kubo (kenkubo[at]lycorp.co.jp) Kyosuke Mizoguchi (kmizoguc[at]lycorp.co.jp)
2. Kyosuke Mizoguchi / 溝⼝ 響介 • 2020 ~ LINEヤフー株式会社 • K8s as a Service の SRE • ⾃動化によるトイル削減や利⽤者 UX 向上などの興味があります 2 ⾃⼰紹介 Kento Kubo / 久保 顕登 • 2023 ~ LINEヤフー株式会社 • K8s as a Service の SRE • 主に k8s バージョンアップや利⽤者向けインターフェースの開発を担当 • ⻘森在住
3. ZCPについて K8s/アドオン新バージョン提供のトイル削減 リソース枯渇・Noisy Neighbor などクラウドの課題に対する対応 まとめ 01 03 02 04 3
4. ZCPについて K8s/アドオン新バージョン提供のトイル削減 リソース枯渇・Noisy Neighbor などクラウドの課題に対する対応 まとめ 01 03 02 04 4
5. ZCP とは 5 • Zlab Container Platform(ZCP) は弊社のプライベート K8s as a Service(KaaS) • 開発者の⾼い⽣産性のためセキュアで運⽤が簡単な k8s クラスタを提供 • 確保されたセキュリティ(監査、脆弱性対応) • SREのプラクティスを簡単に実現 (o11y、アラーティング、運⽤⾃動化) • 全社のサービスが利⽤する極めて重要なプラットフォーム • プラットフォームの稼働率: 99.99% Z Lab / KaaSチーム 開発・運⽤ 提供・管理 開発者 etc. ZCP ZCP について ショッピング オークション
6. ZCP の規模 6 2018/08のGAから5年間運⽤して ✔ 1400+ k8s clusters ✔ 996K+ Containers ✔ 57K+ VMs # 2024/04時点 これらを20数名で管理 ZCP について
7. プライベート KaaS を運⽤する中で、最近以下の課題に直⾯しました • K8s のライフサイクルに追従するためのトイル • リソース枯渇・Noisy Neighbor といったクラウドならではの課題 今回は、これらの課題をどのように解決したかをお話しします 7 KaaS 運⽤のあるある課題 ZCP について
8. ZCPについて K8s/アドオン新バージョン提供のトイル削減 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 まとめ 01 03 02 04 8
9. K8s のライフサイクルに合わせて、検証が完了している直近2バージョンを提供している 9 ZCP の k8s バージョン提供 23/11 24/03 24/07 24/11 1.26 1.27 1.28 1.29 K8s/アドオン新バージョン提供のトイル削減
10. ZCP では、⽣の k8s に加えて、独⾃のアドオンをデフォルトで提供している 例 : Prometheus / Grafana etc... 10 ZCP の k8s & アドオン管理 addon manager 各種アドオン K8s/アドオン新バージョン提供のトイル削減
11. K8s・アドオンマネージャのバージョンはマイナー単位で1対1対応する （アドオンマネージャ配下のアドオンは、必要に応じてバージョンが変わる） 11 ZCP の k8s & アドオン管理 addon manager 各種アドオン 1.26 1.26 addon manager 各種アドオン 1.27 1.27 addon manager 各種アドオン 1.28 1.28 K8s/アドオン新バージョン提供のトイル削減
12. 12 バージョン提供の仕組み KaaS Controller 開発者 addon manager 各種アドオン 1.27 → 1.28 1.27 → 1.28 Z Lab / KaaSチーム k8s/アドオン 提供設定 update K8s/アドオン新バージョン提供のトイル削減
13. 新バージョン提供作業の検証・リリースに、4⼈×2週間×3回/年 (6⼈⽉) の⼯数をかけていた 13 課題 リリース ⽇程調整 新 バージョン 検証 リリース リリース 後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) ⼿作業による検証 ・脆弱性チェック ・検証⽤クラスタでの 新機能検証 ・回帰テスト 環境ごとに繰り返すリリース ・設定ファイルリリース ・K8s 関連リリース ・アドオン関連リリース K8s/アドオン新バージョン提供のトイル削減
14. 新バージョン提供作業の検証・リリースに、4⼈×2週間×3回/年 (6⼈⽉) の⼯数をかけていた 14 課題 リリース ⽇程調整 新 バージョン 検証 リリース リリース 後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) ⼿作業による検証 ・脆弱性チェック ・検証⽤クラスタでの 新機能検証 ・回帰テスト 環境ごとに繰り返すリリース ・設定ファイルリリース ・Kubernetes 関連リリース ・アドオン関連リリース Kubernetes 新バージョン提供のトイル削減 つらすぎる！！！！
15. トイル削減を⽬指し、バージョン提供作業の⾃動化を進めた 15 ZCP の挑戦 リリース ⽇程調整 新 バージョン 検証 リリース リリース 後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) ⼿作業による検証 環境ごとに繰り返すリリース e2e テスト実装や CI pipeline による⾃動化 リリース PR ⾃動作成 bot の実装 K8s/アドオン新バージョン提供のトイル削減
16. K8s/アドオンの新バージョンの検証を⼿作業で実施していた • 脆弱性スキャン (50+ images) • 検証クラスタでの新機能の検証 • K8s 機能検証 (5+ cases) • アドオン機能検証 (50+ cases) • 回帰テスト • 基本機能テスト (100+ cases) • 権限テスト (1000+ cases) 3⼈×2週間のコストがかかっていた 16 新バージョン検証の課題 K8s/アドオン新バージョン提供のトイル削減
17. 検証項⽬の⼤半を、Ginkgo などを使い e2e テスト化し、CI pipeline に組み込んだ テストケースは合計で 約1500件 • 脆弱性スキャンの⾃動化 (API 利⽤) • 新機能検証の e2e テスト化 • CNCF 公式の k8s-conformance テストの実⾏ (ginkgo) • アドオン⽤ e2e テストの実装・実⾏ (ginkgo) • 回帰テスト • 新機能検証で使⽤した e2e テストの実⾏ (ginkgo) • 権限テストのスクリプト化 (shell) • 社内の他 PF との連携テスト 17 検証項⽬の e2e テスト & pipeline 化 K8s/アドオン新バージョン提供のトイル削減
18. 提供中の2バージョンに対して pipeline を実⾏している 3h 程度で⼀連の作業が完了する 18 実際の pipeline K8s/アドオン新バージョン提供のトイル削減
19. 過去の障害の再発防⽌ • バージョンアップデート起因の障害について、再発防⽌確認を e2e テストに組み込んでいる 検証項⽬のテスト化の限界 • バージョン固有機能など、⼀部の項⽬はテストの実装が難しく、完全⾃動化はできていない • K8s/アドオンの最新知識を把握する⽬的で、新機能検証はあえて⼿動でも確認 19 副次的効果と限界 K8s/アドオン新バージョン提供のトイル削減
20. 4環境に対して新バージョンリリースを繰り返す必要があった リリースは CI/CD 経由で⾏い、リリース⽤ PR をそれぞれ作成しなければならない • 設定ファイルリリース (1PR) • K8s 関連リリース (2PR) • アドオン関連リリース (2PR) 全環境で合計 20 PR を作成していた 1⼈×2週間のコストがかかっていた 20 リリースの課題 K8s/アドオン新バージョン提供のトイル削減
21. 4環境に対して新バージョンリリースを繰り返す必要があった リリースは CI/CD 経由で⾏い、リリース⽤ PR をそれぞれ作成しなければならない • 設定ファイルリリース (1PR) • K8s 関連リリース (2PR) • アドオン関連リリース (2PR) 全環境で合計 20 PR を作成していた 1⼈×2週間のコストがかかっていた 21 リリースの課題 K8s/アドオン新バージョン提供のトイル削減
22. 繰り返す PR を⾃動作成する github bot を実装 24 リリース bot の整備 KaaS Controller 20 PR の 作成⾃動化 CI/CD K8s/アドオン新バージョン提供のトイル削減
23. 25 リリース bot の整備 リリース⼿順 管理者 : issue でコマンドを打つ ↓ Bot : PR 作成 ↓ 管理者 : PR review & merge ↓ CI/CD : リリース K8s/アドオン新バージョン提供のトイル削減
24. ⼀連のトイル削減に、2⼈×4ヶ⽉程度のリソースを投資した 各⼿順ごとに ProcessTime/LeadTime を計測し、優先度を決めて効果を確認しながら実施した 26 コスト K8s/アドオン新バージョン提供のトイル削減
25. 新バージョン提供作業の検証・リリースを 2⼈×3⽇×3回/年 (0.6 ⼈⽉) で実現した (85% 削減) 27 Before/After リリース ⽇程調整 新 バージョン 検証 リリース リリース 後作業 1⼈×3⽇ (-90%) 1⼈×3⽇ (-70%) リリース ⽇程調整 新 バージョン 検証 リリース リリース 後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) 暗黙知の削減にもつながった K8s/アドオン新バージョン提供のトイル削減
26. ZCPについて K8s/アドオン新バージョン提供のトイル削減 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 まとめ 01 03 02 04 28
27. ZCP は プライベート KaaS であり、主に以下のような特徴がある • Node(VM) が乗っている物理マシン (HV) は全体共有している • VM はマシンリソース有効利⽤のために、CPU を 4 倍まで overcommit を許す設定で運⽤している • OpenStack クラスタが複数存在する • dev,prod などの環境や世代ごとに OpenStack クラスタが存在する • HV の減価償却に応じて、新しいOpenStack クラスタへの移⾏が必要 29 ZCP のインフラの特徴 k8s クラスタA VM VM OpenStack A k8s クラスタB VM VM k8s クラスタC VM VM HV HV リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 k8s クラスタD VM VM OpenStack B k8s クラスタE VM VM VM VM HV HV
28. OpenStack クラスタがリソース枯渇に陥った場合でも、気軽に増強できない • DC の敷設、費⽤などの制約によって、即座に OpenStack クラスタを増強できないことが多い →この時、リソースに余裕がある別の OpenStack クラスタへ k8s クラスタの移⾏が必要な場合があった 30 クラウド課題１：OpenStack クラスタのリソース枯渇 k8s クラスタA VM VM OpenStack k8s クラスタB VM VM k8s クラスタC VM VM HV HV OpenStack k8s クラスタC VM VM HV HV VM スケールアウトしたいが、 OpenStack クラスタの リソースが⾜りない リソースに余裕がある 別 OpenStack クラスタへ k8s クラスタごとで移⾏ リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
29. Noisy Neighbor • HV を全体共有しているため、⾃分の k8s クラスタだけでなく、他の k8s クラスタと CPU リソースの取 り合いの状態になっている場合がある →この時、⾃分の k8s クラスタだけでなく、他の k8s クラスタのレイテンシの悪化やタイムアウトを発⽣ させてしまうことがある 31 課題２: Noisy Neighbor cpu1 cpu2 cpu3 cpu100 … Noisy Neighbor状態 k8s クラスタB および k8s クラスタC にて レイテンシ悪化、タイムアウト発⽣ 🔥 🔥 🔥 cpu4 🔥 HV k8s クラスタA k8s クラスタB k8s クラスタC HV リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
30. 別 OpenStack クラスタへの移⾏のつらさ • 前述の課題の対応として、別の OpenStack クラスタへ k8s クラスタへ移⾏を利⽤者に案内していた • 移⾏作業における⼯程が多かった • ⼯程内では、yaml の書き直しなど⼿動での設定変更項⽬も多かった • 結果として、移⾏作業は3ヶ⽉程度必要で、利⽤者に実施頂く必要があった • HV の減価償却に応じた OpenStack クラスタへの移⾏として、500 クラスタ程度の利⽤者に移⾏対応い ただき、移⾏完了まで 6ヶ⽉以上要した • HVの減価償却に応じた OpenStack クラスタの移⾏は今後も継続的に必要となる 32 課題への対応(Before) リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
31. 新規クラスタを作成せず、WorkerNode のみ別 OpenStack クラスタに移⾏する機能を提供する (※ WorkerNode を優先対応しており、CotrolPlane,Ingress も今後対応予定) 33 別 OpenStack クラスタへの移⾏機能を提供 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
32. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • 移⾏先でのポート開放漏れなどによって、トラフィック全断のリスクなど • [対策1] • 移⾏する WorkerNode の割合を指定し、段階的に移⾏できる機能を提供した 34 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
33. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • 移⾏先でのポート開放漏れなどによって、トラフィック全断のリスクなど • [対策1] • 移⾏する WorkerNode の割合を指定し、段階的に移⾏できる機能を提供した 35 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 移⾏先 OpenStack へ WorkerNode 1台作成 1台の WorkerNode を drain する
34. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • 移⾏先でのポート開放漏れなどによって、トラフィック全断のリスクなど • [対策1] • 移⾏する WorkerNode の割合を指定し、段階的に移⾏できる機能を提供した 36 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 残りの WorkerNode を drain する 移⾏先 OpenStack へ WorkerNode を残り3台作成
35. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • 移⾏先でのポート開放漏れなどによって、トラフィック全断のリスクなど • [対策1] • 移⾏する WorkerNode の割合を指定し、段階的に移⾏できる機能を提供した 37 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 drainした WorkerNode を 全て削除
36. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • [対策2] • 段階的移⾏中は、移⾏前の WorkerNode も保持することで迅速な RollBack を実現した • 移⾏前の WorkerNode の再作成を待たずに RollBack 可能 38 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 段階的移⾏中に 問題が発⽣！
37. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • [対策2] • 段階的移⾏中は、移⾏前の WorkerNode も保持することで迅速な RollBack を実現した • 移⾏前の WorkerNode の再作成を待たずに RollBack 可能 39 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 移⾏先 OpenStack の WorkerNode を drain する 移⾏元 WorkerNode の drain を外す
38. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • [対策2] • 段階的移⾏中は、移⾏前の WorkerNode も保持することで迅速な RollBack を実現した • 移⾏前の WorkerNode の再作成を待たずに RollBack 可能 40 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 移⾏先 OpenStack の WorkerNode を削除する
39. • [課題] • 移⾏状態の整合性担保が難しい • 当初コマンド実⾏による逐次処理として実装していたが、実⾏時にプロセスが落ちた場合な どに、コマンド実⾏による要求と、実際の移⾏状態の整合性の担保が難しかった • クラスタの RollingUpdate などによって Node が再作成された場合に node label が維持され ず、整合性の担保が難しかった • [対策] • 移⾏状態を表す、CustomResouceDefinition(CRD): ClusterMigration を定義した • CRD: ClusterMigration に対して監視と調整を⾏うClusterMigrationController を実装した • 利⽤者からのコマンド実⾏では、CRD: ClusterMigration の作成を⾏うものとした 41 移⾏機能実装における課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
40. 移⾏機能の処理の流れ 1. ClusterMigrationController が CR: ClusterMigration を watch している 2. 利⽤者によるコマンド実⾏(zcpctl)で、ClusterMigration が apply される 3. ClusterMigrationContoller が ClusterMigration の定義に従って、古い WorkerNode の drain と新しい WorkerNode を作成する 42 移⾏機能のアーキテクチャ リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
41. • [Before] 別の OpenStack クラスタへ k8s クラスタへ移⾏を利⽤者に案内していた • 移⾏作業における⼯程が多かった • ⼯程内では、yaml の書き直しなど⼿動での設定変更項⽬も多かった • 結果として、移⾏作業は3ヶ⽉程度必要で、利⽤者に実施頂く必要があった • [After] コマンド実⾏のみで WorkerNode の移⾏が可能になった • yaml の書き直しなどの⼿動の設定変更は不要で、既存のリソースを利⽤できる • 60min 以下で移⾏が可能になった 43 Before/After リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 [Before]: 3ヶ⽉程度必要 [After]: 60min 以下で移⾏可能
42. ZCPについて K8s/アドオン新バージョン提供のトイル削減 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 まとめ 01 03 02 04 44
43. プライベート KaaS を運⽤する中で直⾯した課題を、システム化によって解決した • K8s/アドオンの新バージョン提供のトイル • e2e テストや CI pipeline 、リリース bot の実装によって⾃動化 • リソース枯渇・Noisy Neighbor といったクラウドならではの課題 • zcpctl と controller を⽤いた、別 OpenStack クラスタへの移⾏機能提供によって、移⾏ 作業の⼯数を削減 45 まとめ まとめ
44. これすなわち DevOps これからも ZCP の挑戦は続く 46 まとめ
45. Thank you