Docker 疑難雜癥匯總（一）

這里主要是為了記錄在使用 Docker 的時候遇到的問題及其處理解決方法。

1. Docker 遷移存儲目錄

默認情況系統(tǒng)會將 Docker 容器存放在 /var/lib/docker 目錄下

[問題起因] 今天通過監(jiān)控系統(tǒng)，發(fā)現(xiàn)公司其中一臺服務(wù)器的磁盤快慢，隨即上去看了下，發(fā)現(xiàn) /var/lib/docker 這個目錄特別大。由上述原因，我們都知道，在 /var/lib/docker 中存儲的都是相關(guān)于容器的存儲，所以也不能隨便的將其刪除掉。

那就準備遷移 docker 的存儲目錄吧，或者對 /var 設(shè)備進行擴容來達到相同的目的。更多關(guān)于 dockerd 的詳細參數(shù)，請查看官方文檔。

但是需要注意的一點就是，盡量不要用軟鏈， 因為一些 docker 容器編排系統(tǒng)不支持這樣做，比如我們所熟知的 k8s 就在內(nèi)。

#?發(fā)現(xiàn)容器啟動不了了
ERROR：cannot ?create?temporary?directory!

#?查看系統(tǒng)存儲情況
$?du?-h?--max-depth=1

[解決方法 1] 添加軟鏈接

#?1.停止docker服務(wù)
$?sudo?systemctl?stop?docker

#?2.開始遷移目錄
$?sudo?mv?/var/lib/docker?/data/

#?3.添加軟鏈接
$?sudo?ln?-s?/data/docker?/var/lib/docker

#?4.啟動docker服務(wù)
$?sudo?systemctl?start?docker

[解決方法 2] 改動 docker 配置文件

#?[方式一]?改動docker啟動配置文件
$?sudo?vim?/lib/systemd/system/docker.service
ExecStart=/usr/bin/dockerd?--graph=/data/docker/

#?[方式二]?改動docker啟動配置文件
$?sudo?vim?/etc/docker/daemon.json
{
????"live-restore":?true,
????"graph":?[?"/data/docker/"?]
}

[操作注意事項] 在遷移 docker 目錄的時候注意使用的命令，要么使用 mv 命令直接移動，要么使用 cp 命令復(fù)制文件，但是需要注意同時復(fù)制文件權(quán)限和對應(yīng)屬性，不然在使用的時候可能會存在權(quán)限問題。如果容器中，也是使用 root 用戶，則不會存在該問題，但是也是需要按照正確的操作來遷移目錄。

#?使用mv命令
$?sudo?mv?/var/lib/docker?/data/docker

#?使用cp命令
$?sudo?cp?-arv?/data/docker?/data2/docker

下圖中，就是因為啟動的容器使用的是普通用戶運行進程的，且在運行當中需要使用 /tmp 目錄，結(jié)果提示沒有權(quán)限。在我們導(dǎo)入容器鏡像的時候，其實是會將容器啟動時需要的各個目錄的權(quán)限和屬性都賦予了。如果我們直接是 cp 命令單純復(fù)制文件內(nèi)容的話，就會出現(xiàn)屬性不一致的情況，同時還會有一定的安全問題。

2. Docker 設(shè)備空間不足

Increase Docker container size from default 10GB on rhel7.

[問題起因一] 容器在導(dǎo)入或者啟動的時候，如果提示磁盤空間不足的，那么多半是真的因為物理磁盤空間真的有問題導(dǎo)致的。如下所示，我們可以看到 / 分區(qū)確實滿了。

#?查看物理磁盤空間
$?df?-Th
Filesystem????Size????Used????Avail????Use%????Mounted?on
/dev/vda1??????40G?????40G???????0G????100%????/
tmpfs?????????7.8G???????0?????7.8G??????0%????/dev/shm
/dev/vdb1?????493G????289G?????179G?????62%????/mnt

如果發(fā)現(xiàn)真的是物理磁盤空間滿了的話，就需要查看到底是什么占據(jù)了如此大的空間，導(dǎo)致因為容器沒有空間無法啟動。其中，docker 自帶的命令就是一個很好的能夠幫助我們發(fā)現(xiàn)問題的工具。

