写点什么

深入理解 nvidia-docker 2.0

  • 2019-11-19
  • 本文字数:1714 字

    阅读完需:约 6 分钟

深入理解 nvidia-docker 2.0

上篇推送我们介绍了 nvidia-docker 2.0 在我司大规模 Kubernetes 集群上的实践,本篇文章就将介绍相较于旧版本,nvidia-docker 2.0 的设计优势及其实现机制,希望能对大家有所帮助。本文首发于 OpsDev.cn,转载已获取作者授权。


NVIDIA 于 2016 年开始设计 NVIDIA-Docker 已便于容器使用 NVIDIA GPUs。 第一代 nvidia-docker1.0 实现了对 docker client 的封装,并在容器启动时,将必要的 GPU device 和 libraries 挂载到容器中。

1 nvidia-docker 存在的问题

但是这种设计的方式高度的与 docker 运行时耦合,缺乏灵活性。存在的缺陷具体如下:


  • 设计高度与 docker 耦合,不支持其它的容器运行时。如: LXC, CRI-O 及未来可能会增加的容器运行时。

  • 不能更好的利用 docker 生态的其它工具。如: docker compose。

  • 不能将 GPU 作为调度系统的一种资源来进行灵活的调度。

  • 完善容器运行时对 GPU 的支持。如: 自动的获取用户层面的 NVIDIA Driver libraries, NVIDIA kernel modules, device ordering 等。


基于上面描述的这些弊端,NVIDIA 开始了对下一代容器运行时的设计: nvidia-docker2.0。

2 nvidia-docker 2.0 的实现机制

基础知识

先简单介绍下 nvidia-docker 2.0, nvidia-container-runtime,libnvidia-container 以及 runc 直接的关系。


实现机制

它们之间的关系可以通过下面这张图关联起来:


上面已经介绍了各个组件的作用以及它们之间的关系,接下来详细的描述下这张图:


正常创建一个容器的流程

docker --> dockerd --> docker-containerd-shm -->runc --> container-process
复制代码


docker 客户端将创建容器的请求发送给 dockerd, 当 dockerd 收到请求任务之后将请求发送给 docker-containerd-shm


(其实就是 containerd)。


前面没有介绍到 containerd。这里简单的介绍下,containerd,它主要负责的工作是:


  • 管理容器的生命周期(从容器的创建到销毁)

  • 拉取/推送容器镜像

  • 存储管理(管理镜像及容器数据的存储)

  • 调用 runc 运行容器

  • 管理容器的网络接口及网络


containerd 的定位是:


containerd 被设计成嵌入到一个大系统中,而不是给开发人员和终端的设备使用。


关于 containerd 的详细说明,请查看 containerd (https://github.com/containerd/containerd)。


当 containerd 接收到请求之后,做好相关的准备工作,会去调用 runc,而 runc 基于 OCI 文件对容器进行创建。这是容器创建的整体流程。

创建一个使用 GPU 容器的流程

docker--> dockerd --> docker-containerd-shim-->nvidia-container-runtime -- > container-process
复制代码


基本流程和普通不使用 GPU 的容器差不多,只是把 docker 默认的运行时替换成了 NVIDIA 自家的 nvidia-container-runtime。 这样当 nvidia-container-runtime 创建容器时,先执行 nvidia-container-runtime-hook 这个 hook 去检查容器是否需要使用 GPU(通过环境变量 NVIDIA_VISIBLE_DEVICES 来判断)。如果需要则调用 libnvidia-container 来暴露 GPU 给容器使用。否则则走默认的 runc 逻辑。

3 总结

说到这里 nvidia-docker2.0 的大体机制基本就通了。但是涉及到的 nvidia-container-runtime, libnvidia-container, containerd,runc 这些项目, 这本篇文章里面就不一一介绍了。


本文转载自公众号 360 云计算(ID:hulktalk)。


原文链接:


https://mp.weixin.qq.com/s/UKwbNKlEYLq_s2tbx-ZV0g


2019-11-19 23:581539

评论

发布
暂无评论
发现更多内容

什么是死锁?如何解决死锁?

奈学教育

什么是死锁?如何解决死锁?

古月木易

死锁

数据中台建设方法论

数据社

大数据 数据中台

微服务

石刻掌纹

35岁腾讯员工被裁员感叹:北京一套房,存款700多万,失业好焦虑

程序员生活志

程序员

凉了!张三同学没答好「进程间通信」,被面试官挂了....

小林coding

操作系统 计算机基础 进程

架构师训练营 week10 homework

Nick

关于微服务架构的思考和认知

任小龙

解决 WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED

邵俊达

Linux SSH

week10 学习总结

任小龙

django-admin和manage.py用法

BigYoung

Python django django-admin manage.py

微服务架构的思考

Season

Flink 支持的重启策略有哪些

奈学教育

flink

微服务和DDD总结

周冬辉

微服务 DDD

Django如何编写自定义manage.py 命令

BigYoung

Python django manage.py

第十周作业

方堃

聊聊数据库

数据社

数据库 大数据

CDH部署指南

数据社

大数据 CDH

Dubbo微服务框架请求流程

GalaxyCreater

架构

Flink 支持的重启策略有哪些

古月木易

flink

一文了解greenplum

数据社

数据库 greenplum MPP

数据库的那些事

数据社

数据库 大数据

报警不响,黄金万两的“稳定性成熟度”干货

滴滴普惠出行

一周信创舆情观察(8.3~8.9)

统小信uos

Jira 和 Confluence 企业最佳部署方式

Atlassian

项目管理 敏捷开发 Atlassian Jira

anyRTC 4.0 以心铸造,以梦相承

anyRTC开发者

anyRTC 4.0 官网升级

Kubernetes 网络通讯模型解析

ninetyhe

只加两行代码,为什么用了整整两天时间?

程序员生活志

编程 bug

架构师训练营 week10 summary

Nick

华章科技好书5折优惠,满99再减10元

华章IT

Python AI 数字化转型 Java 25 周年 计算机科学丛书

架构师训练营第十周作业

一剑

深入理解 nvidia-docker 2.0_文化 & 方法_王希刚_InfoQ精选文章