ヤフーで KaaS ベースの PaaS ができるまで #cainfra

情報区分: 公開 ヤフーで KaaS ベースの PaaS ができるまで ~ CA.infra #1 ~ ヤフー株式会社 ⼤⾕ 貴之 Copyright (C) 2020 Yahoo © Yahoo Japan Japan Corporation. All Rights Reserved.

情報区分: 公開 ⾃⼰紹介 大谷 貴之（おおたに たかゆき） •所属: ヤフー株式会社 •テクノロジーグループ システム統括本部 クラウドプラットフォーム本部 •業務内容: •エンジニアとして、社内開発者向けの PaaS に関する業務に従事 •クラスタの構築・保守・運用 •追加機能の設計・開発・保守 •利用者のサポート 社内でのアイコン画像 （アイコン設定当時の精神状態を表している） etc. •K8s 関連で関⼼を持っていること: •スケジューリング周りの話、Audi2ng、マルチテナンシー •好きな K8s リソース︓ NetworkPolicy（パズルみたいで組み甲斐がある） •趣味: •散歩、スーパー銭湯、映画鑑賞（映画館によく行く） •音楽鑑賞（フジロックなどのフェスにも参加） © Yahoo Japan 2

情報区分: 公開 このセッションについて ヤフーでは従来よりプライベートクラウドの⼀種として KaaS が存在していましたが、 現在はこれを拡張して PaaS としても運⽤しています。 今回のセッションではこの Kubernetes ベースの PaaS を実現するに⾄った経緯 やその特徴、（時間があれば）これまでにやらかした失敗談 についてご紹介します。 ※ 以降、「Kubernetes」を「K8s」と略している箇所があります。 © Yahoo Japan 3

情報区分: 公開 アジェンダ 1. ヤフーにおけるプライベートクラウド 2. KaaS ベースの PaaS 誕⽣のきっかけ 3. KaaS ベースの PaaS の特徴 4. K と P の間にあるもの 5. 失敗談 6. 今後の課題 7. 最後に © Yahoo Japan 4

情報区分: 公開 アジェンダ 1. ヤフーにおけるプライベートクラウド 2. KaaS ベースの PaaS 誕⽣のきっかけ 3. KaaS ベースの PaaS の特徴 4. K と P の間にあるもの 5. 失敗談 6. 今後の課題 7. 最後に © Yahoo Japan 5

情報区分: 公開 1. ヤフーにおけるプライベートクラウド ヤフーの KaaS とは ヤフーで運⽤しているプライベートクラウドの ⼀つとして KaaS がある。 KaaS • ヤフー⼦会社の Z Lab 社が開発したプロダクト • 2018/08 に正式リリースし、社内で広く使われている • Kubernetes クラスタ⾃体をカスタムリソースとして扱い、 コマンド 1 つで OpenStack 上に VM 群を作成、 必要な設定などを⾏い、 K8s クラスタとしてすぐに使える状態にしてくれる © Yahoo Japan 6

情報区分: 公開 1. ヤフーにおけるプライベートクラウド ヤフーの KaaS とは ヤフーで運⽤しているプライベートクラウドの ⼀つとして KaaS がある。 KaaS • その規模は 2023/02 時点で・・・ • Kubernetes クラスタ数 • VM 数 • コンテナ数 1,200 以上 44,000 以上 770,000 以上 © Yahoo Japan 7

情報区分: 公開 アジェンダ 1. ヤフーにおけるプライベートクラウド 2. KaaS ベースの PaaS 誕⽣のきっかけ 3. KaaS ベースの PaaS の特徴 4. K と P の間にあるもの 5. 失敗談 6. 今後の課題 7. 最後に © Yahoo Japan 8

情報区分: 公開 2. KaaS ベースの PaaS 誕⽣のきっかけ そもそも KaaS と PaaS って︖ 釈迦に説法ですが、 『PaaS vs KaaS: What's the difference, and when does it ma8er?』⽈く・・・ KaaS PaaS Kubernetes as a Service Platform as a Service 開発者がセルフサービスで Kubernetes クラスタを 構築・管理することを可能にするシステム ハードウェアやソフトウェアのデプロイが 抽象化されており、 開発者がコンポーネントを組み合わせるだけで アプリケーションを作成可能なシステム © Yahoo Japan 9