#?查看基本信息
#?硬件驅(qū)動使用的是devicemapper，空間池為docker-252
#?磁盤可用容量僅剩16.78MB，可用供我們使用
$?docker?info
Containers:?1
Images:?28
Storage?Driver:?devicemapper
?Pool?Name:?docker-252:1-787932-pool
?Pool?Blocksize:?65.54?kB
?Backing?Filesystem:?extfs
?Data?file:?/dev/loop0
?Metadata?file:?/dev/loop1
?Data?Space?Used:?1.225?GB
?Data?Space?Total:?107.4?GB
?Data?Space?Available:?16.78?MB
?Metadata?Space?Used:?2.073?MB
?Metadata?Space?Total:?2.147?GB

[解決方法] 通過查看信息，我們知道正是因為 docker 可用的磁盤空間不足，所以導(dǎo)致啟動的時候沒有足夠的空間進行加載啟動鏡像。解決的方法也很簡單，第一就是清理無效數(shù)據(jù)文件釋放磁盤空間(清除日志)，第二就是修改 docker 數(shù)據(jù)的存放路徑(大分區(qū))。

#?顯示哪些容器目錄具有最大的日志文件
$?du?-d1?-h?/var/lib/docker/containers?|?sort?-h

#?清除您選擇的容器日志文件的內(nèi)容
$?cat?/dev/null?>?/var/lib/docker/containers/container_id/container_log_name

[問題起因二] 顯然我遇到的不是上一種情況，而是在啟動容器的時候，容器啟動之后不久就顯示是 unhealthy 的狀態(tài)，通過如下日志發(fā)現(xiàn)，原來是復(fù)制配置文件啟動的時候，提示磁盤空間不足。

后面發(fā)現(xiàn)是因為 CentOS7 的系統(tǒng)使用的 docker 容器默認的創(chuàng)建大小就是 10G 而已，然而我們使用的容器卻超過了這個限制，導(dǎo)致無法啟動時提示空間不足。

2019-08-16?11:11:15,816?INFO?spawned:?'app-demo'?with?pid?835
2019-08-16?11:11:16,268?INFO?exited:?app?(exit?status?1;?not?expected)
2019-08-16?11:11:17,270?INFO?gave?up:?app?entered?FATAL?state,?too?many?start?retries?too?quickly
cp:?cannot?create?regular?file?'/etc/supervisor/conf.d/grpc-app-demo.conf':?No?space?left?on?device
cp:?cannot?create?regular?file?'/etc/supervisor/conf.d/grpc-app-demo.conf':?No?space?left?on?device
cp:?cannot?create?regular?file?'/etc/supervisor/conf.d/grpc-app-demo.conf':?No?space?left?on?device
cp:?cannot?create?regular?file?'/etc/supervisor/conf.d/grpc-app-demo.conf':?No?space?left?on?device

[解決方法 1] 改動 docker 啟動配置文件

#?/etc/docker/daemon.json
{
????"live-restore":?true,
????"storage-opt":?[?"dm.basesize=20G"?]
}

[解決方法 2] 改動 systemctl 的 docker 啟動文件

#?1.stop?the?docker?service
$?sudo?systemctl?stop?docker

#?2.rm?exised?container
$?sudo?rm?-rf?/var/lib/docker

#?2.edit?your?docker?service?file
$?sudo?vim?/usr/lib/systemd/system/docker.service

#?3.find?the?execution?line
ExecStart=/usr/bin/dockerd
and?change?it?to:
ExecStart=/usr/bin/dockerd?--storage-opt?dm.basesize=20G

#?4.start?docker?service?again
$?sudo?systemctl?start?docker

#?5.reload?daemon
$?sudo?systemctl?daemon-reload

[問題起因三] 還有一種情況也會讓容器無法啟動，并提示磁盤空間不足，但是使用命令查看發(fā)現(xiàn)并不是因為物理磁盤真的不足導(dǎo)致的。而是，因為對于分區(qū)的 inode 節(jié)點數(shù)滿了導(dǎo)致的。

#?報錯信息
No?space?left?on?device

[解決方法] 因為 ext3 文件系統(tǒng)使用 inode table 存儲 inode 信息，而 xfs 文件系統(tǒng)使用 B+ tree 來進行存儲。考慮到性能問題，默認情況下這個 B+ tree 只會使用前 1TB 空間，當這 1TB 空間被寫滿后，就會導(dǎo)致無法寫入 inode 信息，報磁盤空間不足的錯誤。我們可以在 mount 時，指定 inode64 即可將這個 B+ tree 使用的空間擴展到整個文件系統(tǒng)。

