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
   

   View Slide

2. © 2021 Cloud Native Computing Foundation
   2
   自己紹介
   Kohei Ota (@inductor)
   •アーキテクト@HPE
   •CNCF Ambassador
   •Google Developer Expert (GCP)
   •CloudNative Days Tokyo 運営
   •昔、コロニーな生活ガチ勢でした
   

   View Slide

3. © 2021 Cloud Native Computing Foundation
   3
   自己紹介
   Kohei Ota (@inductor)
   •アーキテクト@HPE
   •CNCF Ambassador
   •Google Developer Expert (GCP)
   •CloudNative Days Tokyo 運営
   •昔、コロニーな生活ガチ勢でした
   最近好きな本:
   SREの探求
   

   View Slide

4. © 2021 Cloud Native Computing Foundation
   4
   Table of Contents
   改めて Platform for Platforms とは
   KubeCon セッションにおける実例
   エコシステムを用いた様々な実現方法
   まとめ
   

   View Slide

5. Platform for Platforms の考え方
   

   View Slide

6. © 2021 Cloud Native Computing Foundation
   6
   Today’s biggest topic
   

   View Slide

7. © 2021 Cloud Native Computing Foundation
   7
   Today’s biggest topic
   Kubernetesはプラットフォームを作るためのプラットフォーム。それが
   ゴールなのではなく、始まりなのである。
   

   View Slide

8. いい話だなぁ... The end
   

   View Slide

9. んなわきゃない
   

   View Slide

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やリソース
    • 大きなコミュニティとエコシステム
    

    View Slide

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やリソース
    • 大きなコミュニティとエコシステム
    ● 宣言的なリソース管理の仕組み
    ● カスタムリソース定義による拡張性
    ● 様々なベンダー・コミュニティによる実装
    

    View Slide

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
    

    View Slide

13. © 2021 Cloud Native Computing Foundation
    13
    個人的にわかりにくいと思うポイント
    「コンテナをいい感じに管理したい」から Kubernetes に
    入門するとこうした実態とのギャップに驚きやすい
    → Why?
    1. 分散システムという前提が理解できていない場合がある
    2. 運用とともに作り込みが必要な点は既存ツールと同じ
    3. (特に)規模の大きい環境では、Kubernetesが持つ
    標準化の仕組みに乗っかることが利点になっていきやすい
    → 拡大予定なく小さい環境を作り込むメリットが薄い
    

    View Slide

14. © 2021 Cloud Native Computing Foundation
    14
    個人的にわかりにくいと思うポイント
    「コンテナをいい感じに管理したい」から Kubernetes に
    入門するとこうした実態とのギャップに驚きやすい
    → Why?
    1. 分散システムという前提が理解できていない場合がある
    2. 運用とともに作り込みが必要な点は既存ツールと同じ
    3. (特に)規模の大きい環境では、Kubernetesが持つ
    標準化の仕組みに乗っかることが利点になっていきやすい
    → 拡大予定なく小さい環境を作り込むメリットが薄い
    例えば:
    マルチテナント
    例えば:
    オンプレでは難しいコンピュートとス
    トレージの分離
    例えば:
    環境に依存しない
    既存 OSS の活用
    

    View Slide

15. © 2021 Cloud Native Computing Foundation
    15
    個人的にわかりにくいと思うポイント
    「コンテナをいい感じに管理したい」から Kubernetes に
    入門するとこうした実態とのギャップに驚きやすい
    → Why?
    1. 分散システムという前提が理解できていない場合がある
    2. 運用とともに作り込みが必要な点は既存ツールと同じ
    3. (特に)規模の大きい環境では、Kubernetesが持つ
    標準化の仕組みに乗っかることが利点になっていきやすい
    → 拡大予定なく小さい環境を作り込むメリットが薄い
    例えば:
    マルチテナント
    例えば:
    オンプレでは難しいコンピュートとス
    トレージの分離
    例えば:
    環境に依存しない
    既存 OSS の活用
    良くも悪くもオンプレ上で受けられる恩恵が多い (ように見える)
    → このような枠組みの活用こそが「クラウドネイティブ」であるという考
    え方もある
    ※ ただし、クラウドではマネージド Kubernetesもあるので、
    　 それ自体も大きなメリット
    

    View Slide

16. Platform for Platforms とは
    規模拡大につれ必要となる「関心の分離」に
    対する1つの考え方である
    

    View Slide

17. KubeCon セッションにおける実例
    

    View Slide

