KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice

Transcript

1. Platform for Platforms のあり方と その実践 Kohei Ota (@inductor), Architect at HPE/CNCF Ambassador
2. © 2021 Cloud Native Computing Foundation 2 自己紹介 Kohei Ota (@inductor) •アーキテクト@HPE •CNCF Ambassador •Google Developer Expert (GCP) •CloudNative Days Tokyo 運営 •昔、コロニーな生活ガチ勢でした
3. © 2021 Cloud Native Computing Foundation 3 自己紹介 Kohei Ota (@inductor) •アーキテクト@HPE •CNCF Ambassador •Google Developer Expert (GCP) •CloudNative Days Tokyo 運営 •昔、コロニーな生活ガチ勢でした 最近好きな本: SREの探求
4. © 2021 Cloud Native Computing Foundation 4 Table of Contents 改めて Platform for Platforms とは KubeCon セッションにおける実例 エコシステムを用いた様々な実現方法 まとめ
5. Platform for Platforms の考え方
6. © 2021 Cloud Native Computing Foundation 6 Today’s biggest topic
7. © 2021 Cloud Native Computing Foundation 7 Today’s biggest topic Kubernetesはプラットフォームを作るためのプラットフォーム。それが ゴールなのではなく、始まりなのである。
8. いい話だなぁ... The end
9. んなわきゃない
10. © 2021 Cloud Native Computing Foundation 10 Kubernetesの3つの顔 Marketing Committee Technical Oversight Committee Governing Board End User Community Container Orchestration Distributed system Platform for Platforms • 複数の「ノード」を束ねる クラスタリング • 柔軟なジョブスケジューリング • Raftベースの分散KVS • 高速で簡単なスケーリング • ロードバランサーとの統合 • 柔軟で簡単なデプロイ手段 • インフラ基盤との強力な連携 • 拡張を前提に作られた APIやリソース • 大きなコミュニティとエコシステム
11. © 2021 Cloud Native Computing Foundation 11 Kubernetesの3つの顔 Marketing Committee Technical Oversight Committee Governing Board End User Community Container Orchestration Distributed system Platform for Platforms • 複数の「ノード」を束ねる クラスタリング • 柔軟なジョブスケジューリング • Raftベースの分散KVS • 高速で簡単なスケーリング • ロードバランサーとの統合 • 柔軟で簡単なデプロイ手段 • インフラ基盤との強力な連携 • 拡張を前提に作られた APIやリソース • 大きなコミュニティとエコシステム • 宣言的なリソース管理の仕組み • カスタムリソース定義による拡張性 • 様々なベンダー・コミュニティによる実装
12. © 2021 Cloud Native Computing Foundation 12 Kubernetes が生まれてから6年... •Borg の思想から生まれた OSS は”えんたーぷらいず”で騒 がれるまで急速に成長 – マルチテナントなど要件の厳しい環境を実現するため セキュリティやクラスター管理の仕組みが成長 – GitOpsを軸としたエッジ、IoT環境の管理など IoT Edge & More Security Cloud Native Cluster API Kubernetes is Boring Security and Observability Introduction of Operators 2015 2016 2017 2018 2019 2020 Kubernetes release 2021 Platform for Platforms
13. © 2021 Cloud Native Computing Foundation 13 個人的にわかりにくいと思うポイント 「コンテナをいい感じに管理したい」から Kubernetes に 入門するとこうした実態とのギャップに驚きやすい → Why? 1. 分散システムという前提が理解できていない場合がある 2. 運用とともに作り込みが必要な点は既存ツールと同じ 3. (特に)規模の大きい環境では、Kubernetesが持つ 標準化の仕組みに乗っかることが利点になっていきやすい → 拡大予定なく小さい環境を作り込むメリットが薄い
14. © 2021 Cloud Native Computing Foundation 14 個人的にわかりにくいと思うポイント 「コンテナをいい感じに管理したい」から Kubernetes に 入門するとこうした実態とのギャップに驚きやすい → Why? 1. 分散システムという前提が理解できていない場合がある 2. 運用とともに作り込みが必要な点は既存ツールと同じ 3. (特に)規模の大きい環境では、Kubernetesが持つ 標準化の仕組みに乗っかることが利点になっていきやすい → 拡大予定なく小さい環境を作り込むメリットが薄い 例えば: マルチテナント 例えば: オンプレでは難しいコンピュートとス トレージの分離 例えば: 環境に依存しない 既存 OSS の活用
15. © 2021 Cloud Native Computing Foundation 15 個人的にわかりにくいと思うポイント 「コンテナをいい感じに管理したい」から Kubernetes に 入門するとこうした実態とのギャップに驚きやすい → Why? 1. 分散システムという前提が理解できていない場合がある 2. 運用とともに作り込みが必要な点は既存ツールと同じ 3. (特に)規模の大きい環境では、Kubernetesが持つ 標準化の仕組みに乗っかることが利点になっていきやすい → 拡大予定なく小さい環境を作り込むメリットが薄い 例えば: マルチテナント 例えば: オンプレでは難しいコンピュートとス トレージの分離 例えば: 環境に依存しない 既存 OSS の活用 良くも悪くもオンプレ上で受けられる恩恵が多い (ように見える) → このような枠組みの活用こそが「クラウドネイティブ」であるという考 え方もある ※ ただし、クラウドではマネージド Kubernetesもあるので、 　 それ自体も大きなメリット
16. Platform for Platforms とは 規模拡大につれ必要となる「関心の分離」に 対する1つの考え方である
17. KubeCon セッションにおける実例
18. © 2021 Cloud Native Computing Foundation 18 ここで1つ前置き ここでの解説は私の個人的な意見を多分に含みます 加えて、時間の都合省略する部分もあります 発表者の意見を必ずしも反映しているものではないため、 興味が沸いたものについては実セッション・実スライドを ご覧になることを強く推奨します
19. © 2021 Cloud Native Computing Foundation 19 過去のKubeConで発表されたケーススタディの例 - 国防総省における利用例 (Istioとかも使ってるやつ) - 「国防総省でもK8s入れてるのに入れてないの？」 - 冗談はさておき DevSecOps の実例としては貴重 - D2IQ (旧 Mesosphere) とのコラボレーション - リードしていた Nicolas 氏の辞職が気になる - CERN (世界最大の素粒子物理学研究所) - キーノート中にヒッグス粒子の発見を Kubernetes クラスター上で シミュレーションして再現していたのが印象的 - Mesos to Kubernetes な事例 - Uber とか Appleとか - Airbnb における運用知見の継続的な共有 - 個人的に好きなセッションが多い
20. © 2021 Cloud Native Computing Foundation 20 過去のKubeConで発表されたケーススタディの例 - 国防総省における利用例 (Istioとかも使ってるやつ) - 「国防総省でもK8s入れてるのに入れてないの？」 - 冗談はさておき DevSecOps の実例としては貴重 - D2IQ (旧 Mesosphere) とのコラボレーション - リードしていた Nicolas 氏の辞職が気になる - CERN (世界最大の素粒子物理学研究所) - キーノート中にヒッグス粒子の発見を Kubernetes クラスター上で シミュレーションして再現していたのが印象的 - Mesos to Kubernetes な事例 - Uber とか Appleとか - Airbnb における運用知見の継続的な共有 - 個人的に好きなセッションが多い 他にもいろいろありますが ここからは特にオモシロイと思ったものを紹介
21. © 2021 Cloud Native Computing Foundation 21 Mesos to Kubernetes な事例 計算リソースを管理するための Apache Mesos を Kubernetes に移行する事例 数千個のマイクロサービスが1日平均1000回以上デプロイされる10000台以上 のインスタンス(コンテナは10万台オーダー)で作られたインフラ ベアメタル → 静的環境でのコンテナ配置 → Mesos + Apache Aurora → Mesos + Peloton (社内独自のスケジュー リングフレームワーク) と変遷 将来的な規模拡大や拡張性が懸念となり、Kubernetes 移行を決断 移行にあたって検証したことや比較の詳細などが描かれている https://www.youtube.com/watch?v=91c3iUI2K7M
22. © 2021 Cloud Native Computing Foundation 22 Mesos to Kubernetes な事例 計算リソースを管理するための Apache Mesos を Kubernetes に移行する事例 数千個のマイクロサービスが1日平均1000回以上デプロイされる10000台以上 のインスタンス(コンテナは10万台オーダー)で作られたインフラ ベアメタル → 静的環境でのコンテナ配置 → Mesos + Apache Aurora → Mesos + Peloton (社内独自のスケジュー リングフレームワーク) と変遷 将来的な規模拡大や拡張性が懸念となり、Kubernetes 移行を決断 移行にあたって検証したことや比較の詳細などが描かれている https://www.youtube.com/watch?v=91c3iUI2K7M
23. © 2021 Cloud Native Computing Foundation 23 Mesos to Kubernetes な事例 計算リソースを管理するための Apache Mesos を Kubernetes に移行する事例 数千個のマイクロサービスが1日平均1000回以上デプロイされる10000台以上 のインスタンス(コンテナは10万台オーダー)で作られたインフラ ベアメタル → 静的環境でのコンテナ配置 → Mesos + Apache Aurora → Mesos + Peloton (社内独自のスケジュー リングフレームワーク) と変遷 将来的な規模拡大や拡張性が懸念となり、Kubernetes 移行を決断 移行にあたって検証したことや比較の詳細などが描かれている https://www.youtube.com/watch?v=91c3iUI2K7M
24. © 2021 Cloud Native Computing Foundation 24 Mesos to Kubernetes な事例 計算リソースを管理するための Apache Mesos を Kubernetes に移行する事例 数千個のマイクロサービスが1日平均1000回以上デプロイされる10000台以上 のインスタンス(コンテナは10万台オーダー)で作られたインフラ ベアメタル → 静的環境でのコンテナ配置 → Mesos + Apache Aurora → Mesos + Peloton (社内独自のスケジュー リングフレームワーク) と変遷 将来的な規模拡大や拡張性が懸念となり、Kubernetes 移行を決断 移行にあたって検証したことや比較の詳細などが描かれている https://www.youtube.com/watch?v=91c3iUI2K7M
25. © 2021 Cloud Native Computing Foundation 25 Mesos to Kubernetes な事例 計算リソースを管理するための Apache Mesos を Kubernetes に移行する事例 数千個のマイクロサービスが1日平均1000回以上デプロイされる10000台以上 のインスタンス(コンテナは10万台オーダー)で作られたインフラ ベアメタル → 静的環境でのコンテナ配置 → Mesos + Apache Aurora → Mesos + Peloton (社内独自のスケジュー リングフレームワーク) と変遷 将来的な規模拡大や拡張性が懸念となり、Kubernetes 移行を決断 移行にあたって検証したことや比較の詳細などが描かれている https://www.youtube.com/watch?v=91c3iUI2K7M
26. © 2021 Cloud Native Computing Foundation 26 Mesos to Kubernetes な事例 計算リソースを管理するための Apache Mesos を Kubernetes に移行する事例 数千個のマイクロサービスが1日平均1000回以上デプロイされる10000台以上 のインスタンス(コンテナは10万台オーダー)で作られたインフラ ベアメタル → 静的環境でのコンテナ配置 → Mesos + Apache Aurora → Mesos + Peloton (社内独自のスケジュー リングフレームワーク) と変遷 将来的な規模拡大や拡張性が懸念となり、Kubernetes 移行を決断 移行にあたって検証したことや比較の詳細などが描かれている https://www.youtube.com/watch?v=91c3iUI2K7M
27. © 2021 Cloud Native Computing Foundation 27 Airbnb におけるマイクロサービスとの戦い よくある VM + Monolithic Rails から Kubernetes + Microserviecs に 移行する際にぶつかった問題の事例 YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社 内ツールを作った話 他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら ないようにするなど、構成管理の工夫も見られました KubeCon 以外では、同氏が過去の CloudNative Days で発表した マイクロサービス移行におけるサービスプロキシの必要性や 依存関係との戦いに関するセッションも合わせてご覧ください https://www.youtube.com/watch?v=ytu3aUCwlSg
28. © 2021 Cloud Native Computing Foundation 28 Airbnb におけるマイクロサービスとの戦い よくある VM + Monolithic Rails から Kubernetes + Microserviecs に 移行する際にぶつかった問題の事例 YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社 内ツールを作った話 他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら ないようにするなど、構成管理の工夫も見られました KubeCon 以外では、同氏が過去の CloudNative Days で発表した マイクロサービス移行におけるサービスプロキシの必要性や 依存関係との戦いに関するセッションも合わせてご覧ください https://www.youtube.com/watch?v=ytu3aUCwlSg
29. © 2021 Cloud Native Computing Foundation 29 Airbnb におけるマイクロサービスとの戦い よくある VM + Monolithic Rails から Kubernetes + Microserviecs に 移行する際にぶつかった問題の事例 YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社 内ツールを作った話 他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら ないようにするなど、構成管理の工夫も見られました KubeCon 以外では、同氏が過去の CloudNative Days で発表した マイクロサービス移行におけるサービスプロキシの必要性や 依存関係との戦いに関するセッションも合わせてご覧ください https://www.youtube.com/watch?v=ytu3aUCwlSg
30. © 2021 Cloud Native Computing Foundation 30 Airbnb におけるマイクロサービスとの戦い よくある VM + Monolithic Rails から Kubernetes + Microserviecs に 移行する際にぶつかった問題の事例 YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社 内ツールを作った話 他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら ないようにするなど、構成管理の工夫も見られました KubeCon 以外では、同氏が過去の CloudNative Days で発表した マイクロサービス移行におけるサービスプロキシの必要性や 依存関係との戦いに関するセッションも合わせてご覧ください https://www.youtube.com/watch?v=ytu3aUCwlSg
31. © 2021 Cloud Native Computing Foundation 31 Airbnb におけるマイクロサービスとの戦い よくある VM + Monolithic Rails から Kubernetes + Microserviecs に 移行する際にぶつかった問題の事例 YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社 内ツールを作った話 他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら ないようにするなど、構成管理の工夫も見られました KubeCon 以外では、同氏が過去の CloudNative Days で発表した マイクロサービス移行におけるサービスプロキシの必要性や 依存関係との戦いに関するセッションも合わせてご覧ください https://www.youtube.com/watch?v=ytu3aUCwlSg
32. © 2021 Cloud Native Computing Foundation 32 Airbnb におけるマイクロサービスとの戦い よくある VM + Monolithic Rails から Kubernetes + Microserviecs に 移行する際にぶつかった問題の事例 YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社 内ツールを作った話 他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら ないようにするなど、構成管理の工夫も見られました KubeCon 以外では、同氏が過去の CloudNative Days で発表した マイクロサービス移行におけるサービスプロキシの必要性や 依存関係との戦いに関するセッションも合わせてご覧ください https://www.youtube.com/watch?v=ytu3aUCwlSg
33. © 2021 Cloud Native Computing Foundation 33 Walmart の Edge + Istio な事例 世界最大のスーパーマーケットチェーン Walmart の店舗に置かれている POS レジの仕組みを Kubernetes + Edge + Istio で作ったという話 旧態依然なオンプレの仕組みを置き換えたいが、単にクラウド移行してもいちい ちクラウドと通信していては決済時の体験が非常に悪い 店舗に自律動作可能な何かを置けば良いのでは？ → 店舗にクラスターを置いちゃえ！という思い切りのある事例 おもしろポイント 1. クラスター構成は GitOps で配信 (オンサイトでの作業を減らす) 2. Istio を使い、店舗のサービスが死んだ場合はクラウド側と 通信するような仕組みを実現 https://www.youtube.com/watch?v=sfPFrvDvdlk
34. © 2021 Cloud Native Computing Foundation 34 Walmart の Edge + Istio な事例 世界最大のスーパーマーケットチェーン Walmart の店舗に置かれている POS レジの仕組みを Kubernetes + Edge + Istio で作ったという話 旧態依然なオンプレの仕組みを置き換えたいが、単にクラウド移行してもいちい ちクラウドと通信していては決済時の体験が非常に悪い 店舗に自律動作可能な何かを置けば良いのでは？ → 店舗にクラスターを置いちゃえ！という思い切りのある事例 おもしろポイント 1. クラスター構成は GitOps で配信 (オンサイトでの作業を減らす) 2. Istio を使い、店舗のサービスが死んだ場合はクラウド側と 通信するような仕組みを実現 https://www.youtube.com/watch?v=sfPFrvDvdlk
35. © 2021 Cloud Native Computing Foundation 35 Walmart の Edge + Istio な事例 世界最大のスーパーマーケットチェーン Walmart の店舗に置かれている POS レジの仕組みを Kubernetes + Edge + Istio で作ったという話 旧態依然なオンプレの仕組みを置き換えたいが、単にクラウド移行してもいちい ちクラウドと通信していては決済時の体験が非常に悪い 店舗に自律動作可能な何かを置けば良いのでは？ → 店舗にクラスターを置いちゃえ！という思い切りのある事例 おもしろポイント 1. クラスター構成は GitOps で配信 (オンサイトでの作業を減らす) 2. Istio を使い、店舗のサービスが死んだ場合はクラウド側と 通信するような仕組みを実現 https://www.youtube.com/watch?v=sfPFrvDvdlk
36. © 2021 Cloud Native Computing Foundation 36 Walmart の Edge + Istio な事例 世界最大のスーパーマーケットチェーン Walmart の店舗に置かれている POS レジの仕組みを Kubernetes + Edge + Istio で作ったという話 旧態依然なオンプレの仕組みを置き換えたいが、単にクラウド移行してもいちい ちクラウドと通信していては決済時の体験が非常に悪い 店舗に自律動作可能な何かを置けば良いのでは？ → 店舗にクラスターを置いちゃえ！という思い切りのある事例 おもしろポイント 1. クラスター構成は GitOps で配信 (オンサイトでの作業を減らす) 2. Istio を使い、店舗のサービスが死んだ場合はクラウド側と 通信するような仕組みを実現 https://www.youtube.com/watch?v=sfPFrvDvdlk
37. © 2021 Cloud Native Computing Foundation 37 Walmart の Edge + Istio な事例 世界最大のスーパーマーケットチェーン Walmart の店舗に置かれている POS レジの仕組みを Kubernetes + Edge + Istio で作ったという話 旧態依然なオンプレの仕組みを置き換えたいが、単にクラウド移行してもいちい ちクラウドと通信していては決済時の体験が非常に悪い 店舗に自律動作可能な何かを置けば良いのでは？ → 店舗にクラスターを置いちゃえ！という思い切りのある事例 おもしろポイント 1. クラスター構成は GitOps で配信 (オンサイトでの作業を減らす) 2. Istio を使い、店舗のサービスが死んだ場合はクラウド側と 通信するような仕組みを実現 https://www.youtube.com/watch?v=sfPFrvDvdlk
38. © 2021 Cloud Native Computing Foundation 38 Walmart の Edge + Istio な事例 世界最大のスーパーマーケットチェーン Walmart の店舗に置かれている POS レジの仕組みを Kubernetes + Edge + Istio で作ったという話 旧態依然なオンプレの仕組みを置き換えたいが、単にクラウド移行してもいちい ちクラウドと通信していては決済時の体験が非常に悪い 店舗に自律動作可能な何かを置けば良いのでは？ → 店舗にクラスターを置いちゃえ！という思い切りのある事例 おもしろポイント 1. クラスター構成は GitOps で配信 (オンサイトでの作業を減らす) 2. Istio を使い、店舗のサービスが死んだ場合はクラウド側と 通信するような仕組みを実現 https://www.youtube.com/watch?v=sfPFrvDvdlk
39. © 2021 Cloud Native Computing Foundation 39 Walmart の Edge + Istio な事例 世界最大のスーパーマーケットチェーン Walmart の店舗に置かれている POS レジの仕組みを Kubernetes + Edge + Istio で作ったという話 旧態依然なオンプレの仕組みを置き換えたいが、単にクラウド移行してもいちい ちクラウドと通信していては決済時の体験が非常に悪い 店舗に自律動作可能な何かを置けば良いのでは？ → 店舗にクラスターを置いちゃえ！という思い切りのある事例 おもしろポイント 1. クラスター構成は GitOps で配信 (オンサイトでの作業を減らす) 2. Istio を使い、店舗のサービスが死んだ場合はクラウド側と 通信するような仕組みを実現 https://www.youtube.com/watch?v=sfPFrvDvdlk
40. © 2021 Cloud Native Computing Foundation 40 事例を見て思うこと 今回紹介した事例はどこもそれなりに規模が大きい 自前でプラットフォームを作り込んでいくことに 大きな意義がある組織 日本国内にもいくつかそうした組織はあるが、 必ずしもそうではない
41. でもこれ大きすぎて参考にならない... 😇
42. わかる（それはそう）
43. © 2021 Cloud Native Computing Foundation 43 Kubernetes が生まれてから6年... •Borg の思想から生まれた OSS は”えんたーぷらいず”で騒 がれるまで急速に成長 – マルチテナントなど要件の厳しい環境を実現するため セキュリティやクラスター管理の仕組みが成長 – GitOpsを軸としたエッジ、IoT環境の管理など IoT Edge & More Security Cloud Native Cluster API Getting Boring Security and Observability Introduction of Operators 2015 2016 2017 2018 2019 2020 Kubernetes release 2021 Platform for Platforms Kubernetes上でさまざまなリソースのラ イフサイクルを管理 Kubernetesクラスター自体を複数管理 できるようにするための仕組み リソース要求の厳しい環境でも動く 軽量なKubernetesディストロ マルチテナントで動かすための仮想的な 分離の仕組み インフラを「触らずに」構成管理
44. Kubernetes のエコシステムを用いた さまざまな環境の実現
45. © 2021 Cloud Native Computing Foundation 45 Kubernetes オペレーターを使ったリソース管理 ML platform、DBaaS、ストレージなど 「プラットフォーム」を管理する考え方
46. © 2021 Cloud Native Computing Foundation 46 cert-manager Jetstack社発のOSS 暗号化通信に使う 証明書の管理 発行・更新の定義と自 動化をCRDで管理
47. © 2021 Cloud Native Computing Foundation 47 Zalando Postgres Operator ヨーロッパで展開する ファッションEC Zalando 発のOSS Postgres as a Service を実現するための オペレーター
48. © 2021 Cloud Native Computing Foundation 48 Cybozu MOCO サイボウズ社発のOSS MySQL as a Serviceを 実現するための オペレーター
49. マルチテナントを実現するための仕組み
50. © 2021 Cloud Native Computing Foundation 50 Kubernetes における基本的な権限分離 Namespace + RBAC を用いた環境分離が一般的 ただしクラスターワイドなリソースは分離が難しい
51. © 2021 Cloud Native Computing Foundation 51 Namespace を使ったシンプルな権限分離の例 - Namespace: dev-1 - dev-1 内だけでリソースを触れるような RBAC を設定 - Namespace: staging - クラスター運用者相当または CD tool のみが操作可能 - Namespace: production - クラスター管理者相当または CD tool のみが操作可能 - Namespace: monitoring - クラスター内メトリクスが取得可能な RBAC を設定
52. © 2021 Cloud Native Computing Foundation 52 テナントが増えてくると... - Namespace: tenant-0-dev - Tenant 0の開発者がリソースを触れるような RBAC を設定 - Namespace: staging-tenant-0 - Tenant 0の運用者または CD tool のみが操作可能 - Namespace: production-tenant-0 - Tenant 0の管理者相当または CD tool のみが操作可能 - Namespace: monitoring-tenant-0 - Tenant 0の内メトリクスが取得可能な RBAC を設定 みたいな設定が各テナントごとに生える
53. © 2021 Cloud Native Computing Foundation 53 テナントが増えてくると... - Namespace: tenant-0-dev - Tenant 0の開発者がリソースを触れるような RBAC を設定 - Namespace: staging-tenant-0 - Tenant 0の運用者または CD tool のみが操作可能 - Namespace: staging-tenant-0 - Tenant 0の管理者相当または CD tool のみが操作可能 - Namespace: staging-tenant-0 - Tenant 0の内メトリクスが取得可能な RBAC を設定 みたいな設定が各テナントごとに生える クラスターを別で立てれば良いのでは？ → インフラコストが単純に上がるので 　 そう簡単に決められない
54. © 2021 Cloud Native Computing Foundation 54 Hierarchical Namespace の活用 Namespace に階層構造を作れる仕組み 親 Namespace と子 Namespace 間で 継承したいリソースを定義しておくことで権限 管理のコストを下げることができる リソース管理や構成管理など様々な用途 でも使いやすい
55. © 2021 Cloud Native Computing Foundation 55 vcluster Loft Labs 発の OSS Namespace ごとに k3s ベースの環境が 立ち上がり、仮想クラ スターとして動作 Pod 間通信は普通の クラスターと同じように動作 Deployment などはホスト側で管 理されず仮想クラスター内で完結 Pod は 実リソースなのでホストクラ スターに情報が渡りコンテナが作成 される (PVなども同様)
56. © 2021 Cloud Native Computing Foundation 56 Cluster API 細かい仕様については時間の都合上省略 様々な環境でクラスターを自動的に作るための 仕組み Anthos とか VMware TKG(Tanzu Kubernetes Grid) の中で内部的に使われている EKSでも内部的に使われ始めたようです
57. © 2021 Cloud Native Computing Foundation 57 Cluster API 細かい仕様については時間の都合上省略 様々な環境でクラスターを自動的に作るための 仕組み Anthos とか VMware TKG(Tanzu Kubernetes Grid) の中で内部的に使われている EKSでも内部的に使われ始めたようです
58. © 2021 Cloud Native Computing Foundation 58 マルチテナントにおける分離レベルの考慮 分離レベルをどう設定したいか - クラスター単位で分離 - アプリが動くマシン単位で分離 - 仮想クラスターによる分離 - Namespace単位で分離 - コンテナランタイムで分離 分離レベル インフラコスト ランタイムとマシン単位の話 は今回割愛 Cluster API が活用できるな ら便利だけどインフラのコスト は高いまま
59. © 2021 Cloud Native Computing Foundation 59 テナント分離の比較 Namespace 分離 仮想クラスター クラスター 分離 分離レベル 低い 高い 非常に高い 各テナントへのアクセス Namespace単位なので 自由度は低い 仮想クラスター管理者 であれば可 クラスター管理者 であれば可 インフラコスト 非常に安い 安い 高い テナント間における リソースの共有 簡単 簡単 難しい オーバーヘッド 少ない 少ない 大きい Minimum of three year commitment
60. © 2021 Cloud Native Computing Foundation 60 テナント分離の比較 Namespace 分離 仮想クラスター クラスター 分離 分離レベル 低い 高い 非常に高い 各テナントへのアクセス Namespace単位なので 自由度は低い 仮想クラスター管理者 であれば可 クラスター管理者 であれば可 インフラコスト 非常に安い 安い 高い テナント間における リソースの共有 簡単 簡単 難しい オーバーヘッド 少ない 少ない 大きい Minimum of three year commitment 仮想クラスターの登場によって、分離における選択肢が 大きく広がりました ワークロードやステークホルダーの特性、インフラコストとのバ ランスを考えてやっていきましょう
61. まとめ
62. © 2021 Cloud Native Computing Foundation 62 まとめ • Kubernetes の実例は、もはや一言でまとめることができないくらい 大小さまざまで多様化が進んできた • 運用の辛さを軽減するための自動化、分離、権限管理の仕組みが しのぎを削るフェーズとなり、いよいよ利用の広がりが目に見えてきた • プラットフォームを作るための構成要素が増え、選択肢を見据えるための 目的がとても重要になってきた Platform for Platforms とは多様化によって広がるエコシステムの大海原を 我々開発者/運用者が今一度見直すために必要な、原点のようなものなのかも？ 皆さんの思う Platform for Platforms について、ぜひツイッターで教えて下さい！
63. Appendix: 時間があったら 一瞬だけランタイムの話
64. © 2021 Cloud Native Computing Foundation 64 ランタイム事情 Kubernetes 1.24 から Dockershim が完全に消える CRI/OCI compliant なランタイム利用が全体に広がる これまで Docker 一辺倒だったものが gVisor のようなマルチテナ ント前提のランタイムや、Kata, Firecracker などの VM型ランタイ ムに置き換えやすくなった さらに Krustlet + WASM を使った新しい分離の仕方も・・・ 今ランタイム界は激アツなのです！！
65. Thank you for your attention! The CNCF aims to help end users connect with other end users, recruit talent, and adopt cloud native successfully in a vendor neutral environment.