CRI — containerd研究

研究CRI — containerD背後的image相關操作,image檔案儲存佔用空間位置

參考這篇:

Why and How to Use containerd from the Command Line - Ivan Velichko

可以發現有裝containerd後可以執行ctr指令

所以觀看有抓來的images的指令是:

ctr images ls

我在master機上執行得到的,需要權限,所以我加sudo

正常應該會是長如下這樣:

參考link

其他還有一些確認指令可以看看:

好像不太對...master上都是空的!

所以我啟動worker機來執行看看:

worker也沒有,超怪!

還是空的

最後找到有人也問一樣問題:

回頭在master執行

sudo ctr --namespace k8s.io containers ls

確認ctr的namespace執行:

sudo ctr namespaces list

同理可以看看曾經跑過的images了吧,執行:

sudo ctr --namespace k8s.io images ls

媽呀,我終於看到image list了

看看task,執行:

sudo ctr --namespace k8s.io task ls

參考containerd的github md裡面也很多ctr指令可以參考使用:

ctr指令也有help,執行:

sudo ctr -h

參考以下這篇知道containerd部會儲存latest的image:

link

偶然看到的YT影片,將cri從docker轉到containerd

找到關聯目錄(這邊用root):

找到疑似存放image檔案的地方,但是都是10月份的

可能是因為containerd沒存latest版image的關係:

用find指令(用root)從根目錄下去找到:

我試著抓看看舊一點的nginx:

後來在worker機上發現很多當天的檔案在以下路徑上:

/var/lib/containerd/io.containerd.content.v1.content/blobs/sha256/

worker1的

worker1的images list

worker2的

worker2的images list

可能就是image檔(上面有-t可以把最新的顯示在上面)

所以在嘗試在master建沒用過版本的nginx

在worker2上建立出沒用過的1.19.9版nginx

所以到worker2再次確認到:

worker2終於找到可能的目錄!不過這看起來是打包過的,檔案又多...

依樣在看看ctr指令查詢image list:

可以比對上面的worker2的image list比對確認,剛剛真的沒有1.19.9的tag版號

這時候再看看worker1有沒有:

worker1沒有新增1.19.9的nginx

所以結論:

當未曾佈署過的image的tag版本,被Scheduler安排要佈署到某台worker時

身為CRI的containerd會在該worker node下載image到以下目錄(可能):

/var/lib/containerd/io.containerd.content.v1.content/blobs/sha256/

之後才依據這個下載好的image執行佈署container到該機台上

↓=======重點========↓

亦即image相關檔案的儲存是by被佈署的Node各自儲放

↑=======重點========↑

其他確認:

光是1.19.9跑起來就多這些

試試content get指令,會進到二進位檔去,不過我挑的是library可能是原因

指令確認存放image相關檔案目錄執行:

du -sh {路徑,這邊是/var/lib/containerd/io.containerd.content.v1.content/blobs/sha256/}

現在佔545M