18. © 2021 Cloud Native Computing Foundation
    18
    ここで1つ前置き
    ここでの解説は私の個人的な意見を多分に含みます
    加えて、時間の都合省略する部分もあります
    発表者の意見を必ずしも反映しているものではないため、
    興味が沸いたものについては実セッション・実スライドを
    ご覧になることを強く推奨します
    

    View Slide

19. © 2021 Cloud Native Computing Foundation
    19
    過去のKubeConで発表されたケーススタディの例
    - 国防総省における利用例 (Istioとかも使ってるやつ)
    - 「国防総省でもK8s入れてるのに入れてないの？」
    - 冗談はさておき DevSecOps の実例としては貴重
    - D2IQ (旧 Mesosphere) とのコラボレーション
    - リードしていた Nicolas 氏の辞職が気になる
    - CERN (世界最大の素粒子物理学研究所)
    - キーノート中にヒッグス粒子の発見を Kubernetes クラスター上で
    シミュレーションして再現していたのが印象的
    - Mesos to Kubernetes な事例
    - Uber とか Appleとか
    - Airbnb における運用知見の継続的な共有
    - 個人的に好きなセッションが多い
    

    View Slide

20. © 2021 Cloud Native Computing Foundation
    20
    過去のKubeConで発表されたケーススタディの例
    - 国防総省における利用例 (Istioとかも使ってるやつ)
    - 「国防総省でもK8s入れてるのに入れてないの？」
    - 冗談はさておき DevSecOps の実例としては貴重
    - D2IQ (旧 Mesosphere) とのコラボレーション
    - リードしていた Nicolas 氏の辞職が気になる
    - CERN (世界最大の素粒子物理学研究所)
    - キーノート中にヒッグス粒子の発見を Kubernetes クラスター上で
    シミュレーションして再現していたのが印象的
    - Mesos to Kubernetes な事例
    - Uber とか Appleとか
    - Airbnb における運用知見の継続的な共有
    - 個人的に好きなセッションが多い
    他にもいろいろありますが
    ここからは特にオモシロイと思ったものを紹介
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

27. © 2021 Cloud Native Computing Foundation
    27
    Airbnb におけるマイクロサービスとの戦い
    よくある VM + Monolithic Rails から Kubernetes + Microserviecs に
    移行する際にぶつかった問題の事例
    YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社
    内ツールを作った話
    他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら
    ないようにするなど、構成管理の工夫も見られました
    KubeCon 以外では、同氏が過去の CloudNative Days で発表した
    マイクロサービス移行におけるサービスプロキシの必要性や
    依存関係との戦いに関するセッションも合わせてご覧ください
    https://www.youtube.com/watch?v=ytu3aUCwlSg
    

    View Slide

28. © 2021 Cloud Native Computing Foundation
    28
    Airbnb におけるマイクロサービスとの戦い
    よくある VM + Monolithic Rails から Kubernetes + Microserviecs に
    移行する際にぶつかった問題の事例
    YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社
    内ツールを作った話
    他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら
    ないようにするなど、構成管理の工夫も見られました
    KubeCon 以外では、同氏が過去の CloudNative Days で発表した
    マイクロサービス移行におけるサービスプロキシの必要性や
    依存関係との戦いに関するセッションも合わせてご覧ください
    https://www.youtube.com/watch?v=ytu3aUCwlSg
    

    View Slide

29. © 2021 Cloud Native Computing Foundation
    29
    Airbnb におけるマイクロサービスとの戦い
    よくある VM + Monolithic Rails から Kubernetes + Microserviecs に
    移行する際にぶつかった問題の事例
    YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社
    内ツールを作った話
    他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら
    ないようにするなど、構成管理の工夫も見られました
    KubeCon 以外では、同氏が過去の CloudNative Days で発表した
    マイクロサービス移行におけるサービスプロキシの必要性や
    依存関係との戦いに関するセッションも合わせてご覧ください
    https://www.youtube.com/watch?v=ytu3aUCwlSg
    

    View Slide

30. © 2021 Cloud Native Computing Foundation
    30
    Airbnb におけるマイクロサービスとの戦い
    よくある VM + Monolithic Rails から Kubernetes + Microserviecs に
    移行する際にぶつかった問題の事例
    YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社
    内ツールを作った話
    他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら
    ないようにするなど、構成管理の工夫も見られました
    KubeCon 以外では、同氏が過去の CloudNative Days で発表した
    マイクロサービス移行におけるサービスプロキシの必要性や
    依存関係との戦いに関するセッションも合わせてご覧ください
    https://www.youtube.com/watch?v=ytu3aUCwlSg
    

    View Slide