#?查看系統(tǒng)的inode節(jié)點使用情況
$?sudo?df?-i

#?嘗試重新掛載
$?sudo?mount?-o?remount?-o?noatime,nodiratime,inode64,nobarrier?/dev/vda1

[補充知識] 文件儲存在硬盤上，硬盤的最小存儲單位叫做 扇區(qū)(Sector)。每個扇區(qū)儲存 512 字節(jié)(相當于0.5KB)。操作系統(tǒng)讀取硬盤的時候，不會一個個扇區(qū)地讀取，這樣效率太低，而是一次性連續(xù)讀取多個扇區(qū)，即一次性讀取一個塊(block)。這種由多個扇區(qū)組成的塊，是文件存取的最小單位。塊的大小，最常見的是4KB，即連續(xù)八個 sector 組成一個 block 塊。文件數(shù)據(jù)都儲存在塊中，那么很顯然，我們還必須找到一個地方儲存文件的元信息，比如文件的創(chuàng)建者、文件的創(chuàng)建日期、文件的大小等等。這種儲存文件元信息的區(qū)域就叫做索引節(jié)點(inode)。每一個文件都有對應(yīng)的 inode，里面包含了除了文件名以外的所有文件信息。

inode 也會消耗硬盤空間，所以硬盤格式化的時候，操作系統(tǒng)自動將硬盤分成兩個區(qū)域。一個是數(shù)據(jù)區(qū)，存放文件數(shù)據(jù)；另一個是 inode 區(qū)(inode table)，存放 inode 所包含的信息。每個 inode 節(jié)點的大小，一般是 128 字節(jié)或 256 字節(jié)。inode 節(jié)點的總數(shù)，在格式化時就給定，一般是每1KB或每2KB就設(shè)置一個 inode 節(jié)點。

#?每個節(jié)點信息的內(nèi)容
$?stat?check_port_live.sh
??File:?check_port_live.sh
??Size:?225???????????Blocks:?8??????????IO?Block:?4096???regular?file
Device:?822h/2082d????Inode:?99621663????Links:?1
Access:?(0755/-rwxr-xr-x)??Uid:?(?1006/??escape)???Gid:?(?1006/??escape)
Access:?2019-07-29?14:59:59.498076903?+0800
Modify:?2019-07-29?14:59:59.498076903?+0800
Change:?2019-07-29?23:20:27.834866649?+0800
?Birth:?-

#?磁盤的inode使用情況
$?df?-i
Filesystem?????????????????Inodes???IUsed?????IFree?IUse%?Mounted?on
udev?????????????????????16478355?????801??16477554????1%?/dev
tmpfs????????????????????16487639????2521??16485118????1%?/run
/dev/sdc2???????????????244162560?4788436?239374124????2%?/
tmpfs????????????????????16487639???????5??16487634????1%?/dev/shm

3. Docker 缺共享鏈接庫

Docker 命令需要對/tmp 目錄下面有訪問權(quán)限

[問題起因] 給系統(tǒng)安裝完 compose 之后，查看版本的時候，提示缺少一個名為 libz.so.1 的共享鏈接庫。第一反應(yīng)就是，是不是系統(tǒng)少安裝那個軟件包導(dǎo)致的。隨即，搜索了一下，將相關(guān)的依賴包都給安裝了，卻還是提示同樣的問題。

#?提示錯誤信息
$?docker-compose?--version
error?while?loading?shared?libraries:?libz.so.1:?failed?to?map?segment?from?shared?object:?Operation?not?permitted

[解決方法] 后來發(fā)現(xiàn)，是因為系統(tǒng)中 docker 沒有對 /tmp 目錄的訪問權(quán)限導(dǎo)致，需要重新將其掛載一次，就可以解決了。

#?重新掛載
$?sudo?mount?/tmp?-o?remount,exec

4. Docker 容器文件損壞

對 dockerd 的配置有可能會影響到系統(tǒng)穩(wěn)定

[問題起因] 容器文件損壞，經(jīng)常會導(dǎo)致容器無法操作。正常的 docker 命令已經(jīng)無法操控這臺容器了，無法關(guān)閉、重啟、刪除。正巧，前天就需要這個的問題，主要的原因是因為重新對 docker 的默認容器進行了重新的分配限制導(dǎo)致的。

#?操作容器遇到類似的錯誤
b'devicemapper:?Error?running?deviceCreate?(CreateSnapDeviceRaw)?dm_task_run?failed'

