KubeCon + CloudNativeCon North America 2020 における Building a Global Supercomputer with Virtual Kubelet という講演を振り返りながら、Kubernetes における multi-cluster scheduling の最新情報と現時点での課題を紹介します。

1. Building a Global Supercomputer
with Virtual Kubelet
Dmitry Mishin, University of California San Diego & Adrien Trouillaud, Admiralty
Shingo Omura, Preferred Networks, Inc.
2020/12/22(Tue) Kubernetes Meetup Tokyo #37
KubeCon + CloudNativeCon North America 2020 Recap

2. 自己紹介 - 大村伸吾 (Shingo Omura)
● エンジニア, Preferred Networks, Inc.
○ 社内向けGPUクラスタの開発運用
○ 主にkubernetes sig-scheduling で活動中
● @everpeace (twitter)
● shingo.omura (facebook)
2

3. PFN における機械学習クラスタ関連の最近のスライド
3
Cloud Native Days Tokyo 2020
SlideShare, Video

4. 4KubeCon + CloudNativeCon North America 2020 Virtual: Building a Global Supercomputer with Virtual Kubelet

5. 5
Overview of this session
● University of California San Diego (UCSD) の
Pacific Research Platform (PRP) で作っている
Nautilus という Global Hyper Cluster (with Kubernetes) を構築中
● Admiralty (admiralty.io) という"decentralized" multi-cluster schedulerを
使ってFederated Schedulingをどう実現しているを解説
(OSS & 商用版あり)

6. 6
なぜこの講演をRecapするのか

7. この講演をRecapする理由
● 抱える課題/ユースケースがPFNの機械学習クラスタと似ている
○ 複数 Kubernetes Cluster で Federated Scheduling 出来る
Super Computerを構築したい
● Virtual Kubelet + Scheduling Framework を活用した
Federated Scheduling の実装である (kubefedと大きく違う)
○ このアーキテクチャと共にAdmiralty (admiralty.io) の可能性を
以前から検討しており、今回事例として出てきたので注目
● この講演を通してFederated Scheduling 実現の難しさも
併せて見えてくる
7

8. PFN における Kubernetes環境
8
Icon pack by Icons8 - https://icons8.com
多くの研究者
オンプレ GPU Clusters
Cluster on AWS
(Burst用)
計算Cluster を
選ぶ必要がある

9. Federated Schedulingの必要性
9
Icon pack by Icons8 - https://icons8.com
多くの研究者
オンプレ GPU Clusters
Cluster on AWS
(Burst用)
いい感じにどっかでやっ
てほしい

10. 魅力的な
タイトル!!
KubeCon + CloudNativeCon North America 2020 Virtual: Building a Global Supercomputer with Virtual Kubelet

11. 11
(再) Overview of this session
● University of California San Diego (UCSD) の
Pacific Research Platform (PRP) で作っている
Nautilus という Global Hyper Cluster (with Kubernetes) を構築中
● Admiralty (admiralty.io) という"decentralized" multi-cluster schedulerを
使ってFederated Schedulingをどう実現しているを解説
(OSS & 商用版あり)

12. KubeCon + CloudNativeCon North America 2020 Virtual: Building a Global Supercomputer with Virtual Kubelet
Nautilus (global hyper cluster) の概要
アメリカ
だけじゃなく
Europe & APAC
にも広がっている
Transoceanic
Nodesなんてのも
見える

13. KubeCon + CloudNativeCon North America 2020 Virtual: Building a Global Supercomputer with Virtual Kubelet
Nautilus (global hyper cluster) の概要
Pacific Research
Platformの
Nautilusの規模
UCSDのExpanse
というスパコンも
Federate予定
最終的には
200,000 cores
になるらしい
Cloudによる
Burstingも
行っている

14. Nautilus における Federation への要求
各拠点はそれぞれ運用組織が違うので
独立に制御したい
ルールやポリシーも
独立に運用・強制したい
namespaceレベルで
federationを利用させたい
(admin作業はできるだけ少なく )
KubeCon + CloudNativeCon North America 2020 Virtual: Building a Global Supercomputer with Virtual Kubelet

