Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

LY Corporation Tech

May 22, 2024
Tweet

More Decks by LY Corporation Tech

Other Decks in Technology

Transcript

  1. Kyosuke Mizoguchi / 溝⼝ 響介 • 2020 ~ LINEヤフー株式会社 •

    K8s as a Service の SRE • ⾃動化によるトイル削減や利⽤者 UX 向上などの興味があります 2 ⾃⼰紹介 Kento Kubo / 久保 顕登 • 2023 ~ LINEヤフー株式会社 • K8s as a Service の SRE • 主に k8s バージョンアップや利⽤者向けインターフェースの開発を担当 • ⻘森在住
  2. ZCP とは 5 • Zlab Container Platform(ZCP) は弊社のプライベート K8s as

    a Service(KaaS) • 開発者の⾼い⽣産性のためセキュアで運⽤が簡単な k8s クラスタを提供 • 確保されたセキュリティ(監査、脆弱性対応) • SREのプラクティスを簡単に実現 (o11y、アラーティング、運⽤⾃動化) • 全社のサービスが利⽤する極めて重要なプラットフォーム • プラットフォームの稼働率: 99.99% Z Lab / KaaSチーム 開発・運⽤ 提供・管理 開発者 etc. ZCP ZCP について ショッピング オークション
  3. ZCP の規模 6 2018/08のGAから5年間運⽤して ✔ 1400+ k8s clusters ✔ 996K+

    Containers ✔ 57K+ VMs # 2024/04時点 これらを20数名で管理 ZCP について
  4. ZCP では、⽣の k8s に加えて、独⾃のアドオンをデフォルトで提供している 例 : Prometheus / Grafana etc...

    10 ZCP の k8s & アドオン管理 addon manager 各種アドオン K8s/アドオン新バージョン提供のトイル削減
  5. 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/アドオン新バージョン提供のトイル削減
  6. 12 バージョン提供の仕組み KaaS Controller 開発者 addon manager 各種アドオン 1.27 →

    1.28 1.27 → 1.28 Z Lab / KaaSチーム k8s/アドオン 提供設定 update K8s/アドオン新バージョン提供のトイル削減
  7. 新バージョン提供作業の検証・リリースに、4⼈×2週間×3回/年 (6⼈⽉) の⼯数をかけていた 13 課題 リリース ⽇程調整 新 バージョン 検証

    リリース リリース 後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) ⼿作業による検証 ・脆弱性チェック ・検証⽤クラスタでの 新機能検証 ・回帰テスト 環境ごとに繰り返すリリース ・設定ファイルリリース ・K8s 関連リリース ・アドオン関連リリース K8s/アドオン新バージョン提供のトイル削減
  8. 新バージョン提供作業の検証・リリースに、4⼈×2週間×3回/年 (6⼈⽉) の⼯数をかけていた 14 課題 リリース ⽇程調整 新 バージョン 検証

    リリース リリース 後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) ⼿作業による検証 ・脆弱性チェック ・検証⽤クラスタでの 新機能検証 ・回帰テスト 環境ごとに繰り返すリリース ・設定ファイルリリース ・Kubernetes 関連リリース ・アドオン関連リリース Kubernetes 新バージョン提供のトイル削減 つらすぎる!!!!
  9. トイル削減を⽬指し、バージョン提供作業の⾃動化を進めた 15 ZCP の挑戦 リリース ⽇程調整 新 バージョン 検証 リリース

    リリース 後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) ⼿作業による検証 環境ごとに繰り返すリリース e2e テスト実装や CI pipeline による⾃動化 リリース PR ⾃動作成 bot の実装 K8s/アドオン新バージョン提供のトイル削減
  10. K8s/アドオンの新バージョンの検証を⼿作業で実施していた • 脆弱性スキャン (50+ images) • 検証クラスタでの新機能の検証 • K8s 機能検証

    (5+ cases) • アドオン機能検証 (50+ cases) • 回帰テスト • 基本機能テスト (100+ cases) • 権限テスト (1000+ cases) 3⼈×2週間のコストがかかっていた 16 新バージョン検証の課題 K8s/アドオン新バージョン提供のトイル削減
  11. 検証項⽬の⼤半を、Ginkgo などを使い e2e テスト化し、CI pipeline に組み込んだ テストケースは合計で 約1500件 • 脆弱性スキャンの⾃動化

    (API 利⽤) • 新機能検証の e2e テスト化 • CNCF 公式の k8s-conformance テストの実⾏ (ginkgo) • アドオン⽤ e2e テストの実装・実⾏ (ginkgo) • 回帰テスト • 新機能検証で使⽤した e2e テストの実⾏ (ginkgo) • 権限テストのスクリプト化 (shell) • 社内の他 PF との連携テスト 17 検証項⽬の e2e テスト & pipeline 化 K8s/アドオン新バージョン提供のトイル削減
  12. 4環境に対して新バージョンリリースを繰り返す必要があった リリースは CI/CD 経由で⾏い、リリース⽤ PR をそれぞれ作成しなければならない • 設定ファイルリリース (1PR) •

    K8s 関連リリース (2PR) • アドオン関連リリース (2PR) 全環境で合計 20 PR を作成していた 1⼈×2週間のコストがかかっていた 20 リリースの課題 K8s/アドオン新バージョン提供のトイル削減
  13. 4環境に対して新バージョンリリースを繰り返す必要があった リリースは CI/CD 経由で⾏い、リリース⽤ PR をそれぞれ作成しなければならない • 設定ファイルリリース (1PR) •

    K8s 関連リリース (2PR) • アドオン関連リリース (2PR) 全環境で合計 20 PR を作成していた 1⼈×2週間のコストがかかっていた 21 リリースの課題 K8s/アドオン新バージョン提供のトイル削減
  14. 繰り返す PR を⾃動作成する github bot を実装 24 リリース bot の整備

    KaaS Controller 20 PR の 作成⾃動化 CI/CD K8s/アドオン新バージョン提供のトイル削減
  15. 25 リリース bot の整備 リリース⼿順 管理者 : issue でコマンドを打つ ↓

    Bot : PR 作成 ↓ 管理者 : PR review & merge ↓ CI/CD : リリース K8s/アドオン新バージョン提供のトイル削減
  16. 新バージョン提供作業の検証・リリースを 2⼈×3⽇×3回/年 (0.6 ⼈⽉) で実現した (85% 削減) 27 Before/After リリース

    ⽇程調整 新 バージョン 検証 リリース リリース 後作業 1⼈×3⽇ (-90%) 1⼈×3⽇ (-70%) リリース ⽇程調整 新 バージョン 検証 リリース リリース 後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) 暗黙知の削減にもつながった K8s/アドオン新バージョン提供のトイル削減
  17. 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
  18. OpenStack クラスタがリソース枯渇に陥った場合でも、気軽に増強できない • DC の敷設、費⽤などの制約によって、即座に OpenStack クラスタを増強できないことが多い →この時、リソースに余裕がある別の OpenStack クラスタへ

    k8s クラスタの移⾏が必要な場合があった 30 クラウド課題1: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 などクラウド課題に対する対応
  19. Noisy Neighbor • HV を全体共有しているため、⾃分の k8s クラスタだけでなく、他の k8s クラスタと CPU

    リソースの取 り合いの状態になっている場合がある →この時、⾃分の k8s クラスタだけでなく、他の k8s クラスタのレイテンシの悪化やタイムアウトを発⽣ させてしまうことがある 31 課題2: Noisy Neighbor cpu1 cpu2 cpu3 cpu100 … Noisy Neighbor状態 k8s クラスタB および k8s クラスタC にて レイテンシ悪化、タイムアウト発⽣ 🔥 🔥 🔥 cpu4 🔥 HV k8s クラスタA k8s クラスタB k8s クラスタC HV リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
  20. 別 OpenStack クラスタへの移⾏のつらさ • 前述の課題の対応として、別の OpenStack クラスタへ k8s クラスタへ移⾏を利⽤者に案内していた •

    移⾏作業における⼯程が多かった • ⼯程内では、yaml の書き直しなど⼿動での設定変更項⽬も多かった • 結果として、移⾏作業は3ヶ⽉程度必要で、利⽤者に実施頂く必要があった • HV の減価償却に応じた OpenStack クラスタへの移⾏として、500 クラスタ程度の利⽤者に移⾏対応い ただき、移⾏完了まで 6ヶ⽉以上要した • HVの減価償却に応じた OpenStack クラスタの移⾏は今後も継続的に必要となる 32 課題への対応(Before) リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
  21. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • 移⾏先でのポート開放漏れなどによって、トラフィック全断のリスクなど • [対策1]

    • 移⾏する WorkerNode の割合を指定し、段階的に移⾏できる機能を提供した 34 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
  22. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • 移⾏先でのポート開放漏れなどによって、トラフィック全断のリスクなど • [対策1]

    • 移⾏する WorkerNode の割合を指定し、段階的に移⾏できる機能を提供した 35 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 移⾏先 OpenStack へ WorkerNode 1台作成 1台の WorkerNode を drain する
  23. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • 移⾏先でのポート開放漏れなどによって、トラフィック全断のリスクなど • [対策1]

    • 移⾏する WorkerNode の割合を指定し、段階的に移⾏できる機能を提供した 36 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 残りの WorkerNode を drain する 移⾏先 OpenStack へ WorkerNode を残り3台作成
  24. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • 移⾏先でのポート開放漏れなどによって、トラフィック全断のリスクなど • [対策1]

    • 移⾏する WorkerNode の割合を指定し、段階的に移⾏できる機能を提供した 37 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 drainした WorkerNode を 全て削除
  25. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • [対策2] • 段階的移⾏中は、移⾏前の

    WorkerNode も保持することで迅速な RollBack を実現した • 移⾏前の WorkerNode の再作成を待たずに RollBack 可能 38 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 段階的移⾏中に 問題が発⽣!
  26. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • [対策2] • 段階的移⾏中は、移⾏前の

    WorkerNode も保持することで迅速な RollBack を実現した • 移⾏前の WorkerNode の再作成を待たずに RollBack 可能 39 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 移⾏先 OpenStack の WorkerNode を drain する 移⾏元 WorkerNode の drain を外す
  27. • [課題] • ⼀回で全ての WorkerNode の移⾏を⾏うことはリスクが⼤きい • [対策2] • 段階的移⾏中は、移⾏前の

    WorkerNode も保持することで迅速な RollBack を実現した • 移⾏前の WorkerNode の再作成を待たずに RollBack 可能 40 移⾏機能提供に向けた課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 移⾏先 OpenStack の WorkerNode を削除する
  28. • [課題] • 移⾏状態の整合性担保が難しい • 当初コマンド実⾏による逐次処理として実装していたが、実⾏時にプロセスが落ちた場合な どに、コマンド実⾏による要求と、実際の移⾏状態の整合性の担保が難しかった • クラスタの RollingUpdate

    などによって Node が再作成された場合に node label が維持され ず、整合性の担保が難しかった • [対策] • 移⾏状態を表す、CustomResouceDefinition(CRD): ClusterMigration を定義した • CRD: ClusterMigration に対して監視と調整を⾏うClusterMigrationController を実装した • 利⽤者からのコマンド実⾏では、CRD: ClusterMigration の作成を⾏うものとした 41 移⾏機能実装における課題とその対策 リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
  29. 移⾏機能の処理の流れ 1. ClusterMigrationController が CR: ClusterMigration を watch している 2.

    利⽤者によるコマンド実⾏(zcpctl)で、ClusterMigration が apply される 3. ClusterMigrationContoller が ClusterMigration の定義に従って、古い WorkerNode の drain と新しい WorkerNode を作成する 42 移⾏機能のアーキテクチャ リソース枯渇・Noisy Neighbor などクラウド課題に対する対応
  30. • [Before] 別の OpenStack クラスタへ k8s クラスタへ移⾏を利⽤者に案内していた • 移⾏作業における⼯程が多かった •

    ⼯程内では、yaml の書き直しなど⼿動での設定変更項⽬も多かった • 結果として、移⾏作業は3ヶ⽉程度必要で、利⽤者に実施頂く必要があった • [After] コマンド実⾏のみで WorkerNode の移⾏が可能になった • yaml の書き直しなどの⼿動の設定変更は不要で、既存のリソースを利⽤できる • 60min 以下で移⾏が可能になった 43 Before/After リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 [Before]: 3ヶ⽉程度必要 [After]: 60min 以下で移⾏可能
  31. プライベート KaaS を運⽤する中で直⾯した課題を、システム化によって解決した • K8s/アドオンの新バージョン提供のトイル • e2e テストや CI pipeline

    、リリース bot の実装によって⾃動化 • リソース枯渇・Noisy Neighbor といったクラウドならではの課題 • zcpctl と controller を⽤いた、別 OpenStack クラスタへの移⾏機能提供によって、移⾏ 作業の⼯数を削減 45 まとめ まとめ