[解決方法] 可以通過以下操作將容器刪除/重建。

#?1.關(guān)閉docker
$?sudo?systemctl?stop?docker

#?2.刪除容器文件
$?sudo?rm?-rf?/var/lib/docker/containers

#?3.重新整理容器元數(shù)據(jù)
$?sudo?thin_check?/var/lib/docker/devicemapper/devicemapper/metadata
$?sudo?thin_check?--clear-needs-check-flag?/var/lib/docker/devicemapper/devicemapper/metadata

#?4.重啟docker
$?sudo?systemctl?start?docker

5. Docker 容器優(yōu)雅重啟

不停止服務(wù)器上面運行的容器，重啟 dockerd 服務(wù)是多么好的一件事

[問題起因] 默認情況下，當 Docker 守護程序終止時，它會關(guān)閉正在運行的容器。從 Docker-ce 1.12 開始，可以在配置文件中添加 live-restore 參數(shù)，以便在守護程序變得不可用時容器保持運行。需要注意的是 Windows 平臺暫時還是不支持該參數(shù)的配置。

#?Keep?containers?alive?during?daemon?downtime
$?sudo?vim?/etc/docker/daemon.yaml
{
??"live-restore":?true
}

#?在守護進程停機期間保持容器存活
$?sudo?dockerd?--live-restore

#?只能使用reload重載
#?相當于發(fā)送SIGHUP信號量給dockerd守護進程
$?sudo?systemctl?reload?docker

#?但是對應(yīng)網(wǎng)絡(luò)的設(shè)置需要restart才能生效
$?sudo?systemctl?restart?docker

[解決方法] 可以通過以下操作將容器刪除/重建。

#?/etc/docker/daemon.yaml
{
????"registry-mirrors":?["https://vec0xydj.mirror.aliyuncs.com"],??#?配置獲取官方鏡像的倉庫地址
????"experimental":?true,??#?啟用實驗功能
????"default-runtime":?"nvidia",??#?容器的默認OCI運行時(默認為runc)
????"live-restore":?true,??#?重啟dockerd服務(wù)的時候容易不終止
????"runtimes":?{??#?配置容器運行時
????????"nvidia":?{
????????????"path":?"/usr/bin/nvidia-container-runtime",
????????????"runtimeArgs":?[]
????????}
????},
????"default-address-pools":?[??#?配置容器使用的子網(wǎng)地址池
????????{
????????????"scope":?"local",
????????????"base":"172.17.0.0/12",
????????????"size":24
????????}
????]
}

$?vim?/etc/docker/daemon.json
{
??"default-address-pools"?:?[
????{
??????"base"?:?"172.240.0.0/16",
??????"size"?:?24
????}
??]
}

6. Docker 容器無法刪除

找不到對應(yīng)容器進程是最嚇人的

[問題起因] 今天遇到 docker 容器無法停止/終止/刪除，以為這個容器可能又出現(xiàn)了 dockerd 守護進程托管的情況，但是通過 ps -ef無法查到對應(yīng)的運行進程。哎，后來開始開始查 supervisor 以及 Dockerfile 中的進程，都沒有。這種情況的可能原因是容器啟動之后，主機因任何原因重新啟動并且沒有優(yōu)雅地終止容器。剩下的文件現(xiàn)在阻止你重新生成舊名稱的新容器，因為系統(tǒng)認為舊容器仍然存在。

#?刪除容器
$?sudo?docker?rm?-f?f8e8c3..
Error?response?from?daemon:?Conflict,?cannot?remove?the?default?name?of?the?container

[解決方法] 找到 /var/lib/docker/containers/ 下的對應(yīng)容器的文件夾，將其刪除，然后重啟一下 dockerd 即可。我們會發(fā)現(xiàn)，之前無法刪除的容器沒有了。

#?刪除容器文件
$?sudo?rm?-rf?/var/lib/docker/containers/f8e8c3...65720

#?重啟服務(wù)
$?sudo?systemctl?restart?docker.service

7. Docker 容器中文異常

容器存在問題話，記得優(yōu)先在官網(wǎng)查詢

[問題起因] 今天登陸之前部署的 MySQL 數(shù)據(jù)庫查詢，發(fā)現(xiàn)使用 SQL 語句無法查詢中文字段，即使直接輸入中文都沒有辦法顯示。

