Download to read offline
More Related Content
Infrakitの話とk8s+GPUの話
- 1.
- 2.
- 3.
- 4.
- 5. Infrakit? • One ofmoby project • Toolkit for Cluster infrastructure orchestration
- 6.
- 7. Infrakit Architecture Default Group 2 AWSEC2 GCP GCE Docker Swarm Kubernetes Instance FlavorGroup RPC RPC API Group : Default Instance : AWS Flavor : Docker Swarm master 2 worker 4
- 8. Infrakit Architecture Default Group 2 AWSEC2 GCP GCE Docker Swarm Kubernetes Instance FlavorGroup Group : Default Instance : AWS Flavor : Docker Swarm master 2 worker 4
- 9. Infrakit Architecture Default Group 2 AWSEC2 GCP GCE Docker Swarm Kubernetes Instance FlavorGroup RPC RPC Group : Default Instance : AWS Flavor : Docker Swarm master 2 worker 4 そんなものはない！ いまインスタンス どんな感じ？
- 10. Infrakit Architecture Default Group 2 AWSEC2 GCP GCE Docker Swarm Kubernetes Instance FlavorGroup RPC RPC API Group : Default Instance : AWS Flavor : Docker Swarm master 2 worker 4 Docker swarm, 2マスタ 4ワーカでよろしく
- 11. Infrakit Architecture Default Group 2 AWSEC2 GCP GCE Docker Swarm Kubernetes Instance FlavorGroup RPC RPC API Group : Default Instance : AWS Flavor : Docker Swarm master 2 worker 4
- 12. Infrakit Architecture Default Group 2 AWSEC2 GCP GCE Docker Swarm Kubernetes Instance FlavorGroup Group : Default Instance : AWS Flavor : Docker Swarm master 2 worker 4
- 13. Infrakit Architecture Default Group 2 AWSEC2 GCP GCE Docker Swarm Kubernetes Instance FlavorGroup RPC RPC API Group : Default Instance : AWS Flavor : Docker Swarm master 2 worker 4 どんな感じ？
- 14. Infrakit Architecture Default Group 2 AWSEC2 GCP GCE Docker Swarm Kubernetes Instance FlavorGroup RPC RPC API Group : Default Instance : AWS Flavor : Docker Swarm master 2 worker 4 あかんやん！ 2マスタ 3ワーカ
- 15. Infrakit Architecture Default Group 2 AWSEC2 GCP GCE Docker Swarm Kubernetes Instance FlavorGroup RPC RPC API Group : Default Instance : AWS Flavor : Docker Swarm master 2 worker 4 1ワーカ追加ね
- 16. Infrakitの特徴 • プラグインモデル • Infrakitの設定（必要なプラグイン、その設定）とクラスタの期 待状態をファイルに記述して再現可能にする •プラグインを変えれば簡単に別のクラウドに移行することがで きるようにしたい • 将来的にはLBの設定とかも管理できるようになりたい
- 17.
- 18. linuxkit? • ディストリビューション・アズ・ア・コード • dockerホストとなるサーバに必要なミドルウェア、設定を記述 できる •isoファイルやAWS, GCPなどのクラウドのイメージ、VMWareの VMイメージを作れる
- 19.
- 20.
- 21.
- 22. kubernetes対応とは？ • Linuxkit: kubernetesノードとして必要なコンポーネントを入れら れるようになった •Infrakit: kubernetesクラスタを構築、管理できるようにした ということ
- 23.
- 24.
- 25. モチベーション • 分散学習タスクの場合にいちいちノードにログインしたくない • 複数のタスクを並列で走らせたい •コンテナ単位で管理できればデプロイも楽
- 26. なぜkubernetesなのか • コンテナオーケストレータの覇者であることがほぼ確定 • スケジューラなどが拡張しやすい •アルファ版だがGPUサポートが有る 秀逸な資料： GPU Container as a Serviceを実現するための最新OSS徹底比較 https://www.slideshare.net/td-nttcom/gpu-container-as-a-service-oss
- 27.
- 28.
- 29. spec: template: metadata: labels: app: mxd-worker1 spec: volumes: - name:nvidialib hostPath: path: /usr/lib/nvidia-375 containers: - name: mxd-worker1 image: mxnet/python:gpu volumeMounts: - mountPath: /usr/local/nvidia name: nvidialib readOnly: true resources: requests: alpha.kubernetes.io/nvidia-gpu: 4 limits: alpha.kubernetes.io/nvidia-gpu: 4 これで大丈夫 ドキュメントにもそう書いてある
- 32.
- 33.
- 34.
- 35. nvidia-container-runtime • nvidiaが最近始めたプロジェクト • OCIランタイムスペックに準拠したGPUを利用するためのコンテ ナランタイム •ホスト側のCUDAのバージョンを自動的に認識してなんとかして くれる • 最新版のdockerにも対応してる 問題点 何故かdockerのデフォルトランタイムに設定してもk8sからだと 無視された
- 36.
- 37. 動くけど。。 • 不安定 • 怖すぎる •nv-runtimeが環境変数でGPUの数の管理などを行うのでk8s側で 制御できなくなる
- 38. nv-docker, nv-runtime, k8sの関係 k8sはdocker,cri-containerdに対して deviceオプションでGPUデバイスを、-vでライブラリを入れる デバイスオプション このpodにはGPU 2つ ライブラリのマウントはユーザの責任
- 39. nv-docker, nv-runtime, k8sの関係 nv-dockerも一緒 デバイスオプション このコンテナにはGPU2つ ライブラリのマウントも自動
- 40. nv-docker, nv-runtime, k8sの関係 nv-runtimeは違う 環境変数でGPU数指定このコンテナにはGPU 2つ デバイス・ライブラリのマウント
- 41.
- 42. 結論 • しばらくはk8s+docker1.13でnvdockerが作るディレクトリを使っ ていこう • もしくは丁寧に必要なライブラリの場所を洗い出そう •ノードごとのバージョン問題はノードにラベルを貼るしか（今 のところ）解がない • ちなみにk8sのGPU管理は雑（/devをスキャンしてnvidiaデバイ スをマウントしてDBに登録するだけ）
Editor's Notes
- #8 This is little more details about implementation. Each of plug-ins are running as go process and Infrakit discovers them through Unix socket. And plug-ins communicate each other with rpc.
- #9 Now, I will talk about the flow of using Infrakit. First, you send a configuration of cluster to Infrakit and it will be sent to group plug-in. In this example, Using default group plug-in, aws instance plug-in and docker swarm flavor plug-in. And you define the desired state of your cluster. Now, it is 2 masters and 4 workers for docker swarm.
- #10 Then the group plugin check the state of your cluster through flavor and instance plug-in. now, there are no instance.
- #11 The group plugin send the required number of instances to instance and flaver plug-ins with rpc. It need to deploy 2 masters and 4 workers now.
- #12 And then, Instance plug-in gather information that will be needed to deploy instance from flavor plug-in and deploy instances by cloud provider’s API.
- #13 Now, some failure occurred in your cluster. One of your worker died unexpectedly.
- #14 Group plug-in has been polling the state of your cluster. How many instances are running? Are all nodes healthy?
- #15 So the Group plug-in can notice a node has gone down because the instance plug-in report number of only healthy nodes. In this case, instance plugin reports 2 master and only 3 workers are running.
- #16 Then, the group plug-in will request to instance and flavor plug-ins to maintain your desired state. This is the basic behavior of provisioning and auto-healing of Infrakit.