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

Slide 1

Slide 1 text

システム化で乗り切る 1200 クラスタの KaaS 運⽤ LINEヤフー株式会社サービスインフラグループクラウド統括本部 Cloud Native 本部 Kento Kubo (kenkubo[at]lycorp.co.jp) Kyosuke Mizoguchi (kmizoguc[at]lycorp.co.jp)

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

ZCPについて K8s/アドオン新バージョン提供のトイル削減リソース枯渇・Noisy Neighbor などクラウドの課題に対する対応まとめ 01 03 02 04 3

Slide 4

Slide 4 text

ZCPについて K8s/アドオン新バージョン提供のトイル削減リソース枯渇・Noisy Neighbor などクラウドの課題に対する対応まとめ 01 03 02 04 4

Slide 5

Slide 5 text

ZCP とは 5 • Zlab Container Platform(ZCP) は弊社のプライベート K8s as a Service(KaaS) • 開発者の⾼い⽣産性のためセキュアで運⽤が簡単な k8s クラスタを提供 • 確保されたセキュリティ(監査、脆弱性対応) • SREのプラクティスを簡単に実現 (o11y、アラーティング、運⽤⾃動化) • 全社のサービスが利⽤する極めて重要なプラットフォーム • プラットフォームの稼働率: 99.99% Z Lab / KaaSチーム開発・運⽤提供・管理開発者 etc. ZCP ZCP についてショッピングオークション

Slide 6

Slide 6 text

ZCP の規模 6 2018/08のGAから5年間運⽤して ✔ 1400+ k8s clusters ✔ 996K+ Containers ✔ 57K+ VMs # 2024/04時点これらを20数名で管理 ZCP について

Slide 7

Slide 7 text

プライベート KaaS を運⽤する中で、最近以下の課題に直⾯しました • K8s のライフサイクルに追従するためのトイル • リソース枯渇・Noisy Neighbor といったクラウドならではの課題今回は、これらの課題をどのように解決したかをお話しします 7 KaaS 運⽤のあるある課題 ZCP について

Slide 8

Slide 8 text

ZCPについて K8s/アドオン新バージョン提供のトイル削減リソース枯渇・Noisy Neighbor などクラウド課題に対する対応まとめ 01 03 02 04 8

Slide 9

Slide 9 text

K8s のライフサイクルに合わせて、検証が完了している直近2バージョンを提供している 9 ZCP の k8s バージョン提供 23/11 24/03 24/07 24/11 1.26 1.27 1.28 1.29 K8s/アドオン新バージョン提供のトイル削減

Slide 10

Slide 10 text

ZCP では、⽣の k8s に加えて、独⾃のアドオンをデフォルトで提供している例 : Prometheus / Grafana etc... 10 ZCP の k8s & アドオン管理 addon manager 各種アドオン K8s/アドオン新バージョン提供のトイル削減

Slide 11

Slide 11 text

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/アドオン新バージョン提供のトイル削減

Slide 12

Slide 12 text

12 バージョン提供の仕組み KaaS Controller 開発者 addon manager 各種アドオン 1.27 → 1.28 1.27 → 1.28 Z Lab / KaaSチーム k8s/アドオン提供設定 update K8s/アドオン新バージョン提供のトイル削減

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

トイル削減を⽬指し、バージョン提供作業の⾃動化を進めた 15 ZCP の挑戦リリース⽇程調整新バージョン検証リリースリリース後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) ⼿作業による検証環境ごとに繰り返すリリース e2e テスト実装や CI pipeline による⾃動化リリース PR ⾃動作成 bot の実装 K8s/アドオン新バージョン提供のトイル削減

Slide 16

Slide 16 text

K8s/アドオンの新バージョンの検証を⼿作業で実施していた • 脆弱性スキャン (50+ images) • 検証クラスタでの新機能の検証 • K8s 機能検証 (5+ cases) • アドオン機能検証 (50+ cases) • 回帰テスト • 基本機能テスト (100+ cases) • 権限テスト (1000+ cases) 3⼈×2週間のコストがかかっていた 16 新バージョン検証の課題 K8s/アドオン新バージョン提供のトイル削減

Slide 17

Slide 17 text

検証項⽬の⼤半を、Ginkgo などを使い e2e テスト化し、CI pipeline に組み込んだテストケースは合計で約1500件 • 脆弱性スキャンの⾃動化 (API 利⽤) • 新機能検証の e2e テスト化 • CNCF 公式の k8s-conformance テストの実⾏ (ginkgo) • アドオン⽤ e2e テストの実装・実⾏ (ginkgo) • 回帰テスト • 新機能検証で使⽤した e2e テストの実⾏ (ginkgo) • 権限テストのスクリプト化 (shell) • 社内の他 PF との連携テスト 17 検証項⽬の e2e テスト & pipeline 化 K8s/アドオン新バージョン提供のトイル削減

Slide 18

Slide 18 text

提供中の2バージョンに対して pipeline を実⾏している 3h 程度で⼀連の作業が完了する 18 実際の pipeline K8s/アドオン新バージョン提供のトイル削減

Slide 19

Slide 19 text

