写点什么

深入理解 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:581471

评论

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

建设 TiDB 自动化平台:转转 DBA 团队实践

PingCAP

数据库 自动化 TiDB

React源码分析3-render阶段(穿插scheduler和reconciler)

goClient1992

React

React源码解读之更新的创建

flyzz177

React

万亿级对象存储的元数据系统架构设计和实践

百度开发者中心

对象存储 文件存储 百度沧海

Golang 编程“珠玑”

MatrixOrigin

golang 分布式数据库 编程语言 MatrixOrigin MatrixOne

解读Teradata结束中国直营背后的原因!国产数据库能填补空缺吗?

雨果

数据库管理工具 国产数据库 teradata SQL工具

react hook 源码完全解读

flyzz177

React

用javascript分类刷leetcode15.链表(图文视频讲解)

js2030code

JavaScript LeetCode

Unittest接口测试生成报告和日志方法

日志 单元测试 自动化测试 unittest 测试报告

美团前端必会vue面试题合集

bb_xiaxia1998

Vue

React源码解读之任务调度

flyzz177

React

JavaScript刷LeetCode拿offer-树的遍历

js2030code

JavaScript LeetCode

LR性能测试常见问题及处理方法(二)

性能测试 问题排查 LoadRunner

目前兰州市等保测评机构有几家?有新增的吗?

行云管家

等保 等级保护 等保测评 兰州

unittest中使用ddt后生成的测试报告名称如何修改?(如test_api_0修改成test_api_0_titile)

单元测试 自动化测试 unittest 参数化 ddt

写过vue自定义指令吗,原理是什么?.m

bb_xiaxia1998

Vue

前端手写面试题总结

helloworld1024fd

JavaScript

构建云边端一体的分布式云架构,软硬结合驱动边缘计算创新场景

百度开发者中心

云原生 边缘计算 #百度智能云#

可视化分析能力MAX,瓴羊Quick BI带来全新数据分析体验

对不起该用户已成仙‖

自己手写一个redux

helloworld1024fd

JavaScript

LR性能测试常见问题及处理方法(一)

性能测试 问题排查 LoadRunner

SQL工具性能实测:居然比Navicat还快,数百万行数据导出仅51秒

雨果

sql 数据库管理工具 Web SQL sql studio

腾讯前端一面经典手写面试题合集

helloworld1024fd

JavaScript

React源码分析4-深度理解diff算法

goClient1992

React

vivo x TiDB丨解决云服务海量数据挑战

PingCAP

TiDB

谈谈Linux内核的噪声

统信软件

Linux 内核

关于这个“微信提现”的问题,太炸裂了,以至于我写了段代码来验证!

why技术

Java 算法

React源码分析2-深入理解fiber

goClient1992

React

假如问:你是怎样优化Vue项目的,该怎么回答

bb_xiaxia1998

Vue

堡垒机行业标杆产品是哪家呢?有哪些功能?

行云管家

网络安全 信息安全 等保 堡垒机

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