#?查看容器支持的字符集
root@b18f56aa1e15:#?locale?-a
C
C.UTF-8
POSIX

[解決方法] Docker 部署的 MySQL 系統(tǒng)使用的是 POSIX 字符集。然而 POSIX 字符集是不支持中文的，而 C.UTF-8 是支持中文的只要把系統(tǒng)中的環(huán)境 LANG 改為 "C.UTF-8" 格式即可解決問題。同理，在 K8S 進入 pod 不能輸入中文也可用此方法解決。

#?臨時解決
docker?exec?-it?some-mysql?env?LANG=C.UTF-8?/bin/bash

#?永久解決
docker?run?--name?some-mysql?\
????-e?MYSQL_ROOT_PASSWORD=my-secret-pw?\
????-d?mysql:tag?--character-set-server=utf8mb4?\
????--collation-server=utf8mb4_unicode_ci

8. Docker 容器網(wǎng)絡(luò)互通

了解 Docker 的四種網(wǎng)絡(luò)模型

[問題起因] 在本機部署 Nginx 容器想代理本機啟動的 Python 后端服務(wù)程序，但是對代碼服務(wù)如下的配置，結(jié)果訪問的時候一直提示 502 錯誤。

#?啟動Nginx服務(wù)
$?docker?run?-d?-p?80:80?$PWD:/etc/nginx?nginx

server?{
????...
????location?/api?{
????????proxy_pass?http://localhost:8080
????}
????...
}

[解決方法] 后面發(fā)現(xiàn)是因為 nginx.conf 配置文件中的 localhost 配置的有問題，由于 Nginx 是在容器中運行，所以 localhost 為容器中的 localhost，而非本機的 localhost，所以導(dǎo)致無法訪問。

可以將 nginx.conf 中的 localhost 改為宿主機的 IP 地址，就可以解決 502 的錯誤。

#?查詢宿主機IP地址?=>?172.17.0.1
$?ip?addr?show?docker0
docker0:??mtu?1500?qdisc?noqueue?state?UP?group?default
????link/ether?02:42:d5:4c:f2:1e?brd?ff:ff:ff:ff:ff:ff
????inet?172.17.0.1/16?scope?global?docker0
???????valid_lft?forever?preferred_lft?forever
????inet6?fe80::42:d5ff:fe4c:f21e/64?scope?link
???????valid_lft?forever?preferred_lft?forever

server?{
????...
????location?/api?{
????????proxy_pass?http://172.17.0.1:8080
????}
????...
}

當容器使用 host 網(wǎng)絡(luò)時，容器與宿主共用網(wǎng)絡(luò)，這樣就能在容器中訪問宿主機網(wǎng)絡(luò)，那么容器的 localhost 就是宿主機的 localhost 了。

#?服務(wù)的啟動方式有所改變(沒有映射出來端口)
#?因為本身與宿主機共用了網(wǎng)絡(luò)，宿主機暴露端口等同于容器中暴露端口
$?docker?run?-d?-p?80:80?--network=host?$PWD:/etc/nginx?nginxx

9. Docker 容器總線錯誤

總線錯誤看到的時候還是挺嚇人了

[問題起因] 在 docker 容器中運行程序的時候，提示 bus error 錯誤。

#?總線報錯
$?inv?app.user_op?--name=zhangsan
Bus?error?(core?dumped)

[解決方法] 原因是在 docker 運行的時候，shm 分區(qū)設(shè)置太小導(dǎo)致 share memory 不夠。不設(shè)置 --shm-size 參數(shù)時，docker 給容器默認分配的 shm 大小為 64M，導(dǎo)致程序啟動時不足。具體原因還是因為安裝 pytorch 包導(dǎo)致了，多進程跑任務(wù)的時候，docker 容器分配的共享內(nèi)存太小，導(dǎo)致 torch 要在 tmpfs 上面放模型數(shù)據(jù)用于子線程的共享不足，就出現(xiàn)報錯了。

#?問題原因
[email protected]:/opt/app#?df?-TH
Filesystem?????Type?????Size??Used?Avail?Use%?Mounted?on
overlay????????overlay??2.0T??221G??1.4T???3%?/
tmpfs??????????tmpfs?????68M?????0???68M???0%?/dev
shm????????????tmpfs?????68M???41k???68M???1%?/dev/shm

#?啟動docker的時候加上--shm-size參數(shù)(單位為b,k,m或g)
$?docker?run?-it?--rm?--shm-size=200m?pytorch/pytorch:latest