過去の障害の再発防⽌ • バージョンアップデート起因の障害について、再発防⽌確認を e2e テストに組み込んでいる検証項⽬のテスト化の限界 • バージョン固有機能など、⼀部の項⽬はテストの実装が難しく、完全⾃動化はできていない • K8s/アドオンの最新知識を把握する⽬的で、新機能検証はあえて⼿動でも確認 19 副次的効果と限界 K8s/アドオン新バージョン提供のトイル削減

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

繰り返す PR を⾃動作成する github bot を実装 24 リリース bot の整備 KaaS Controller 20 PR の作成⾃動化 CI/CD K8s/アドオン新バージョン提供のトイル削減

Slide 23

Slide 23 text

25 リリース bot の整備リリース⼿順管理者 : issue でコマンドを打つ ↓ Bot : PR 作成 ↓ 管理者 : PR review & merge ↓ CI/CD : リリース K8s/アドオン新バージョン提供のトイル削減

Slide 24

Slide 24 text

⼀連のトイル削減に、2⼈×4ヶ⽉程度のリソースを投資した各⼿順ごとに ProcessTime/LeadTime を計測し、優先度を決めて効果を確認しながら実施した 26 コスト K8s/アドオン新バージョン提供のトイル削減

Slide 25

Slide 25 text

新バージョン提供作業の検証・リリースを 2⼈×3⽇×3回/年 (0.6 ⼈⽉) で実現した (85% 削減) 27 Before/After リリース⽇程調整新バージョン検証リリースリリース後作業 1⼈×3⽇ (-90%) 1⼈×3⽇ (-70%) リリース⽇程調整新バージョン検証リリースリリース後作業 3⼈×2週間 (1.5⼈⽉) 1⼈×2週間 (0.5⼈⽉) 暗黙知の削減にもつながった K8s/アドオン新バージョン提供のトイル削減

Slide 26

Slide 26 text

ZCPについて K8s/アドオン新バージョン提供のトイル削減リソース枯渇・Noisy Neighbor などクラウド課題に対する対応まとめ 01 03 02 04 28

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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 などクラウド課題に対する対応

Slide 29

Slide 29 text

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 などクラウド課題に対する対応

Slide 30

Slide 30 text

別 OpenStack クラスタへの移⾏のつらさ • 前述の課題の対応として、別の OpenStack クラスタへ k8s クラスタへ移⾏を利⽤者に案内していた • 移⾏作業における⼯程が多かった • ⼯程内では、yaml の書き直しなど⼿動での設定変更項⽬も多かった • 結果として、移⾏作業は3ヶ⽉程度必要で、利⽤者に実施頂く必要があった • HV の減価償却に応じた OpenStack クラスタへの移⾏として、500 クラスタ程度の利⽤者に移⾏対応いただき、移⾏完了まで 6ヶ⽉以上要した • HVの減価償却に応じた OpenStack クラスタの移⾏は今後も継続的に必要となる 32 課題への対応(Before) リソース枯渇・Noisy Neighbor などクラウド課題に対する対応

Slide 31

Slide 31 text

新規クラスタを作成せず、WorkerNode のみ別 OpenStack クラスタに移⾏する機能を提供する (※ WorkerNode を優先対応しており、CotrolPlane,Ingress も今後対応予定) 33 別 OpenStack クラスタへの移⾏機能を提供リソース枯渇・Noisy Neighbor などクラウド課題に対する対応

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

移⾏機能の処理の流れ 1. ClusterMigrationController が CR: ClusterMigration を watch している 2. 利⽤者によるコマンド実⾏(zcpctl)で、ClusterMigration が apply される 3. ClusterMigrationContoller が ClusterMigration の定義に従って、古い WorkerNode の drain と新しい WorkerNode を作成する 42 移⾏機能のアーキテクチャリソース枯渇・Noisy Neighbor などクラウド課題に対する対応

Slide 41

Slide 41 text

• [Before] 別の OpenStack クラスタへ k8s クラスタへ移⾏を利⽤者に案内していた • 移⾏作業における⼯程が多かった • ⼯程内では、yaml の書き直しなど⼿動での設定変更項⽬も多かった • 結果として、移⾏作業は3ヶ⽉程度必要で、利⽤者に実施頂く必要があった • [After] コマンド実⾏のみで WorkerNode の移⾏が可能になった • yaml の書き直しなどの⼿動の設定変更は不要で、既存のリソースを利⽤できる • 60min 以下で移⾏が可能になった 43 Before/After リソース枯渇・Noisy Neighbor などクラウド課題に対する対応 [Before]: 3ヶ⽉程度必要 [After]: 60min 以下で移⾏可能

Slide 42

Slide 42 text

ZCPについて K8s/アドオン新バージョン提供のトイル削減リソース枯渇・Noisy Neighbor などクラウド課題に対する対応まとめ 01 03 02 04 44

Slide 43

Slide 43 text

プライベート KaaS を運⽤する中で直⾯した課題を、システム化によって解決した • K8s/アドオンの新バージョン提供のトイル • e2e テストや CI pipeline 、リリース bot の実装によって⾃動化 • リソース枯渇・Noisy Neighbor といったクラウドならではの課題 • zcpctl と controller を⽤いた、別 OpenStack クラスタへの移⾏機能提供によって、移⾏作業の⼯数を削減 45 まとめまとめ