写点什么

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

评论

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

一图看懂CodeArts Deploy 5大特性,带你玩转部署服务

华为云开发者联盟

云计算 后端 华为云 华为云开发者联盟 企业号 5 月 PK 榜

中移链合约常用开发介绍(四)工程树目录

BSN研习社

不是单例的单例——巧用ClassLoader

PPPHUANG

单例模式 ClassLoader ContextClassLoader Java web

Y组合子的一个启发式推导

canonical

函数式编程 函数式 Lambda演算 Y组合子 不动点

宝兰德应用服务器软件与华为云GaussDB完成兼容互认证

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 5 月 PK 榜

如何用 ModelScope 实现 “AI 换脸” 视频

北桥苏

Python ModelScope

led大屏幕存在的问题

Dylan

LED显示屏 全彩LED显示屏 led显示屏厂家

问鼎CodeXGLUE榜单,华为云UniXcoder-VESO-v1算法取得突破

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 企业号 5 月 PK 榜

《银河护卫队3》观后感:AI、人生

无人之路

AI 电影

支持GraalVM原生编译的开源低代码平台:Nop Platform

canonical

开源 低代码 GraalVM Quarkus 低代码平台

SpringBoot整合MybatisPlus基础教程

(-0 , +0)

springboot Mybatis Plus

这份阿里逆天的Redis手册,于内卷中首次亮相了

Java你猿哥

Java redis 面试 Redis 核心技术与实战 redis 底层原理

如果重写SpringBoot,我们会做哪些不同的选择?

canonical

开源 低代码 架构设计 springboot spring ioc

springboot整合redis基础示例

(-0 , +0)

采用Excel作为设计器的开源中国式报表引擎:NopReport

canonical

开源 低代码 报表 BI 报表 中国式报表

从可逆计算看开源低代码平台Skyve的设计

canonical

开源 低代码 架构设计 低代码平台 扩展机制

如何在不修改基础产品源码的情况下实现定制化开发

canonical

开源 低代码 定制化 迭代增量开发 可扩展性

火山引擎DataTester:A/B实验平台数据集成技术分享

字节跳动数据平台

从张量积看低代码平台的设计

canonical

开源 低代码 架构设计 低代码平台 领域模型

性能优化多重要?凭借华为791页Mysql金字塔性能调优手册,进阿里

Java MySQL 性能优化 性能调优

分库分表的 21 条法则,hold 住!

程序员小富

分库分表 springboot 分库表

再见!Fastjson!

Java你猿哥

Java ssm Fastjson

为什么说百度AMIS框架是一个优秀的设计

canonical

开源 前端架构 低代码 低代码平台 百度AMIS

关于 ModelScope 的视频 “AI 换脸” 优化方案

北桥苏

Python ModelScope

eBPF动手实践系列二:构建基于纯C语言的eBPF项目

阿里云大数据AI技术

运维 C语言 ebpf 企业号 5 月 PK 榜

分类树,我从2s优化到0.1s

Java你猿哥

Java 算法 ssm 分类树

可逆计算:下一代软件构造理论

canonical

低代码 软件架构 函数式编程 领域驱动模型DDD 中台架构 低代码平台

系统学Java,看这篇Java综合笔记万字总结就够了!纯干货分享

Java你猿哥

Java spring 面试 ssm 多线程与高并发

一把王者的时间,带你吃透Java面试八股文(2023最新整理)

Java你猿哥

Java 面试 微服务 Spring Boot mybatis

XDSL:通用的领域特定语言设计

canonical

开源 低代码 dsl 领域特定语言 领域语言工作台

Paxos的魔法学研究报告

canonical

paxos协议 共识算法 分布式, 分布式算法 深入理解分布式共识算法

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