31. © 2021 Cloud Native Computing Foundation
    31
    Airbnb におけるマイクロサービスとの戦い
    よくある VM + Monolithic Rails から Kubernetes + Microserviecs に
    移行する際にぶつかった問題の事例
    YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社
    内ツールを作った話
    他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら
    ないようにするなど、構成管理の工夫も見られました
    KubeCon 以外では、同氏が過去の CloudNative Days で発表した
    マイクロサービス移行におけるサービスプロキシの必要性や
    依存関係との戦いに関するセッションも合わせてご覧ください
    https://www.youtube.com/watch?v=ytu3aUCwlSg
    

    View Slide

32. © 2021 Cloud Native Computing Foundation
    32
    Airbnb におけるマイクロサービスとの戦い
    よくある VM + Monolithic Rails から Kubernetes + Microserviecs に
    移行する際にぶつかった問題の事例
    YAML 地獄との戦いに決着をつけるために新規サービスブートストラップ用の社
    内ツールを作った話
    他にも設定ファイルとアプリケーションコードを同時に編集することで構成が腐ら
    ないようにするなど、構成管理の工夫も見られました
    KubeCon 以外では、同氏が過去の CloudNative Days で発表した
    マイクロサービス移行におけるサービスプロキシの必要性や
    依存関係との戦いに関するセッションも合わせてご覧ください
    https://www.youtube.com/watch?v=ytu3aUCwlSg
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

40. © 2021 Cloud Native Computing Foundation
    40
    事例を見て思うこと
    今回紹介した事例はどこもそれなりに規模が大きい
    自前でプラットフォームを作り込んでいくことに
    大きな意義がある組織
    日本国内にもいくつかそうした組織はあるが、
    必ずしもそうではない
    

    View Slide

41. でもこれ大きすぎて参考にならない... 😇
    

    View Slide

42. わかる（それはそう）
    

    View Slide

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ディストロ
    マルチテナントで動かすための仮想的な
    分離の仕組み
    インフラを「触らずに」構成管理
    

    View Slide

44. Kubernetes のエコシステムを用いた
    さまざまな環境の実現
    

    View Slide

45. © 2021 Cloud Native Computing Foundation
    45
    Kubernetes オペレーターを使ったリソース管理
    ML platform、DBaaS、ストレージなど
    「プラットフォーム」を管理する考え方
    

    View Slide

46. © 2021 Cloud Native Computing Foundation
    46
    cert-manager
    Jetstack社発のOSS
    暗号化通信に使う
    証明書の管理
    発行・更新の定義と自
    動化をCRDで管理
    

    View Slide

47. © 2021 Cloud Native Computing Foundation
    47
    Zalando Postgres Operator
    ヨーロッパで展開する
    ファッションEC Zalando
    発のOSS
    Postgres as a Service
    を実現するための
    オペレーター
    

    View Slide

48. © 2021 Cloud Native Computing Foundation
    48
    Cybozu MOCO
    サイボウズ社発のOSS
    MySQL as a Serviceを
    実現するための
    オペレーター
    

    View Slide

49. マルチテナントを実現するための仕組み
    

    View Slide

50. © 2021 Cloud Native Computing Foundation
    50
    Kubernetes における基本的な権限分離
    Namespace + RBAC を用いた環境分離が一般的
    ただしクラスターワイドなリソースは分離が難しい
    

    View Slide

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 を設定
    

    View Slide

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 を設定
    みたいな設定が各テナントごとに生える
    

    View Slide

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 を設定
    みたいな設定が各テナントごとに生える
    クラスターを別で立てれば良いのでは？
    → インフラコストが単純に上がるので
    　 そう簡単に決められない
    

    View Slide

54. © 2021 Cloud Native Computing Foundation
    54
    Hierarchical Namespace の活用
    Namespace に階層構造を作れる仕組み
    親 Namespace と子 Namespace 間で
    継承したいリソースを定義しておくことで権限
    管理のコストを下げることができる
    リソース管理や構成管理など様々な用途
    でも使いやすい
    

    View Slide