#?在docker-compose添加對應(yīng)配置
$?shm_size:?'2gb'

[解決方法] 還有一種情況就是容器內(nèi)的磁盤空間不足，也會導(dǎo)致 bus error 這樣的報錯，所以如果出現(xiàn)了，清除多余文件和目錄或者分配一個大的磁盤空間，就可以解決了。

#?磁盤空間不足
$?df?-Th
Filesystem?????Type?????Size??Used?Avail?Use%?Mounted?on
overlay????????overlay????1T????1T????0G?100%?/
shm????????????tmpfs?????64M???24K???64M???1%?/dev/shm

10. Docker NFS 掛載報錯

NFS 掛載之后容器程序使用異常為內(nèi)核版本太低導(dǎo)致的

[問題起因] 我們將服務(wù)部署到 openshift 集群中，啟動服務(wù)調(diào)用資源文件的時候，報錯信息如下所示。從報錯信息中，得知是在 Python3 程序執(zhí)行 read_file() 讀取文件的內(nèi)容，給文件加鎖的時候報錯了。但是奇怪的是，本地調(diào)試的時候發(fā)現(xiàn)服務(wù)都是可以正常運行的，文件加鎖也是沒問題的。后來發(fā)現(xiàn)，在 openshift 集群中使用的是 NFS 掛載的共享磁盤。

#?報錯信息
Traceback?(most?recent?call?last):
????......
????File?"xxx/utils/storage.py",?line?34,?in?xxx.utils.storage.LocalStorage.read_file
OSError:?[Errno?9]?Bad?file?descriptor

#?文件加鎖代碼
...
????with?open(self.mount(path),?'rb')?as?fileobj:
????????fcntl.flock(fileobj,?fcntl.LOCK_EX)
????????data?=?fileobj.read()
????return?data
...

[解決方法] 從下面的信息得知，要在 Linux 中使用 flock() 的話，就需要升級內(nèi)核版本到 2.6.11+ 才行。后來才發(fā)現(xiàn)，這實際上是由 RedHat 內(nèi)核中的一個錯誤引起的，并在 kernel-3.10.0-693.18.1.el7 版本中得到修復(fù)。所以對于 NFSv3 和 NFSv4 服務(wù)而已，就需要升級 Linux 內(nèi)核版本才能夠解決這個問題。

#?https://t.codebug.vip/questions-930901.htm
$?In?Linux?kernels?up?to?2.6.11,?flock()?does?not?lock?files?over?NFS?(i.e.,
the?scope?of?locks?was?limited?to?the?local?system).?[...]?Since?Linux?2.6.12,
NFS?clients?support?flock()?locks?by?emulating?them?as?byte-range?locks?on?the?entire?file.

11. Docker 使用默認網(wǎng)段

啟動的容器網(wǎng)絡(luò)無法相互通信，很是奇怪！

[問題起因] 我們在使用 Docker 啟動服務(wù)的時候，發(fā)現(xiàn)有時候服務(wù)之前可以相互連通，而有時啟動的多個服務(wù)之前卻出現(xiàn)了無法訪問的情況。究其原因，發(fā)現(xiàn)原來是因為使用的內(nèi)部私有地址網(wǎng)段不一致導(dǎo)致的。有的服務(wù)啟動到了 172.17 - 172.31 的網(wǎng)段，有的服務(wù)跑到了 192.169.0 - 192.168.224 的網(wǎng)段，這樣導(dǎo)致服務(wù)啟動之后出現(xiàn)無法訪問的情況(默認情況下，有下面這個兩個網(wǎng)段可供其使用)。

[解決方法] 上述問題的處理方式，就是手動指定 Docker 服務(wù)的啟動網(wǎng)段，二選一就可以了。

#?查看docker容器配置
$?cat?/etc/docker/daemon.json
{
????"registry-mirrors":?["https://vec0xydj.mirror.aliyuncs.com"],
????"default-address-pools":[{"base":"172.17.0.0/12",?"size":24}],
????"experimental":?true,
????"default-runtime":?"nvidia",
????"live-restore":?true,
????"runtimes":?{
????????"nvidia":?{
????????????"path":?"/usr/bin/nvidia-container-runtime",
????????????"runtimeArgs":?[]
????????}
????}
}

作者：escape

來源：https://www.escapelife.site/posts/43a2bb9b.html

推薦閱讀：