• https://www.cncf.io/online-programs/paas-vs-kaas-whats-the-difference-and-when-does-it-matter/

情報区分: 公開 2. KaaS ベースの PaaS 誕⽣のきっかけ ヤフーの KaaS 管理者が抱えていた課題 •Z Lab 社が開発した KaaS をヤフーでは シングルテナントとして提供しているため・・・ 利⽤者ごとに専⽤ K8s クラスタが存在し、 リソースの利⽤効率がよくない • • 負荷の⼩さい時間帯でも常に最⼤負荷時を 想定した規模のクラスタリソースを 確保しておく必要がある © Yahoo Japan 10

情報区分: 公開 2. KaaS ベースの PaaS 誕⽣のきっかけ ヤフーの KaaS 管理者が抱えていた課題 •Z Lab 社が開発した KaaS をヤフーでは シングルテナントとして提供しているため・・・ 利⽤者ごとに専⽤ K8s クラスタが存在し、 リソースの利⽤効率がよくない • • コントロールプレーンが占める割合が⼤きく、 利⽤者のアプリケーションが稼働可能な 領域がマルチテナントに⽐べて⼩さくなる © Yahoo Japan 11

情報区分: 公開 2. KaaS ベースの PaaS 誕⽣のきっかけ ヤフーの KaaS 管理者が抱えていた課題 •Z Lab 社が開発した KaaS をヤフーでは シングルテナントとして提供しているため・・・ • KaaS の運⽤チームが扱う K8s クラスタの 数が膨⼤で（1000 以上）、 クラスタ群の⼀括更新に時間がかかる © Yahoo Japan 12

情報区分: 公開 2. KaaS ベースの PaaS 誕⽣のきっかけ ヤフーの KaaS 利⽤者が抱えていた課題 •KaaS であるが故に・・・ 利⽤者がアプリケーション開発以外に割くコストが⼤きい • • 利⽤者⾃⾝が強い権限を持ち、K8s クラスタを管理する必要がある • kubectl 以外に、K8s クラスタ⾃体を管理する別の CLI も使う必要がある © Yahoo Japan 13

情報区分: 公開 2. KaaS ベースの PaaS 誕⽣のきっかけ ヤフーの KaaS 利⽤者が抱えていた課題 •KaaS であるが故に・・・ • ほぼ素の K8s クラスタとして扱えるため ⾃由度が⾼い⼀⽅で・・・ • 様々なマニフェストを⽤意する必要があり、 Kubernetes の学習コストが⾼い © Yahoo Japan 14

情報区分: 公開 2. KaaS ベースの PaaS 誕⽣のきっかけ ヤフーの KaaS 利⽤者が抱えていた課題 •KaaS であるが故に・・・ • 社内の他プラットフォームと 連携するための設定も煩雑 © Yahoo Japan 15

情報区分: 公開 2. KaaS ベースの PaaS 誕⽣のきっかけ KaaS ベースの PaaS 誕⽣へ •これらの課題を解決できるプラットフォームのニーズ 「素の Kubernetes よりも簡単に使えるプラットフォームを︕」という声 • もちろん PaaS ではなく KaaS が向いているケースや、 マルチテナントではなくシングルテナントが向いているケースもある • • long running ではないアプリケーション、Stateful なアプリケーション、 GPU の利⽤、CPU Pinning etc. •Kubernetes を基盤とした PaaS を作ればいいのでは︖ • じゃあ、どのように実現するか︖ • KaaS を拡張し、K8s を抽象化したアプリケーション実⾏環境を作ればよい © Yahoo Japan 16

情報区分: 公開 アジェンダ 1. ヤフーにおけるプライベートクラウド 2. KaaS ベースの PaaS 誕⽣のきっかけ 3. KaaS ベースの PaaS の特徴 4. K と P の間にあるもの 5. 失敗談 6. 今後の課題 7. 最後に © Yahoo Japan 17