55. © 2021 Cloud Native Computing Foundation
    55
    vcluster
    Loft Labs 発の OSS
    Namespace ごとに
    k3s ベースの環境が
    立ち上がり、仮想クラ
    スターとして動作
    Pod 間通信は普通の
    クラスターと同じように動作
    Deployment などはホスト側で管
    理されず仮想クラスター内で完結
    Pod は 実リソースなのでホストクラ
    スターに情報が渡りコンテナが作成
    される (PVなども同様)
    

    View Slide

56. © 2021 Cloud Native Computing Foundation
    56
    Cluster API
    細かい仕様については時間の都合上省略
    様々な環境でクラスターを自動的に作るための
    仕組み
    Anthos とか VMware TKG(Tanzu Kubernetes
    Grid) の中で内部的に使われている
    EKSでも内部的に使われ始めたようです
    

    View Slide

57. © 2021 Cloud Native Computing Foundation
    57
    Cluster API
    細かい仕様については時間の都合上省略
    様々な環境でクラスターを自動的に作るための
    仕組み
    Anthos とか VMware TKG(Tanzu Kubernetes
    Grid) の中で内部的に使われている
    EKSでも内部的に使われ始めたようです
    

    View Slide

58. © 2021 Cloud Native Computing Foundation
    58
    マルチテナントにおける分離レベルの考慮
    分離レベルをどう設定したいか
    - クラスター単位で分離
    - アプリが動くマシン単位で分離
    - 仮想クラスターによる分離
    - Namespace単位で分離
    - コンテナランタイムで分離
    分離レベル
    インフラコスト
    ランタイムとマシン単位の話
    は今回割愛
    Cluster API が活用できるな
    ら便利だけどインフラのコスト
    は高いまま
    

    View Slide

59. © 2021 Cloud Native Computing Foundation
    59
    テナント分離の比較
    Namespace
    分離
    仮想クラスター
    クラスター
    分離
    分離レベル 低い 高い 非常に高い
    各テナントへのアクセス
    Namespace単位なので
    自由度は低い
    仮想クラスター管理者
    であれば可
    クラスター管理者
    であれば可
    インフラコスト 非常に安い 安い 高い
    テナント間における
    リソースの共有
    簡単 簡単 難しい
    オーバーヘッド 少ない 少ない 大きい
    Minimum of three year commitment
    

    View Slide

60. © 2021 Cloud Native Computing Foundation
    60
    テナント分離の比較
    Namespace
    分離
    仮想クラスター
    クラスター
    分離
    分離レベル 低い 高い 非常に高い
    各テナントへのアクセス
    Namespace単位なので
    自由度は低い
    仮想クラスター管理者
    であれば可
    クラスター管理者
    であれば可
    インフラコスト 非常に安い 安い 高い
    テナント間における
    リソースの共有
    簡単 簡単 難しい
    オーバーヘッド 少ない 少ない 大きい
    Minimum of three year commitment
    仮想クラスターの登場によって、分離における選択肢が
    大きく広がりました
    ワークロードやステークホルダーの特性、インフラコストとのバ
    ランスを考えてやっていきましょう
    

    View Slide

61. まとめ
    

    View Slide

62. © 2021 Cloud Native Computing Foundation
    62
    まとめ
    ● Kubernetes の実例は、もはや一言でまとめることができないくらい
    大小さまざまで多様化が進んできた
    ● 運用の辛さを軽減するための自動化、分離、権限管理の仕組みが
    しのぎを削るフェーズとなり、いよいよ利用の広がりが目に見えてきた
    ● プラットフォームを作るための構成要素が増え、選択肢を見据えるための
    目的がとても重要になってきた
    Platform for Platforms とは多様化によって広がるエコシステムの大海原を
    我々開発者/運用者が今一度見直すために必要な、原点のようなものなのかも？
    皆さんの思う Platform for Platforms について、ぜひツイッターで教えて下さい！
    

    View Slide

63. Appendix: 時間があったら
    一瞬だけランタイムの話
    

    View Slide

64. © 2021 Cloud Native Computing Foundation
    64
    ランタイム事情
    Kubernetes 1.24 から Dockershim が完全に消える
    CRI/OCI compliant なランタイム利用が全体に広がる
    これまで Docker 一辺倒だったものが gVisor のようなマルチテナ
    ント前提のランタイムや、Kata, Firecracker などの VM型ランタイ
    ムに置き換えやすくなった
    さらに Krustlet + WASM を使った新しい分離の仕方も・・・
    今ランタイム界は激アツなのです！！
    

    View Slide

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.
    

    View Slide