15. KubeCon + CloudNativeCon North America 2020 Virtual: Building a Global Supercomputer with Virtual Kubelet
Admiralty: decentralized multi-cluster control plane
https://github.com/admiraltyio/admiralty

16. Virtual Kubelet (virtual-kubelet.io) とは
16
● 仮想 Node が作れるライブラリ
● Providerインターフェース を介して好
きなものをNodeとして
振る舞わせることが可能
● 既存 Providers
○ Alibaba Cloud Elastic Container
Instance
○ Azure Container Instances
○ Huawei Cloud Container
Instance
○ Hashicorp Nomad
○ Admiralty, 他

17. Virtual Kubelet (virtual-kubelet.io) とは
17
● 仮想 Node が作れるライブラリ
● Providerインターフェース を介して好
きなものをNodeとして
振る舞わせることが可能
● 既存 Providers
○ Alibaba Cloud Elastic Container
Instance
○ Azure Container Instances
○ Huawei Cloud Container
Instance
○ Hashicorp Nomad
○ Admiralty, 他
AdmiraltyではFederation先の
クラスタ毎にvirtual-kubeletが
起動する

18. 18
Admiraltyの
動作概要

19. Admiralty の 動作概要
19
サンプルシナリオ
- “CD” クラスタでJobを作成すると
- “US”, “EU” 実際で実行される
admiralty.io/docs

20. Admiralty の 動作概要
20
① target cluster 毎に
virtual kubelet が起動して
仮想Nodeが出来る
admiralty.io/docs

21. Admiralty の 動作概要
21
② pod に multi cluster annotation
付けるとwebhookでproxy podに変換
されて(注: CRDではない)
admiralty.io/docs
③ virtual node に bindされる

22. Admiralty の 動作概要
22
③ target cluster 側に delegate pod
が自動的に作成されて
(注: CRDではない)
admiralty.io/docs
④ 実 Node に bindされる

23. Admiralty Internals
● Virtual Kubelet Implementation
● "Look-Ahead" multi-cluster scheduling
23

24. 24
Virtual Kubelet Implementation

25. AdmiraltyにおけるVirtual Kubeletの実装
KubeCon + CloudNativeCon North America 2020 Virtual: Building a Global Supercomputer with Virtual Kubelet
Virtual Kubeletの責務 Admiraltyでの実装

26. Admiralty で実現可能な Cluster Topology
26admiralty.io/docs

27. namespace毎に柔軟なFederation Topologyが張れる
Target C
Target B
Cluster B
Target A
Cluster C
Target A
Target B

28. 28
“Look-Ahead”
multi-cluster scheduling

29. Kubernetes Scheduling Framework のおさらい
29Scheduling Framework | Kubernetes
Schedule可能な
Node(複数)に絞る
一つのNodeに決める
(最高Scoreを決める)
各podに対する
Binding Cycleは並行に
動作する
pod一個ずつ直列に実行

30. Admiralty “Look-Ahead”
multi-cluster scheduling の登場人物
30admiralty.io/docs
PodStatusを転送する &
Source Clusterへ付与する権限抑制
ために導入されたCRD
(Source側はPodShaperonしか更新しない)
Source/Target Clusterにそれぞれ
役割の違うschedulerがいる
Source/Target Clusterにそれぞれ
役割の違うschedulerがいる

31. Admiralty “Look-Ahead” multi-cluster scheduling
31admiralty.io/docs
①
②
③
④
⑤

32. Admiralty “Look-Ahead” multi-cluster scheduling
32admiralty.io/docs
① Source Pod から Proxy Pod に変換
● ユーザが multicluster.admiralty.io/elect="" annotation 付き
のPodを作る
● Mutating Webhook が spec.schedulerName 等を書き換える
(Proxy Pod と呼ばれる)
①

