QCon 演讲火热征集中,快来分享技术实践与洞见! 了解详情
写点什么

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

评论

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

观测云产品更新|新增查看器显示列多种快捷操作;新增 Pipeline 一键获取样本测试数据;新增场景自定义查看器文本分析模式等

观测云

小白 0-1 学习 app 开发,从配置到 helloword

YonBuilder低代码开发平台

跨平台 安卓 低代码开发 多端开发

wallys/DR8072V01/IPQ8072A networking SBC supports dual 10GbE, WiFi 6

wallys-wifi6

东方甄选品控翻车,如何通过智能协同的供应链建设建开启可持续商业模式?

数商云

数字化转型 供应链 企业数字化

Golang生成OpenAPI接口文档

百家饭隐私计算平台创业者

Go OpenAPI

建木持续集成平台v2.5.1发布-全面拥抱云原生架构

Jianmu

云原生 k8s 持续集成 CI/CD

开源代码难阅读?几位研发的“妙招”帮你解决

TDengine

数据库 tdengine 开源

搭建帮助中心,推动SaaS企业发展

Baklib

SaaS 客户服务 帮助中心 文档管理

企业自己如何快速开发一个简单实用的CRM客户管理系统?

优秀

CRM系统

推理实践丨如何使用MindStudio进行Pytorch模型离线推理

华为云开发者联盟

人工智能

让智慧物联赋能高效生产, AIRIOT助力数字化油田转型升级

AIRIOT

低代码 物联网 低代码,项目开发

SpringBootAdmin 2.5.5 发布,支持在线重启服务

冉然学Java

编程 springboot 构架 Java’

新书上市 | 20年行业实践,一线工程师的必读之作

图灵教育

软件设计

中文拼写纠错:怎样改善模型对 multi-typo 的纠正效果?

澜舟孟子开源社区

人工智能 自然语言处理 nlp 文本生成 文本纠错

GQM 概述:构建研发效能度量体系的根本方法

思码逸研发效能

研发效能 创新方法 效能度量

让预训练语言模型读懂数字:超对称技术发布 10 亿参数 BigBang Transformer [乾元]金融大规模预训练语言模型

亚马逊云科技 (Amazon Web Services)

架构 数据 模型

2022 开放原子全球开源峰会 OpenAnolis 分论坛携干货来袭!

kk-OSC

centos 开源 龙蜥操作系统 开放原子全球开源峰会 OpenAnolis

编写Dockerfile,让你的程序一键部署

技术小生

Dockerfile 7月月更

RadonDB MySQL Kubernetes 2.2.0 发布!

RadonDB

MySQL Kubernetes 云原生 容器化 RadonDB

阿里云架构师唐风:生命科学产业现状及发展趋势分享

阿里云弹性计算

高性能计算 生命科学 AI制药

升哲科技入选《中国企业家》2022年度“新锐100”企业

SENSORO

云原生时代,金融企业如何完成全栈信创改造?

MIAOYUN

云原生 信创 国产化 金融信创 全栈改造

oa办公系统都有哪家?

优秀

OA oa办公系统

构建工业软件开源工具链,2022 开放原子全球开源峰会开源工业软件论坛即将开幕

kk-OSC

开源 开放原子全球开源峰会 开源工业软件

清源(CleanSource) SCA推出容器镜像扫描功能

安势信息

容器 安全 SCA 容器镜像 容器镜像Docker

一体化实时HTAP数据库StoneDB,如何替换MySQL并实现近百倍分析性能的提升

StoneDB

云原生 #数据库 HTAP 大数据 开源 #开源

TDengine 如何进行数据建模?

TDengine

数据库 tdengine 开源

【7.1-7.8】写作社区精彩技术博文回顾

InfoQ写作社区官方

优质创作周报

内部排序——交换排序

乔乔

7月月更

工作中养成的工作习惯与给老板的汇报

松子(李博源)

大数据 个人成长 高效 高效率 工作总结

共建开源人才生态,2022 开放原子全球开源峰会聚焦 “产学研用”

kk-OSC

开源 数字化 产学研用 开放原子全球开源峰会

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