情報区分: 公開 3. KaaS ベースの PaaS の特徴 複数の K8s クラスタ群で 1 つの⼤きなクラスタを構成 • 1 つのコントロールプレーン⽤ K8s クラスタと、 複数のデータプレーン⽤ K8s クラスタ • クラスタ提供開始後でも データプレーン⽤ K8s クラスタを 追加可能 © Yahoo Japan 18

情報区分: 公開 3. KaaS ベースの PaaS の特徴 マルチテナント • 『KaaS vs PaaS』のところで⾔及された "抽象化" というワード • （私個⼈の意⾒ですが）シングルテナントからマルチテナントにすることも、⼀種の抽象化といえる © Yahoo Japan 19

情報区分: 公開 3. KaaS ベースの PaaS の特徴 マルチテナント • 利⽤者は 1 サービスあたり複数の Namespace をセルフサービスで作成可能 • 利⽤者は⾃⾝が持つ Namespace でアプリケーションをデプロイ するのに必要な最低限の権限のみを持つ © Yahoo Japan 20

情報区分: 公開 3. KaaS ベースの PaaS の特徴 学習コストの低さ •⼀般的な Kubernetes の場合 • アプリケーションの公開までに Deployment, Service, Ingress, PodDisruptionBudget といった種々のマニフェストを扱う必要がある • アプリケーションの Docker イメージは、 ⾃分で Dockerfile を⽤意してビルドする必要があり、 コンテナ初学者にとってはハードルが⾼い © Yahoo Japan 21

情報区分: 公開 3. KaaS ベースの PaaS の特徴 学習コストの低さ •KaaS ベースの PaaS の場合 App というカスタムリソース 1 種類の マニフェストを書くだけでよい • ※ ただし、要件に応じて別途 ConfigMap などを ⽤意する必要はある Source2Image • • 専⽤の Docker プラグインを使⽤することで、 Dockerfile がなくてもソースコードを元に アプリケーションのイメージをビルドできる ※ もちろん⾃前で⽤意した Dockerfile でビルドすることも可能 © Yahoo Japan 22

情報区分: 公開 3. KaaS ベースの PaaS の特徴 学習コストの低さ •最低限必要なマニフェスト（最⼩ 20 ⾏弱の YAML） © Yahoo Japan 23

情報区分: 公開 3. KaaS ベースの PaaS の特徴 他プラットフォームとの親和性 •簡単に社内の他プラットフォームと連携可能 • App マニフェストに数⾏の label や annotation を記述するだけで有効化される 機能 必要な設定（具体例は後述） ロギング App マニフェストでの label 設定でロギングエージェントの収集対象となる トレーシング App マニフェストでの label, annotation 設定でトレーシングのためのエージェントがインストールされる カスタムメトリクス （アプリケーション独⾃実装のメトリクス） App マニフェストでの label, annotation 設定でメトリクスエージェントの収集対象となる 認証・認可のクライアント App マニフェストでの label, annotation 設定で専⽤Sidecarが⾃動挿⼊される 認証・認可のサーバ App マニフェストでの label, annotation 設定で専⽤Sidecarが⾃動挿⼊される mTLS 認証で利⽤可能な X.509 証明書の発⾏ App マニフェストでの label 設定で専⽤Sidecarが⾃動挿⼊される © Yahoo Japan 24

情報区分: 公開 3. KaaS ベースの PaaS の特徴 他プラットフォームとの親和性 •簡単に社内の他プラットフォームと連携可能 • PaaS 利⽤者が追加設定をせずともデフォルトで利⽤可能な機能もいくつかある 機能 設定 共通メトリクス （コンテナ関連のメトリクスなど） 不要（デフォルトでメトリクスエージェントが収集する） 脆弱性検知 不要（デフォルトで、専⽤ WebUI にてイメージに含まれる脆弱性を閲覧可能） © Yahoo Japan 25

情報区分: 公開 3. KaaS ベースの PaaS の特徴 他プラットフォームとの親和性 • ロギング、トレーシング、 認証・認可のクライアント／サーバ、 mTLS 認証で利⽤可能な X.509 証明書の発⾏ それぞれの機能を利⽤する 場合のマニフェスト • 最⼩ 30 ⾏程度 © Yahoo Japan 26

