写点什么

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

评论

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

证书管理:从手工到平台化

vivo互联网技术

运维自动化 运维开发 证书管理

南通市属于几线城市?本地有正规等保测评机构吗?

行云管家

等级保护 等保测评 南通

你说搞开发的很累,那做什么工作不累?

树上有只程序猿

实现淘宝母婴订单实时查询和可视化|Flink-Learning实战营

Apache Flink

大数据 flink

从零开始初识机器学习 | 京东云技术团队

京东科技开发者

人工智能 机器学习 企业号 6 月 PK 榜

TICDC 数据同步至 MySQL初体验

TiDB 社区干货传送门

迁移

看这个视频,4万人学会云上部署 Stable Diffusion

Serverless Devs

云计算 Serverless 函数计算FC

Flink CDC 2.4 正式发布,新增 Vitess 数据源,PostgreSQL 和 SQL Server CDC 连接器支持增量快照,升级 Debezium 版本

Apache Flink

flink

记一次Native memory leak排查过程 | 京东云技术团队

京东科技开发者

native 企业号 6 月 PK 榜 memory leak

TiDB 升级利器(参数对比)——TiDBA

TiDB 社区干货传送门

7.x 实践

TiDB 多租户方案和原理

TiDB 社区干货传送门

TiDB 底层架构 新版本/特性解读 7.x 实践

LED租赁屏市场

Dylan

活动 广告 方案 设备 LED显示屏

程序员搞开发的时候,心态真的不稳

伤感汤姆布利柏

如何用极狐GitLab 为 iOS App 创建自动化CI/CD?详细教程来了

极狐GitLab

ios DevOps gitlab 自动化 CI/CD

TIDB v7.1 reource control资源管控特性体验贴

TiDB 社区干货传送门

版本测评 7.x 实践

资源池化:多租户与数据库整合解决方案

TiDB 社区干货传送门

新版本/特性解读 数据库架构设计

Gartner®DevOps 平台魔力象限出炉,GitLab 获评「领导者」!

极狐GitLab

gitlab 安全 开放平台 开源贡献者 领导者象限

关于 3.0 和 2.0 的数据文件差异以及性能优化思路

爱倒腾的程序员

linux自动化运维工具用哪款好?理由是什么?

行云管家

Linux IT运维 自动化运维

边缘云特点、应用实践和发展趋势浅析

天翼云开发者社区

边缘云

发送Tidb告警信息到企业微信群实践

TiDB 社区干货传送门

监控

基于群组实现从 Azure AD 到极狐GitLab 的单点登录

极狐GitLab

统一身份认证 IdP 单点登录 用户同步 配置群组同步

MySQL中字符串查询效率大比拼

不在线第一只蜗牛

数据库 sql

零样本视频生成无压力,基于飞桨框架实现Text2Video-Zero核心代码及依赖库

飞桨PaddlePaddle

人工智能 百度 paddle 飞桨 百度飞桨

高考成绩都出来了,你的秒杀系统如何了?

冰河

并发编程 多线程 高并发 协程 秒杀系统

微服务之道:8个原则,打造高效的微服务体系

不在线第一只蜗牛

微服务 微服务架构

如何使用 Flink SQL 探索 GitHub 数据集|Flink-Learning 实战营

Apache Flink

大数据 flink 实时计算

表格检测识别技术面临的挑战和发展趋势

合合技术团队

人工智能 表格识别 表格检测

【TiDB v7.1.0】资源管控调研及评测

TiDB 社区干货传送门

7.x 实践

WEB系统安全之开源软件风险使用评估

天翼云开发者社区

开源 Web

数字先锋|云上医院长什么样?宁夏固原中医医院带你一探究竟!

天翼云开发者社区

云计算

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