写点什么

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

评论

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

在AI技术快速实现创意的时代,挖掘数学学习新需求成为关键挑战

qife122

需求分析 数学资源

第七届智能控制、测量与信号处理国际学术会议 (ICMSP 2025)

搞科研的小刘

智能控制

20年装备制造业MES实施经验分享

万界星空科技

制造业 mes 万界星空科技mes 软件实施 MES实施

LED广告牌安装服务,让生意“亮”起来!

Dylan

广告 LED LED display LED显示屏 LED屏幕

Paytium 3.0.13 WordPress插件存储型XSS漏洞分析

qife122

网络安全 WordPress插件

看完鸿蒙6心痒痒?记得在鸿蒙有礼把会员年卡抽了再说

最新动态

进入职场第三课——立足

老李说技术

职场 职场发展 职场妙招

第六届机械工程、智能制造与自动化技术国际学术会议 (MEMAT 2025)

搞科研的小刘

工程机械

得物TiDB升级实践

得物技术

数据库 TiDB 数据库性能优化

使用 Java、Spring Boot 和 Spring AI 开发符合 A2A 标准的 AI 智能体

码界行者

AI Agent Spring AI

配电 低压电工经验总结(18)

万里无云万里天

工业 工厂运维

第十届能源系统、电气与电力国际学术会议 (ESEP 2025)

搞科研的小刘

能源

「腾讯云NoSQL」技术之Redis篇:精准围剿rehash时延毛刺实践方案揭秘

腾讯云数据库

数据库 nosql redis 腾讯云数据库 腾讯云NoSQL

下一代金融安全关键技术:融合开源数据与网络数据的智能处理能力

IAN李车

金融科技 信息安全 数据合规 金融安全 金融合规

[大厂实践] 少即是多:Zendesk 长时间作业执行优化

俞凡

架构

软件未来预测的准确性与代码简洁之道

qife122

软件设计 未来预测

Agentic AI基础设施实践经验系列(六):Agent质量评估

亚马逊云科技 (Amazon Web Services)

人工智能

探析 CodexField:如何搭建自增长的内容资产生态?

股市老人

双十一隐藏福利:鸿蒙有礼让我实现追剧自由

最新动态

一文读懂CodexField 自增长内容资产生态的核心逻辑

BlockChain先知

CodexField 如何构建自增长的内容资产生态?

石头财经

漏洞赏金实战:我是如何轻松获得2500美元奖金的

qife122

漏洞挖掘 逻辑漏洞

久其接口新特性——解决报表连续性、数据项连续性

inBuilder低代码平台

GS Cloud 久其接口 结构化匹配 多版本报表 参数迁移

工业管理 项目管理经验总结(29)

万里无云万里天

项目管理 工业 工厂运维

时序数据库 IoTDB 集成 MyBatisPlus,告别复杂编码,简化时序数据 ORM 开发

Apache IoTDB

微服务已死?别再盲目跟风微服务!这3种情况下单体架构更适合你。

六边形架构

微服务 系统架构 架构设计 架构师 单体架构

2025年医学图像处理与识别国际会议(IPOR 2025)

搞科研的小刘

图像处理

大数据-149 Apache Druid 实时 OLAP 架构与选型要点

武子康

Java 大数据 分布式 Druid Apache Druid

双十一也别忘了薅羊毛,华为音乐全曲库超高清音频随便听

最新动态

三小时会议,五分钟纪要:一个技术Leader的会议记录救赎之路

HuiZhuDev

效率工具 团队协作 技术管理 会议管理 AI指令

低空经济从“蓝图”迈向“实景”,技术与应用协同成为产业焦点

科技经济

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