情報区分: 公開 アジェンダ 1. ヤフーにおけるプライベートクラウド 2. KaaS ベースの PaaS 誕⽣のきっかけ 3. KaaS ベースの PaaS の特徴 4. K と P の間にあるもの 5. 失敗談 6. 今後の課題 7. 最後に © Yahoo Japan 27

情報区分: 公開 4. K と P の間にあるもの K と P の間にあるもの 【再掲】そもそも KaaS と PaaS って︖ 『PaaS vs KaaS: What's the difference, and when does it ma8er?』⽈く・・・ KaaS PaaS Kubernetes as a Service Platform as a Service 開発者がセルフサービスで Kubernetes クラスタを 構築・管理することを可能にするシステム ハードウェアやソフトウェアのデプロイが 抽象化されており、 開発者がコンポーネントを組み合わせるだけで アプリケーションを作成可能なシステム © Yahoo Japan 28

• https://www.cncf.io/online-programs/paas-vs-kaas-whats-the-difference-and-when-does-it-matter/

情報区分: 公開 4. K と P の間にあるもの ソフトウェアデプロイの抽象化 •前述の通り、App という カスタムリソースのみを適⽤することで・・・ • コントロールプレーン⽤ K8s クラスタ上に App リソースや、 各種関連カスタムリソースを⽣成 • データプレーン⽤ K8s クラスタ上に Namespace, Deployment, Service, Ingress, PodDisruptionBudget といった、 ワークロードを稼働させるための K8s ビルトインリソースを⽣成 © Yahoo Japan 29

情報区分: 公開 4. K と P の間にあるもの ソフトウェアデプロイの抽象化 •コントロールプレーン⽤ K8s クラスタ上の App リソースについて 以下のツリー構造で、⼦にあたるリソースが ownerReferences で親リソースと紐づいている • • ※ CR ＝ カスタムリソース © Yahoo Japan 30

情報区分: 公開 4. K と P の間にあるもの ソフトウェアデプロイの抽象化 © Yahoo Japan 31

情報区分: 公開 4. K と P の間にあるもの 他プラットフォームとの親和性 •「開発者がコンポーネントを組み合わせるだけで、アプリケーションを作成可能」 • 前述の通り、アプリケーションのマニフェストに 種々の label, annotaPon を指定するだけで・・・ • Sidecar の⾃動挿⼊ • volumeMount の⾃動設定 • など、各種機能の連携に 必要な設定が可能 © Yahoo Japan 32

情報区分: 公開 4. K と P の間にあるもの ロギングプラットフォームとの連携 •Pod 内の各コンテナのログを収集し、ロギング・プラットフォームに送信する © Yahoo Japan 33

情報区分: 公開 4. K と P の間にあるもの 認証・認可のクライアント機能 •サーバへのリクエスト時に必要なトークンを⾃動で取得・更新する © Yahoo Japan 34

情報区分: 公開 4. K と P の間にあるもの 認証・認可のサーバ機能 •Pod 外から受けたリクエストに対し、定義されたポリシーに従って認証・認可を⾏い、 問題なければ他コンテナにリクエストをプロキシする © Yahoo Japan 35

情報区分: 公開 4. K と P の間にあるもの トレーシング機能 •トレーシングエージェント（Dynatrace OneAgent）導⼊のための initContainer を追加し、 エージェントを使⽤するための環境変数や volumeMount を Containers 配下の対象コンテナ に追加する © Yahoo Japan 36

情報区分: 公開 アジェンダ 1. ヤフーにおけるプライベートクラウド 2. KaaS ベースの PaaS 誕⽣のきっかけ 3. KaaS ベースの PaaS の特徴 4. K と P の間にあるもの 5. 失敗談 6. 今後の課題 7. 最後に © Yahoo Japan 37

