Containerd 的前世今生和保姆級入門教程
原文鏈接：//fuckcloudnative.io/posts/getting-started-with-containerd/
1. Containerd 的前世今生
很久以前，Docker 強勢崛起，以「鏡像」這個大招席捲全球，對其他容器技術進行致命的降維打擊，使其毫無招架之力，就連 Google 也不例外。Google 為了不被拍死在沙灘上，被迫拉下臉面（當然，跪舔是不可能的），希望 Docker 公司和自己聯合推進一個開源的容器運行時作為 Docker 的核心依賴，不然就走著瞧。Docker 公司覺得自己的智商被侮辱了，走著瞧就走著瞧，誰怕誰啊！
很明顯，Docker 公司的這個決策斷送了自己的大好前程，造成了今天的悲劇。
緊接著，Google 聯合 Red Hat、IBM 等幾位巨佬連哄帶騙忽悠 Docker 公司將 libcontainer 捐給中立的社區（OCI，Open Container Intiative），並改名為 runc，不留一點 Docker 公司的痕迹~~
這還不夠，為了徹底扭轉 Docker 一家獨大的局面，幾位大佬又合夥成立了一個基金會叫 CNCF（Cloud Native Computing Fundation），這個名字想必大家都很熟了，我就不詳細介紹了。CNCF 的目標很明確，既然在當前的維度上干不過 Docker，乾脆往上爬，升級到大規模容器編排的維度，以此來擊敗 Docker。
Docker 公司當然不甘示弱，搬出了 Swarm 和 Kubernetes 進行 PK，最後的結局大家都知道了，Swarm 戰敗。然後 Docker 公司耍了個小聰明，將自己的核心依賴 Containerd 捐給了 CNCF，以此來標榜 Docker 是一個 PaaS 平台。
很明顯，這個小聰明又大大加速了自己的滅亡。
巨佬們心想，想當初想和你合作搞個中立的核心運行時，你死要面子活受罪，就是不同意，好傢夥，現在自己搞了一個，還捐出來了，這是什麼操作？也罷，這倒省事了，我就直接拿 Containerd 來做文章吧。
首先呢，為了表示 Kubernetes 的中立性，當然要搞個標準化的容器運行時介面，只要適配了這個介面的容器運行時，都可以和我一起玩耍哦，第一個支援這個介面的當然就是 Containerd 啦。至於這個介面的名字，大家應該都知道了，它叫 CRI（Container Runntime Interface）。
這樣還不行，為了蠱惑 Docker 公司，Kubernetes 暫時先委屈自己，專門在自己的組件中集成了一個 shim（你可以理解為墊片），用來將 CRI 的調用翻譯成 Docker 的 API，讓 Docker 也能和自己愉快地玩耍，溫水煮青蛙，養肥了再殺。。。
就這樣，Kubernetes 一邊假裝和 Docker 愉快玩耍，一邊背地裡不斷優化 Containerd 的健壯性以及和 CRI 對接的絲滑性。現在 Containerd 的翅膀已經完全硬了，是時候卸下我的偽裝，和 Docker say bye bye 了。後面的事情大家也都知道了~~
Docker 這門技術成功了，Docker 這個公司卻失敗了。
2. Containerd 架構
時至今日，Containerd 已經變成一個工業級的容器運行時了，連口號都有了：超簡單！超健壯！可移植性超強！
當然，為了讓 Docker 以為自己不會搶飯碗，Containerd 聲稱自己的設計目的主要是為了嵌入到一個更大的系統中（暗指 Kubernetes），而不是直接由開發人員或終端用戶使用。
事實上呢，Containerd 現在基本上啥都能幹了，開發人員或者終端用戶可以在宿主機中管理完整的容器生命周期，包括容器鏡像的傳輸和存儲、容器的執行和管理、存儲和網路等。大家可以考慮學起來了。
學習 Containerd 最好的時機是關注公眾號 雲原生實驗室 後，其次是現在，看完了再關注公眾號也不遲😆。
先來看看 Containerd 的架構：
可以看到 Containerd 仍然採用標準的 C/S 架構，服務端通過 GRPC 協議提供穩定的 API，客戶端通過調用服務端的 API 進行高級的操作。
為了解耦，Containerd 將不同的職責劃分給不同的組件，每個組件就相當於一個子系統（subsystem）。連接不同子系統的組件被稱為模組。
總體上 Containerd 被劃分為兩個子系統：
- Bundle : 在 Containerd 中，
Bundle包含了配置、元數據和根文件系統數據，你可以理解為容器的文件系統。而 Bundle 子系統允許用戶從鏡像中提取和打包 Bundles。 - Runtime : Runtime 子系統用來執行 Bundles，比如創建容器。
其中，每一個子系統的行為都由一個或多個模組協作完成（架構圖中的 Core 部分）。每一種類型的模組都以插件的形式集成到 Containerd 中，而且插件之間是相互依賴的。例如，上圖中的每一個長虛線的方框都表示一種類型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又會依賴 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一個小方框都表示一個細分的插件，例如 Metadata Plugin 依賴 Containers Plugin、Content Plugin 等。 總之，萬物皆插件，插件就是模組，模組就是插件。
這裡介紹幾個常用的插件：
- Content Plugin : 提供對鏡像中可定址內容的訪問，所有不可變的內容都被存儲在這裡。
- Snapshot Plugin : 用來管理容器鏡像的文件系統快照。鏡像中的每一個 layer 都會被解壓成文件系統快照，類似於 Docker 中的
graphdriver。 - Metrics : 暴露各個組件的監控指標。
從總體來看，Containerd 被分為三個大塊：Storage、Metadata 和 Runtime，可以將上面的架構圖提煉一下：
這是使用 bucketbench 對 Docker、crio 和 Containerd 的性能測試結果，包括啟動、停止和刪除容器，以比較它們所耗的時間：
可以看到 Containerd 在各個方面都表現良好，總體性能還是優越於 Docker 和 crio 的。
3. Containerd 安裝
了解了 Containerd 的概念後，就可以動手安裝體驗一把了。本文的演示環境為 Ubuntu 18.04。
安裝依賴
為 seccomp 安裝依賴：
🐳 → sudo apt-get update
🐳 → sudo apt-get install libseccomp2
下載並解壓 Containerd 程式
Containerd 提供了兩個壓縮包，一個叫 containerd-${VERSION}.${OS}-${ARCH}.tar.gz，另一個叫 cri-containerd-${VERSION}.${OS}-${ARCH}.tar.gz。其中 cri-containerd-${VERSION}.${OS}-${ARCH}.tar.gz 包含了所有 Kubernetes 需要的二進位文件。如果你只是本地測試，可以選擇前一個壓縮包；如果是作為 Kubernetes 的容器運行時，需要選擇後一個壓縮包。
Containerd 是需要調用 runc 的，而第一個壓縮包是不包含 runc 二進位文件的，如果你選擇第一個壓縮包，還需要提前安裝 runc。所以我建議直接使用 cri-containerd 壓縮包。
首先從 release 頁面下載最新版本的壓縮包，當前最新版本為 1.4.3：
🐳 → wget //github.com/containerd/containerd/releases/download/v1.4.3/cri-containerd-cni-1.4.3-linux-amd64.tar.gz
# 也可以替換成下面的 URL 加速下載
🐳 → wget //download.fastgit.org/containerd/containerd/releases/download/v1.4.3/cri-containerd-cni-1.4.3-linux-amd64.tar.gz
可以通過 tar 的 -t 選項直接看到壓縮包中包含哪些文件：
🐳 → tar -tf cri-containerd-cni-1.4.3-linux-amd64.tar.gz
etc/
etc/cni/
etc/cni/net.d/
etc/cni/net.d/10-containerd-net.conflist
etc/crictl.yaml
etc/systemd/
etc/systemd/system/
etc/systemd/system/containerd.service
usr/
usr/local/
usr/local/bin/
usr/local/bin/containerd-shim-runc-v2
usr/local/bin/ctr
usr/local/bin/containerd-shim
usr/local/bin/containerd-shim-runc-v1
usr/local/bin/crictl
usr/local/bin/critest
usr/local/bin/containerd
usr/local/sbin/
usr/local/sbin/runc
opt/
opt/cni/
opt/cni/bin/
opt/cni/bin/vlan
opt/cni/bin/host-local
opt/cni/bin/flannel
opt/cni/bin/bridge
opt/cni/bin/host-device
opt/cni/bin/tuning
opt/cni/bin/firewall
opt/cni/bin/bandwidth
opt/cni/bin/ipvlan
opt/cni/bin/sbr
opt/cni/bin/dhcp
opt/cni/bin/portmap
opt/cni/bin/ptp
opt/cni/bin/static
opt/cni/bin/macvlan
opt/cni/bin/loopback
opt/containerd/
opt/containerd/cluster/
opt/containerd/cluster/version
opt/containerd/cluster/gce/
opt/containerd/cluster/gce/cni.template
opt/containerd/cluster/gce/configure.sh
opt/containerd/cluster/gce/cloud-init/
opt/containerd/cluster/gce/cloud-init/master.yaml
opt/containerd/cluster/gce/cloud-init/node.yaml
opt/containerd/cluster/gce/env
直接將壓縮包解壓到系統的各個目錄中：
🐳 → sudo tar -C / -xzf cri-containerd-cni-1.4.3-linux-amd64.tar.gz
將 /usr/local/bin 和 /usr/local/sbin 追加到 ~/.bashrc 文件的 $PATH 環境變數中：
export PATH=$PATH:/usr/local/bin:/usr/local/sbin
立即生效：
🐳 → source ~/.bashrc
查看版本：
🐳 → ctr version
Client:
Version: v1.4.3
Revision: 269548fa27e0089a8b8278fc4fc781d7f65a939b
Go version: go1.15.5
Server:
Version: v1.4.3
Revision: 269548fa27e0089a8b8278fc4fc781d7f65a939b
UUID: d1724999-91b3-4338-9288-9a54c9d52f70
生成配置文件
Containerd 的默認配置文件為 /etc/containerd/config.toml，我們可以通過命令來生成一個默認的配置：
🐳 → mkdir /etc/containerd
🐳 → containerd config default > /etc/containerd/config.toml
鏡像加速
由於某些不可描述的因素，在中國拉取公共鏡像倉庫的速度是極慢的，為了節約拉取時間，需要為 Containerd 配置鏡像倉庫的 mirror。Containerd 的鏡像倉庫 mirror 與 Docker 相比有兩個區別：
- Containerd 只支援通過
CRI拉取鏡像的 mirror，也就是說，只有通過crictl或者 Kubernetes 調用時 mirror 才會生效，通過ctr拉取是不會生效的。 Docker只支援為Docker Hub配置 mirror，而Containerd支援為任意鏡像倉庫配置 mirror。
配置鏡像加速之前，先來看下 Containerd 的配置結構，乍一看可能會覺得很複雜，複雜就複雜在 plugin 的配置部分：
[plugins]
[plugins."io.containerd.gc.v1.scheduler"]
pause_threshold = 0.02
deletion_threshold = 0
mutation_threshold = 100
schedule_delay = "0s"
startup_delay = "100ms"
[plugins."io.containerd.grpc.v1.cri"]
disable_tcp_service = true
stream_server_address = "127.0.0.1"
stream_server_port = "0"
stream_idle_timeout = "4h0m0s"
enable_selinux = false
sandbox_image = "k8s.gcr.io/pause:3.1"
stats_collect_period = 10
systemd_cgroup = false
enable_tls_streaming = false
max_container_log_line_size = 16384
disable_cgroup = false
disable_apparmor = false
restrict_oom_score_adj = false
max_concurrent_downloads = 3
disable_proc_mount = false
[plugins."io.containerd.grpc.v1.cri".containerd]
snapshotter = "overlayfs"
default_runtime_name = "runc"
no_pivot = false
[plugins."io.containerd.grpc.v1.cri".containerd.default_runtime]
runtime_type = ""
runtime_engine = ""
runtime_root = ""
privileged_without_host_devices = false
[plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime]
runtime_type = ""
runtime_engine = ""
runtime_root = ""
privileged_without_host_devices = false
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v1"
runtime_engine = ""
runtime_root = ""
privileged_without_host_devices = false
[plugins."io.containerd.grpc.v1.cri".cni]
bin_dir = "/opt/cni/bin"
conf_dir = "/etc/cni/net.d"
max_conf_num = 1
conf_template = ""
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["//registry-1.docker.io"]
[plugins."io.containerd.grpc.v1.cri".x509_key_pair_streaming]
tls_cert_file = ""
tls_key_file = ""
[plugins."io.containerd.internal.v1.opt"]
path = "/opt/containerd"
[plugins."io.containerd.internal.v1.restart"]
interval = "10s"
[plugins."io.containerd.metadata.v1.bolt"]
content_sharing_policy = "shared"
[plugins."io.containerd.monitor.v1.cgroups"]
no_prometheus = false
[plugins."io.containerd.runtime.v1.linux"]
shim = "containerd-shim"
runtime = "runc"
runtime_root = ""
no_shim = false
shim_debug = false
[plugins."io.containerd.runtime.v2.task"]
platforms = ["linux/amd64"]
[plugins."io.containerd.service.v1.diff-service"]
default = ["walking"]
[plugins."io.containerd.snapshotter.v1.devmapper"]
root_path = ""
pool_name = ""
base_image_size = ""
每一個頂級配置塊的命名都是 plugins."io.containerd.xxx.vx.xxx" 這種形式，其實每一個頂級配置塊都代表一個插件，其中 io.containerd.xxx.vx 表示插件的類型，vx 後面的 xxx 表示插件的 ID。可以通過 ctr 一覽無餘：
🐳 → ctr plugin ls
TYPE ID PLATFORMS STATUS
io.containerd.content.v1 content - ok
io.containerd.snapshotter.v1 btrfs linux/amd64 error
io.containerd.snapshotter.v1 devmapper linux/amd64 error
io.containerd.snapshotter.v1 aufs linux/amd64 ok
io.containerd.snapshotter.v1 native linux/amd64 ok
io.containerd.snapshotter.v1 overlayfs linux/amd64 ok
io.containerd.snapshotter.v1 zfs linux/amd64 error
io.containerd.metadata.v1 bolt - ok
io.containerd.differ.v1 walking linux/amd64 ok
io.containerd.gc.v1 scheduler - ok
io.containerd.service.v1 containers-service - ok
io.containerd.service.v1 content-service - ok
io.containerd.service.v1 diff-service - ok
io.containerd.service.v1 images-service - ok
io.containerd.service.v1 leases-service - ok
io.containerd.service.v1 namespaces-service - ok
io.containerd.service.v1 snapshots-service - ok
io.containerd.runtime.v1 linux linux/amd64 ok
io.containerd.runtime.v2 task linux/amd64 ok
io.containerd.monitor.v1 cgroups linux/amd64 ok
io.containerd.service.v1 tasks-service - ok
io.containerd.internal.v1 restart - ok
io.containerd.grpc.v1 containers - ok
io.containerd.grpc.v1 content - ok
io.containerd.grpc.v1 diff - ok
io.containerd.grpc.v1 events - ok
io.containerd.grpc.v1 healthcheck - ok
io.containerd.grpc.v1 images - ok
io.containerd.grpc.v1 leases - ok
io.containerd.grpc.v1 namespaces - ok
io.containerd.internal.v1 opt - ok
io.containerd.grpc.v1 snapshots - ok
io.containerd.grpc.v1 tasks - ok
io.containerd.grpc.v1 version - ok
io.containerd.grpc.v1 cri linux/amd64 ok
頂級配置塊下面的子配置塊表示該插件的各種配置，比如 cri 插件下面就分為 containerd、cni 和 registry 的配置，而 containerd 下面又可以配置各種 runtime，還可以配置默認的 runtime。
鏡像加速的配置就在 cri 插件配置塊下面的 registry 配置塊，所以需要修改的部分如下：
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["//dockerhub.mirrors.nwafu.edu.cn"]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."k8s.gcr.io"]
endpoint = ["//registry.aliyuncs.com/k8sxio"]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
endpoint = ["xxx"]
- registry.mirrors.”xxx” : 表示需要配置 mirror 的鏡像倉庫。例如，
registry.mirrors."docker.io"表示配置 docker.io 的 mirror。 - endpoint : 表示提供 mirror 的鏡像加速服務。例如，這裡推薦使用西北農林科技大學提供的鏡像加速服務作為
docker.io的 mirror。
至於 gcr.io，目前還沒有公共的加速服務。我自己掏錢搭了個加速服務，拉取速度大概是 3M/s 左右，有加速需求的同學可以通過微訊號：cloud-native-yang 加我為好友再詳細諮詢。
存儲配置
Containerd 有兩個不同的存儲路徑，一個用來保存持久化數據，一個用來保存運行時狀態。
root = "/var/lib/containerd"
state = "/run/containerd"
root用來保存持久化數據，包括 Snapshots, Content, Metadata 以及各種插件的數據。每一個插件都有自己單獨的目錄，Containerd 本身不存儲任何數據，它的所有功能都來自於已載入的插件，真是太機智了。
🐳 → tree -L 2 /var/lib/containerd/
/var/lib/containerd/
├── io.containerd.content.v1.content
│ ├── blobs
│ └── ingest
├── io.containerd.grpc.v1.cri
│ ├── containers
│ └── sandboxes
├── io.containerd.metadata.v1.bolt
│ └── meta.db
├── io.containerd.runtime.v1.linux
│ └── k8s.io
├── io.containerd.runtime.v2.task
├── io.containerd.snapshotter.v1.aufs
│ └── snapshots
├── io.containerd.snapshotter.v1.btrfs
├── io.containerd.snapshotter.v1.native
│ └── snapshots
├── io.containerd.snapshotter.v1.overlayfs
│ ├── metadata.db
│ └── snapshots
└── tmpmounts
18 directories, 2 files
state 用來保存臨時數據，包括 sockets、pid、掛載點、運行時狀態以及不需要持久化保存的插件數據。
🐳 → tree -L 2 /run/containerd/
/run/containerd/
├── containerd.sock
├── containerd.sock.ttrpc
├── io.containerd.grpc.v1.cri
│ ├── containers
│ └── sandboxes
├── io.containerd.runtime.v1.linux
│ └── k8s.io
├── io.containerd.runtime.v2.task
└── runc
└── k8s.io
8 directories, 2 files
OOM
還有一項配置需要留意：
oom_score = 0
Containerd 是容器的守護者，一旦發生記憶體不足的情況，理想的情況應該是先殺死容器，而不是殺死 Containerd。所以需要調整 Containerd 的 OOM 權重，減少其被 OOM Kill 的幾率。最好是將 oom_score 的值調整為比其他守護進程略低的值。這裡的 oom_socre 其實對應的是 /proc/<pid>/oom_socre_adj，在早期的 Linux 內核版本里使用 oom_adj 來調整權重, 後來改用 oom_socre_adj 了。該文件描述如下：
The value of
/proc/<pid>/oom_score_adjis added to the badness score before it
is used to determine which task to kill. Acceptable values range from -1000
(OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX). This allows userspace to
polarize the preference for oom killing either by always preferring a certain
task or completely disabling it. The lowest possible value, -1000, is
equivalent to disabling oom killing entirely for that task since it will always
report a badness score of 0.
在計算最終的 badness score 時，會在計算結果是中加上 oom_score_adj ,這樣用戶就可以通過該在值來保護某個進程不被殺死或者每次都殺某個進程。其取值範圍為 -1000 到 1000。
如果將該值設置為 -1000，則進程永遠不會被殺死，因為此時 badness score 永遠返回0。
建議 Containerd 將該值設置為 -999 到 0 之間。如果作為 Kubernetes 的 Worker 節點，可以考慮設置為 -999。
Systemd 配置
建議通過 systemd 配置 Containerd 作為守護進程運行，配置文件在上文已經被解壓出來了：
🐳 → cat /etc/systemd/system/containerd.service
# Copyright The containerd Authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# //www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
[Unit]
Description=containerd container runtime
Documentation=//containerd.io
After=network.target local-fs.target
[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/containerd
Type=notify
Delegate=yes
KillMode=process
Restart=always
RestartSec=5
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
LimitNOFILE=1048576
# Comment TasksMax if your systemd version does not supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
OOMScoreAdjust=-999
[Install]
WantedBy=multi-user.target
這裡有兩個重要的參數：
-
Delegate : 這個選項允許 Containerd 以及運行時自己管理自己創建的容器的
cgroups。如果不設置這個選項，systemd 就會將進程移到自己的cgroups中，從而導致 Containerd 無法正確獲取容器的資源使用情況。 -
KillMode : 這個選項用來處理 Containerd 進程被殺死的方式。默認情況下，systemd 會在進程的 cgroup 中查找並殺死 Containerd 的所有子進程，這肯定不是我們想要的。
KillMode欄位可以設置的值如下。- control-group（默認值）：當前控制組裡面的所有子進程，都會被殺掉
- process：只殺主進程
- mixed：主進程將收到 SIGTERM 訊號，子進程收到 SIGKILL 訊號
- none：沒有進程會被殺掉，只是執行服務的 stop 命令。
我們需要將 KillMode 的值設置為
process，這樣可以確保升級或重啟 Containerd 時不殺死現有的容器。
現在到了最關鍵的一步：啟動 Containerd。執行一條命令就完事：
🐳 → systemctl enable containerd --now
接下來進入本文最後一部分：Containerd 的基本使用方式。本文只會介紹 Containerd 的本地使用方法，即本地客戶端 ctr 的使用方法，不會涉及到 crictl，後面有機會再介紹 crictl。
4. Containerd 快速安裝
如果你想在一分鐘內快速裝好 Kubernetes 和 Containerd，可以使用 Sealos 來部署。該項目旨在做一個簡單幹凈輕量級穩定的 kubernetes 安裝工具，一條命令，離線安裝，包含所有依賴，內核負載不依賴 haproxy keepalived,純 golang 開發,99 年證書。1.12.0 版本的離線包搭載了最新版本的 Containerd，還支援 arm64 架構，簡直就是簡直了。
部署方法特別簡單，首先下載並安裝 sealos, sealos 是個 golang 的二進位工具，直接下載拷貝到 bin 目錄即可, release 頁面也可下載：
🐳 → wget -c //sealyun.oss-cn-beijing.aliyuncs.com/latest/sealos
🐳 → chmod +x sealos && mv sealos /usr/bin
下載離線資源包：
🐳 → wget -c //sealyun.oss-cn-beijing.aliyuncs.com/7b6af025d4884fdd5cd51a674994359c-1.18.0/kube1.18.0.tar.gz
安裝一個三 master 的高可用 Kubernetes 集群：
🐳 → sealos init --passwd 123456
--master 192.168.0.2 --master 192.168.0.3 --master 192.168.0.4
--node 192.168.0.5
--pkg-url /root/kube1.18.0.tar.gz
--version v1.18.0
然後就完事了。。。
5. ctr 使用
ctr 目前很多功能做的還沒有 docker 那麼完善，但基本功能已經具備了。下面將圍繞鏡像和容器這兩個方面來介紹其使用方法。
鏡像
鏡像下載：
🐳 → ctr i pull docker.io/library/nginx:alpine
docker.io/library/nginx:alpine: resolved |++++++++++++++++++++++++++++++++++++++|
index-sha256:efc93af57bd255ffbfb12c89ec0714dd1a55f16290eb26080e3d1e7e82b3ea66: done |++++++++++++++++++++++++++++++++++++++|
manifest-sha256:6ceeeab513f7d15cea38c1f8dfe5455323b5a1bfd568516b3b0ee70406f75247: done |++++++++++++++++++++++++++++++++++++++|
config-sha256:0fde4fb87e476fd1655b3f04f55aa5b4b3ef7de7c701eb46573bb5a5dcf66fd2: done |++++++++++++++++++++++++++++++++++++++|
layer-sha256:abaddf4965e5e9ce9953f2e136b3bf9cc15365adbcf0c68b108b1cc26c12b1be: done |++++++++++++++++++++++++++++++++++++++|
layer-sha256:05e7bc50f07f000e9993ec0d264b9ffcbb9a01a4d69c68f556d25e9811a8f7f4: done |++++++++++++++++++++++++++++++++++++++|
layer-sha256:c78f7f670e47cf98494e7dbe08e463d34c160bf6a5939a2155ff4438cb8b0e80: done |++++++++++++++++++++++++++++++++++++++|
layer-sha256:ce77cf6a2ede66c463dcdd39f1a43cfbac3723a99e94f697bc20faee0f7cce1b: done |++++++++++++++++++++++++++++++++++++++|
layer-sha256:3080fd9f46494247c9298a6a3d9694f03f6a32898a07ffbe1c17a0752bae5c4e: done |++++++++++++++++++++++++++++++++++++++|
elapsed: 17.3s total: 8.7 Mi (513.8 KiB/s)
unpacking linux/amd64 sha256:efc93af57bd255ffbfb12c89ec0714dd1a55f16290eb26080e3d1e7e82b3ea66...
done
本地鏡像列表查詢：
🐳 → ctr i ls
REF TYPE DIGEST SIZE PLATFORMS LABELS
docker.io/library/nginx:alpine application/vnd.docker.distribution.manifest.list.v2+json sha256:efc93af57bd255ffbfb12c89ec0714dd1a55f16290eb26080e3d1e7e82b3ea66 9.3 MiB linux/386,linux/amd64,linux/arm/v6,linux/arm/v7,linux/arm64/v8,linux/ppc64le,linux/s390x -
這裡需要注意PLATFORMS，它是鏡像的能夠運行的平台標識。
將鏡像掛載到主機目錄：
🐳 → ctr i mount docker.io/library/nginx:alpine /mnt
🐳 → tree -L 1 /mnt
/mnt
├── bin
├── dev
├── docker-entrypoint.d
├── docker-entrypoint.sh
├── etc
├── home
├── lib
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
└── var
18 directories, 1 file
將鏡像從主機目錄上卸載：
🐳 → ctr i unmount /mnt
將鏡像導出為壓縮包：
🐳 → ctr i export nginx.tar.gz docker.io/library/nginx:alpine
從壓縮包導入鏡像：
🐳 → ctr i import nginx.tar.gz
其他操作可以自己查看幫助：
🐳 → ctr i --help
NAME:
ctr images - manage images
USAGE:
ctr images command [command options] [arguments...]
COMMANDS:
check check that an image has all content available locally
export export images
import import images
list, ls list images known to containerd
mount mount an image to a target path
unmount unmount the image from the target
pull pull an image from a remote
push push an image to a remote
remove, rm remove one or more images by reference
tag tag an image
label set and clear labels for an image
OPTIONS:
--help, -h show help
對鏡像的更高級操作可以使用子命令 content，例如在線編輯鏡像的 blob 並生成一個新的 digest：
🐳 → ctr content ls
DIGEST SIZE AGE LABELS
...
...
sha256:fdd7fff110870339d34cf071ee90fbbe12bdbf3d1d9a14156995dfbdeccd7923 740B 7 days containerd.io/gc.ref.content.2=sha256:4e537e26e21bf61836f827e773e6e6c3006e3c01c6d59f4b058b09c2753bb929,containerd.io/gc.ref.content.1=sha256:188c0c94c7c576fff0792aca7ec73d67a2f7f4cb3a6e53a84559337260b36964,containerd.io/gc.ref.content.0=sha256:b7199797448c613354489644be1f60aa2d8e9c2278989100c72ede3001334f7b,containerd.io/distribution.source.ghcr.fuckcloudnative.io=yangchuansheng/grafana-backup-tool
🐳 → ctr content edit --editor vim sha256:fdd7fff110870339d34cf071ee90fbbe12bdbf3d1d9a14156995dfbdeccd7923
容器
創建容器：
🐳 → ctr c create docker.io/library/nginx:alpine nginx
🐳 → ctr c ls
CONTAINER IMAGE RUNTIME
nginx docker.io/library/nginx:alpine io.containerd.runc.v2
查看容器的詳細配置：
# 和 docker inspect 類似
🐳 → ctr c info nginx
其他操作可以自己查看幫助：
🐳 → ctr c --help
NAME:
ctr containers - manage containers
USAGE:
ctr containers command [command options] [arguments...]
COMMANDS:
create create container
delete, del, rm delete one or more existing containers
info get info about a container
list, ls list containers
label set and clear labels for a container
checkpoint checkpoint a container
restore restore a container from checkpoint
OPTIONS:
--help, -h show help
任務
上面 create 的命令創建了容器後，並沒有處於運行狀態，只是一個靜態的容器。一個 container 對象只是包含了運行一個容器所需的資源及配置的數據結構，這意味著 namespaces、rootfs 和容器的配置都已經初始化成功了，只是用戶進程(這裡是 nginx)還沒有啟動。
然而一個容器真正的運行起來是由 Task 對象實現的，task 代表任務的意思，可以為容器設置網卡，還可以配置工具來對容器進行監控等。
所以還需要通過 Task 啟動容器：
🐳 → ctr task start -d nginx
🐳 → ctr task ls
TASK PID STATUS
nginx 131405 RUNNING
當然，也可以一步到位直接創建並運行容器：
🐳 → ctr run -d docker.io/library/nginx:alpine nginx
進入容器：
# 和 docker 的操作類似，但必須要指定 --exec-id，這個 id 可以隨便寫，只要唯一就行
🐳 → ctr task exec --exec-id 0 -t nginx sh
暫停容器：
# 和 docker pause 類似
🐳 → ctr task pause nginx
容器狀態變成了 PAUSED：
🐳 → ctr task ls
TASK PID STATUS
nginx 149857 PAUSED
恢復容器：
🐳 → ctr task resume nginx
ctr 沒有 stop 容器的功能，只能暫停或者殺死容器。
殺死容器：
🐳 → ctr task kill nginx
獲取容器的 cgroup 資訊：
# 這個命令用來獲取容器的記憶體、CPU 和 PID 的限額與使用量。
🐳 → ctr task metrics nginx
ID TIMESTAMP
nginx 2020-12-15 09:15:13.943447167 +0000 UTC
METRIC VALUE
memory.usage_in_bytes 77131776
memory.limit_in_bytes 9223372036854771712
memory.stat.cache 6717440
cpuacct.usage 194187935
cpuacct.usage_percpu [0 335160 0 5395642 3547200 58559242 0 0 0 0 0 0 6534104 5427871 3032481 2158941 8513633 4620692 8261063 3885961 3667830 0 4367411 356280 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1585841 0 7754942 5818102 21430929 0 0 0 0 0 0 1811840 2241260 2673960 6041161 8210604 2991221 10073713 1111020 3139751 0 640080 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
pids.current 97
pids.limit 0
查看容器中所有進程的 PID：
🐳 → ctr task ps nginx
PID INFO
149857 -
149921 -
149922 -
149923 -
149924 -
149925 -
149926 -
149928 -
149929 -
149930 -
149932 -
149933 -
149934 -
...
注意：這裡的 PID 是宿主機看到的 PID，不是容器中看到的 PID。
命名空間
除了 k8s 有命名空間以外，Containerd 也支援命名空間。
🐳 → ctr ns ls
NAME LABELS
default
如果不指定，ctr 默認是 default 空間。
目前 Containerd 的定位還是解決運行時，所以目前他還不能完全替代 dockerd，例如使用 Dockerfile 來構建鏡像。其實這不是什麼大問題，我再給大家介紹一個大招：Containerd 和 Docker 一起用！
Containerd + Docker
事實上，Docker 和 Containerd 是可以同時使用的，只不過 Docker 默認使用的 Containerd 的命名空間不是 default，而是 moby。下面就是見證奇蹟的時刻。
首先從其他裝了 Docker 的機器或者 GitHub 上下載 Docker 相關的二進位文件，然後使用下面的命令啟動 Docker：
🐳 → dockerd --containerd /run/containerd/containerd.sock --cri-containerd
接著用 Docker 運行一個容器：
🐳 → docker run -d --name nginx nginx:alpine
現在再回過頭來查看 Containerd 的命名空間：
🐳 → ctr ns ls
NAME LABELS
default
moby
查看該命名空間下是否有容器：
🐳 → ctr -n moby c ls
CONTAINER IMAGE RUNTIME
b7093d7aaf8e1ae161c8c8ffd4499c14ba635d8e174cd03711f4f8c27818e89a - io.containerd.runtime.v1.linux
我艹，還可以醬紫？看來以後用 Containerd 不耽誤我 docker build 了~~
最後提醒一句：Kubernetes 用戶不用驚慌，Kubernetes 默認使用的是 Containerd 的 k8s.io 命名空間，所以 ctr -n k8s.io 就能看到 Kubernetes 創建的所有容器啦，也不用擔心 crictl 不支援 load 鏡像了，因為 ctr -n k8s.io 可以 load 鏡像啊，嘻嘻😬
Kubernetes 1.18.2 1.17.5 1.16.9 1.15.12離線安裝包發布地址//store.lameleg.com ，歡迎體驗。 使用了最新的sealos v3.3.6版本。 作了主機名解析配置優化，lvscare 掛載/lib/module解決開機啟動ipvs載入問題， 修復lvscare社區netlink與3.10內核不兼容問題,sealos生成百年證書等特性。更多特性 //github.com/fanux/sealos 。歡迎掃描下方的二維碼加入釘釘群 ，釘釘群已經集成sealos的機器人實時可以看到sealos的動態。
