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