情報区分: 公開 5. 失敗談 ⾃⾝の起動に⾃⾝が必要になって無限ループ事件 • 起きたこと • マニフェストに所定の label を付与すると、 X.509 証明書を発⾏する Sidecar を⾃動挿⼊する Webhook + Operator を導⼊後・・・ • Operator の Pod が何らかの理由で再起動した際、 様々な Pod が起動しない状態になった • 原因 → スコープの局所化の不⾜ • MutatingWebhook の設定に不備があり、 当該 label の指定有無によらず、あらゆる Pod の⽣成時に 当該 Webhook がコールされていた • Operator の起動に⾃分⾃⾝が必要な状況になってしまい、 永遠に Pod が起動しない状態になった • 対応 • MutatingWebhookConfiguration に objectSelector を追加し、 Sidecar 挿⼊のための label が付与されている場合のみ MutatingWebhook がコールされるようにした © Yahoo Japan 38

情報区分: 公開 5. 失敗談 ConfigMap 無限再⽣成事件 • 起きたこと • 認証・認可⽤ Sidecar を⾃動挿⼊する仕組みで、1 つの App で クライアント⽤ Sidecar とサーバ⽤ Sidecar を併⽤するケースにおいて・・・ • クライアント⽤ Sidecar の ConfigMap と サーバ⽤ Sidecar の ConfigMap がそれぞれ ⼀旦削除された直後に同⼀内容で⽣成されるという 処理が⾼頻度で繰り返され続けた （利⽤者には影響は出なかったが、API Server への無駄な負荷が...） © Yahoo Japan 39

情報区分: 公開 5. 失敗談 ConfigMap 無限再⽣成事件 • 原因 → • ユースケースの考慮不⾜ && スコープの局所化の不⾜ クライアント⽤ ConfigMap に変更があった際、K8s Custom Controlller が reconcile 対象の絞り込み条件で ConfigMap の Owner である App の名前と Namespace しか⾒ておらず、 サーバ⽤ ConfigMap も reconcile 対象になっていた（逆もまた然り） • 対応 • それぞれの Controller の reconcile の処理でクライアント⽤・サーバ⽤の label も⾒るようにした © Yahoo Japan 40

情報区分: 公開 アジェンダ 1. ヤフーにおけるプライベートクラウド 2. KaaS ベースの PaaS 誕⽣のきっかけ 3. KaaS ベースの PaaS の特徴 4. K と P の間にあるもの 5. 失敗談 6. 今後の課題 7. 最後に © Yahoo Japan 41

情報区分: 公開 6. 今後の課題 今後の課題 真の意味で "PaaS" を標榜するには、まだまだやることが沢⼭...︕ • • 各データプレーン⽤ K8s クラスタの隠蔽 • 現状では ResourceQuota がデータプレーン⽤ K8s クラスタごとに 独⽴しており、利⽤者がある程度これらの存在を意識せざるを得ない • PaaS としての 1 クラスタ単位で、⾃分が持つ Namespace の空きが どれぐらいあるのかわかりづらい アプリケーションの可⽤性向上のための啓蒙 • アプリケーションを簡単にデプロイできる⼀⽅で、 可⽤性を⾼めるには利⽤者が頑張らないといけない部分も多い • {startup|readiness|liveness}Probe の適切な設定と使い分け • 同⼀ Pod 内の複数コンテナのライフサイクルを意識した graceful shutdown の実現 ・・・などなど © Yahoo Japan 42

情報区分: 公開 アジェンダ 1. ヤフーにおけるプライベートクラウド 2. KaaS ベースの PaaS 誕⽣のきっかけ 3. KaaS ベースの PaaS の特徴 4. K と P の間にあるもの 5. 失敗談 6. 今後の課題 7. 最後に © Yahoo Japan 43

情報区分: 公開 7. 最後に 最後に •以上、ヤフーで KaaS を拡張して PaaS として社内提供するまでのお話でした •Kubernetes ベースのアプリケーション実⾏環境をマルチテナントで提供するには、 ⾊々な課題があると思います •もし同じようなことをやっているという⽅がいらっしゃいましたら、抱えている 課題や⼯夫したことについて是⾮教えていただけるとありがたいです ご清聴ありがとうございました︕︕ © Yahoo Japan 44

情報区分: 公開 7. 最後に 最後に 〜 質疑応答 〜 © Yahoo Japan 45