33. Admiralty “Look-Ahead” multi-cluster scheduling
33admiralty.io/docs
② Filter: Schedule 可能な Target Cluster Node (virtual node) を探す
● Proxy Scheduler の Filter phase で Target Cluster上に PodShaperon を作成
● PodShaperon controller が Pod を作る (Candidate Podと呼ぶ)
● Candidate Scheduler の Filter & Score phase が実際に行われ
● Schedule先Nodeが決まったら、PodShaperonに Reserved とannotate
● Candidate Pod は Candidate Scheduler の PreBind phaseで Bind を待機
● Source側のFilter は Candidate Pod が Reserved になったのを観測したら成功
②

34. Admiralty “Look-Ahead” multi-cluster scheduling
admiralty.io/docs
③ Score: Proxy Pod の Schedule先を決定する
● Proxy Scheduler の Score phaseを経て Bind 先が Target Cluster に決まったら
● Proxy Scheduler の Reserve phase で Candidate Pod に Allow とannotateする
(Allow された Candidate Pod は Delegate Pod と呼ばれる)
④ Bind: Proxy Pod を Bind する
● Candidate Scheduler は PreBind phase を抜けて実際のNodeにBind
● Proxy Scheduler は PreBind で待機して Delegate Pod が Scheduled になったら
● Target Cluster(virtual node) に Bind処理
③
④

35. Admiralty “Look-Ahead” multi-cluster scheduling
35admiralty.io/docs
⑤ 余分なCandidate Pod を Clean Up
● Proxy Scheduler の PostBind phase で
● Bind されなかった Target Cluster上の Candidate Pod を消す
○ Bind された Target Cluster には Delegate Pod が残り
● Source Cluster上の Target Cluster Node (Virtual Kubelet) が Proxy Pod Statusを
更新し続ける
⑤

36. Admiralty “Look-Ahead” multi-cluster scheduling
36admiralty.io/docs
①
②
③
④
⑤

37. Admiralty は商用で色々な機能を提供している
● Multi-Cluster Ingress / Global Server Load Balancing (GSLB)
● Cluster Registry
● Cluster Identity Federation
● kubectl Single Sign-On (SSO)
● Tunnels for private clusters
● Centralized kubernetes audit logs
● etc.
37admiralty.io/docs

38. 感想: 現時点ではまだまだ課題は多い印象
● Data Locality 問題
○ 機械学習だとデータ規模が大きいのでTarget ClusterからSource Clusterに
アクセスするのは現実的でない場合が多い
● Target Cluster 依存の設定が書けない (admiraltyio/admiralty#96)
○ Node Selector, Resource要求を変えたい
○ Target Cluster依存のストレージのエンドポイントを指定したい、等
● Persistent Volumeは扱えなさそう(未検証)
● 既存のCustom Scheduler Pluginとの相互運用性が低い
○ Admiralty以外のScheduler Pluginとの合成は非常に難しい(documentに明記あり)
● 不必要な Preemption が多発する (admiraltyio/admiralty#97)
○ Pod Preemption は Scheduling Cycle で発生するので
○ Candidate Pod を作ると Preemption は発生する可能性が常にある
(Candidate Podは最終的にBindされないかもしれない)
38

39. Kubernetes Federation (kubefed) との現時点での違い
39
kubefed (v0.6.0) Admiralty (v0.13.2)
トポロジ
Host Cluster/Member Cluster
(ツリーのみ)
Flexible/Multiplex
(Target CRDでnamespace毎に設定可)
フォーカス
複数クラスタを効率的に管理
(CRDでresource propagationを管理)
Podを透過的に遠隔クラスタで起動
Network/
DNS
Multi-Cluster Service DNS
X
(一部商用版でサポートあり)
スタイル Centralized / Aggregated Decentralized / Federated
Admiraltyのほうが
Jobクラスタに向いてそう

40. まとめ
● UCSD & Admiralty の事例は Federated Scheduling の実現例として
興味深かった(事例的にもアーキテクチャ的にも)
● 実用に向けてはまだまだ課題は多く今後の発展に期待
● PFNでも継続的にWatchして行きたい
(使えそうなら積極的にContributeしたい)
40

41. 41