1. Containerd 的前世今生

很久以前，Docker 強(qiáng)勢(shì)崛起，以“鏡像”這個(gè)大招席卷全球，對(duì)其他容器技術(shù)進(jìn)行致命的降維打擊，使其毫無(wú)招架之力，就連 Google 也不例外。Google 為了不被拍死在沙灘上，被迫拉下臉面（當(dāng)然，跪舔是不可能的），希望 Docker 公司和自己聯(lián)合推進(jìn)一個(gè)開源的容器運(yùn)行時(shí)作為 Docker 的核心依賴，不然就走著瞧。Docker 公司覺得自己的智商被侮辱了，走著瞧就走著瞧，誰(shuí)怕誰(shuí)??！

很明顯，Docker 公司的這個(gè)決策斷送了自己的大好前程，造成了今天的悲劇。

緊接著，Google 聯(lián)合 Red Hat、IBM 等幾位巨佬連哄帶騙忽悠 Docker 公司將 libcontainer 捐給中立的社區(qū)（OCI，Open Container Intiative），并改名為 runc，不留一點(diǎn) Docker 公司的痕跡~~

這還不夠，為了徹底扭轉(zhuǎn) Docker 一家獨(dú)大的局面，幾位大佬又合伙成立了一個(gè)基金會(huì)叫 CNCF（Cloud Native Computing Fundation），這個(gè)名字想必大家都很熟了，我就不詳細(xì)介紹了。CNCF 的目標(biāo)很明確，既然在當(dāng)前的維度上干不過 Docker，干脆往上爬，升級(jí)到大規(guī)模容器編排的維度，以此來(lái)?yè)魯?Docker。

Docker 公司當(dāng)然不甘示弱，搬出了 Swarm 和 Kubernetes 進(jìn)行 PK，最后的結(jié)局大家都知道了，Swarm 戰(zhàn)敗。然后 Docker 公司耍了個(gè)小聰明，將自己的核心依賴 Containerd 捐給了 CNCF，以此來(lái)標(biāo)榜 Docker 是一個(gè) PaaS 平臺(tái)。

很明顯，這個(gè)小聰明又大大加速了自己的滅亡。

巨佬們心想，想當(dāng)初想和你合作搞個(gè)中立的核心運(yùn)行時(shí)，你死要面子活受罪，就是不同意，好家伙，現(xiàn)在自己搞了一個(gè)，還捐出來(lái)了，馬老師，發(fā)生甚莫事了？

這好嗎？

這不好

也罷，這倒省事了，我就直接拿 Containerd 來(lái)做文章吧。

首先呢，為了表示 Kubernetes 的中立性，當(dāng)然要搞個(gè)標(biāo)準(zhǔn)化的容器運(yùn)行時(shí)接口，只要適配了這個(gè)接口的容器運(yùn)行時(shí)，都可以和我一起玩耍哦，第一個(gè)支持這個(gè)接口的當(dāng)然就是 Containerd 啦。至于這個(gè)接口的名字，大家應(yīng)該都知道了，它叫 CRI（Container Runntime Interface）。

這樣還不行，為了蠱惑 Docker 公司，Kubernetes 暫時(shí)先委屈自己，專門在自己的組件中集成了一個(gè) shim（你可以理解為墊片），用來(lái)將 CRI 的調(diào)用翻譯成 Docker 的 API，讓 Docker 也能和自己愉快地玩耍，溫水煮青蛙，養(yǎng)肥了再殺。。。

就這樣，Kubernetes 一邊假裝和 Docker 愉快玩耍，一邊背地里不斷優(yōu)化 Containerd 的健壯性以及和 CRI 對(duì)接的絲滑性?，F(xiàn)在 Containerd 的翅膀已經(jīng)完全硬了，是時(shí)候卸下我的偽裝，和 Docker say bye bye 了。后面的事情大家也都知道了~~

Docker 這門技術(shù)成功了，Docker 這個(gè)公司卻失敗了。

2. Containerd 架構(gòu)

時(shí)至今日，Containerd 已經(jīng)變成一個(gè)工業(yè)級(jí)的容器運(yùn)行時(shí)了，連口號(hào)都有了：超簡(jiǎn)單！超健壯！可移植性超強(qiáng)！

當(dāng)然，為了讓 Docker 以為自己不會(huì)搶飯碗，Containerd 聲稱自己的設(shè)計(jì)目的主要是為了嵌入到一個(gè)更大的系統(tǒng)中（暗指 Kubernetes），而不是直接由開發(fā)人員或終端用戶使用。

事實(shí)上呢，Containerd 現(xiàn)在基本上啥都能干了，開發(fā)人員或者終端用戶可以在宿主機(jī)中管理完整的容器生命周期，包括容器鏡像的傳輸和存儲(chǔ)、容器的執(zhí)行和管理、存儲(chǔ)和網(wǎng)絡(luò)等。大家可以考慮學(xué)起來(lái)了。

學(xué)習(xí) Containerd 最好的時(shí)機(jī)是關(guān)注公眾號(hào) 云原生實(shí)驗(yàn)室 后，其次是現(xiàn)在，看完了再關(guān)注公眾號(hào)也不遲?。

先來(lái)看看 Containerd 的架構(gòu)：

可以看到 Containerd 仍然采用標(biāo)準(zhǔn)的 C/S 架構(gòu)，服務(wù)端通過 GRPC 協(xié)議提供穩(wěn)定的 API，客戶端通過調(diào)用服務(wù)端的 API 進(jìn)行高級(jí)的操作。

為了解耦，Containerd 將不同的職責(zé)劃分給不同的組件，每個(gè)組件就相當(dāng)于一個(gè)子系統(tǒng)（subsystem）。連接不同子系統(tǒng)的組件被稱為模塊。

總體上 Containerd 被劃分為兩個(gè)子系統(tǒng)：

• Bundle : 在 Containerd 中，Bundle 包含了配置、元數(shù)據(jù)和根文件系統(tǒng)數(shù)據(jù)，你可以理解為容器的文件系統(tǒng)。而 Bundle 子系統(tǒng)允許用戶從鏡像中提取和打包 Bundles。
• Runtime : Runtime 子系統(tǒng)用來(lái)執(zhí)行 Bundles，比如創(chuàng)建容器。

其中，每一個(gè)子系統(tǒng)的行為都由一個(gè)或多個(gè)模塊協(xié)作完成（架構(gòu)圖中的 Core 部分）。每一種類型的模塊都以插件的形式集成到 Containerd 中，而且插件之間是相互依賴的。例如，上圖中的每一個(gè)長(zhǎng)虛線的方框都表示一種類型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又會(huì)依賴 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一個(gè)小方框都表示一個(gè)細(xì)分的插件，例如 Metadata Plugin 依賴 Containers Plugin、Content Plugin 等。總之，萬(wàn)物皆插件，插件就是模塊，模塊就是插件。

這里介紹幾個(gè)常用的插件：

• Content Plugin : 提供對(duì)鏡像中可尋址內(nèi)容的訪問，所有不可變的內(nèi)容都被存儲(chǔ)在這里。
• Snapshot Plugin : 用來(lái)管理容器鏡像的文件系統(tǒng)快照。鏡像中的每一個(gè) layer 都會(huì)被解壓成文件系統(tǒng)快照，類似于 Docker 中的 graphdriver。
• Metrics : 暴露各個(gè)組件的監(jiān)控指標(biāo)。

從總體來(lái)看，Containerd 被分為三個(gè)大塊：Storage、Metadata 和 Runtime，可以將上面的架構(gòu)圖提煉一下：

這是使用 bucketbench^[1] 對(duì) Docker、crio 和 Containerd 的性能測(cè)試結(jié)果，包括啟動(dòng)、停止和刪除容器，以比較它們所耗的時(shí)間：

可以看到 Containerd 在各個(gè)方面都表現(xiàn)良好，總體性能還是優(yōu)越于 Docker 和 crio 的。

3. Containerd 安裝

了解了 Containerd 的概念后，就可以動(dòng)手安裝體驗(yàn)一把了。本文的演示環(huán)境為 Ubuntu 18.04。

安裝依賴

為 seccomp 安裝依賴：

???→?sudo?apt-get?update
???→?sudo?apt-get?install?libseccomp2

下載并解壓 Containerd 程序

Containerd 提供了兩個(gè)壓縮包，一個(gè)叫 containerd-${VERSION}.${OS}-${ARCH}.tar.gz，另一個(gè)叫 cri-containerd-${VERSION}.${OS}-${ARCH}.tar.gz。其中 ?cri-containerd-${VERSION}.${OS}-${ARCH}.tar.gz 包含了所有 Kubernetes 需要的二進(jìn)制文件。如果你只是本地測(cè)試，可以選擇前一個(gè)壓縮包；如果是作為 Kubernetes 的容器運(yùn)行時(shí)，需要選擇后一個(gè)壓縮包。

Containerd 是需要調(diào)用 runc 的，而第一個(gè)壓縮包是不包含 runc 二進(jìn)制文件的，如果你選擇第一個(gè)壓縮包，還需要提前安裝 runc。所以我建議直接使用 cri-containerd 壓縮包。

首先從 release 頁(yè)面^[2]下載最新版本的壓縮包，當(dāng)前最新版本為 1.4.3：

???→?wget?https://github.com/containerd/containerd/releases/download/v1.4.3/cri-containerd-cni-1.4.3-linux-amd64.tar.gz

#?也可以替換成下面的?URL?加速下載
???→?wget?https://download.fastgit.org/containerd/containerd/releases/download/v1.4.3/cri-containerd-cni-1.4.3-linux-amd64.tar.gz

可以通過 tar 的 -t 選項(xiàng)直接看到壓縮包中包含哪些文件：

???→?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

直接將壓縮包解壓到系統(tǒng)的各個(gè)目錄中：

???→?sudo?tar?-C?/?-xzf?cri-containerd-cni-1.4.3-linux-amd64.tar.gz

將 /usr/local/bin 和 /usr/local/sbin 追加到 ~/.bashrc 文件的 $PATH 環(huán)境變量中：

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 的默認(rèn)配置文件為 ?/etc/containerd/config.toml，我們可以通過命令來(lái)生成一個(gè)默認(rèn)的配置：

???→?mkdir?/etc/containerd
???→?containerd?config?default?>?/etc/containerd/config.toml

鏡像加速

由于某些不可描述的因素，在國(guó)內(nèi)拉取公共鏡像倉(cāng)庫(kù)的速度是極慢的，為了節(jié)約拉取時(shí)間，需要為 Containerd 配置鏡像倉(cāng)庫(kù)的 mirror。Containerd 的鏡像倉(cāng)庫(kù) mirror 與 Docker 相比有兩個(gè)區(qū)別：

• Containerd 只支持通過 CRI 拉取鏡像的 mirror，也就是說，只有通過 crictl 或者 Kubernetes 調(diào)用時(shí) mirror 才會(huì)生效，通過 ctr 拉取是不會(huì)生效的。
• Docker 只支持為 Docker Hub 配置 mirror，而 Containerd 支持為任意鏡像倉(cāng)庫(kù)配置 mirror。

配置鏡像加速之前，先來(lái)看下 Containerd 的配置結(jié)構(gòu)，乍一看可能會(huì)覺得很復(fù)雜，復(fù)雜就復(fù)雜在 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 = ["https://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 = ""

每一個(gè)頂級(jí)配置塊的命名都是 plugins."io.containerd.xxx.vx.xxx" 這種形式，其實(shí)每一個(gè)頂級(jí)配置塊都代表一個(gè)插件，其中 io.containerd.xxx.vx 表示插件的類型，vx 后面的 xxx 表示插件的 ID?？梢酝ㄟ^ ctr 一覽無(wú)余：

???→?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

頂級(jí)配置塊下面的子配置塊表示該插件的各種配置，比如 cri 插件下面就分為 containerd、cni 和 registry 的配置，而 containerd 下面又可以配置各種 runtime，還可以配置默認(rèn)的 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 = ["https://dockerhub.mirrors.nwafu.edu.cn"]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."k8s.gcr.io"]
          endpoint = ["https://registry.aliyuncs.com/k8sxio"]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
          endpoint = ["xxx"]

• registry.mirrors."xxx" : 表示需要配置 mirror 的鏡像倉(cāng)庫(kù)。例如，registry.mirrors."docker.io" 表示配置 docker.io 的 mirror。
• endpoint : 表示提供 mirror 的鏡像加速服務(wù)。例如，這里推薦使用西北農(nóng)林科技大學(xué)提供的鏡像加速服務(wù)作為 docker.io 的 mirror。

至于 gcr.io，目前還沒有公共的加速服務(wù)。我自己掏錢搭了個(gè)加速服務(wù)，拉取速度大概是 3M/s 左右，有加速需求的同學(xué)可以通過微信號(hào)：cloud-native-yang 加我為好友再詳細(xì)咨詢。

存儲(chǔ)配置

Containerd 有兩個(gè)不同的存儲(chǔ)路徑，一個(gè)用來(lái)保存持久化數(shù)據(jù)，一個(gè)用來(lái)保存運(yùn)行時(shí)狀態(tài)。

root = "/var/lib/containerd"
state = "/run/containerd"

root用來(lái)保存持久化數(shù)據(jù)，包括 Snapshots, Content, Metadata 以及各種插件的數(shù)據(jù)。每一個(gè)插件都有自己?jiǎn)为?dú)的目錄，Containerd 本身不存儲(chǔ)任何數(shù)據(jù)，它的所有功能都來(lái)自于已加載的插件，真是太機(jī)智了。

???→?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 用來(lái)保存臨時(shí)數(shù)據(jù)，包括 sockets、pid、掛載點(diǎn)、運(yùn)行時(shí)狀態(tài)以及不需要持久化保存的插件數(shù)據(jù)。

???→?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

還有一項(xiàng)配置需要留意：

oom_score = 0

Containerd 是容器的守護(hù)者，一旦發(fā)生內(nèi)存不足的情況，理想的情況應(yīng)該是先殺死容器，而不是殺死 Containerd。所以需要調(diào)整 Containerd 的 OOM 權(quán)重，減少其被 OOM Kill 的幾率。最好是將 oom_score 的值調(diào)整為比其他守護(hù)進(jìn)程略低的值。這里的 oom_socre 其實(shí)對(duì)應(yīng)的是 /proc//oom_socre_adj，在早期的 Linux 內(nèi)核版本里使用 oom_adj 來(lái)調(diào)整權(quán)重, 后來(lái)改用 oom_socre_adj 了。該文件描述如下：

The value of /proc//oom_score_adj is 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.

在計(jì)算最終的 badness score 時(shí)，會(huì)在計(jì)算結(jié)果是中加上 oom_score_adj ,這樣用戶就可以通過該在值來(lái)保護(hù)某個(gè)進(jìn)程不被殺死或者每次都?xì)⒛硞€(gè)進(jìn)程。其取值范圍為 -1000 到 1000。

如果將該值設(shè)置為 -1000，則進(jìn)程永遠(yuǎn)不會(huì)被殺死，因?yàn)榇藭r(shí) badness score 永遠(yuǎn)返回0。

建議 Containerd 將該值設(shè)置為 -999 到 0 之間。如果作為 Kubernetes 的 Worker 節(jié)點(diǎn)，可以考慮設(shè)置為 -999。

Systemd 配置

建議通過 systemd 配置 Containerd 作為守護(hù)進(jìn)程運(yùn)行，配置文件在上文已經(jīng)被解壓出來(lái)了：

???→?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
#
#?????http://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=https://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

這里有兩個(gè)重要的參數(shù)：

• Delegate : 這個(gè)選項(xiàng)允許 Containerd 以及運(yùn)行時(shí)自己管理自己創(chuàng)建的容器的 cgroups。如果不設(shè)置這個(gè)選項(xiàng)，systemd 就會(huì)將進(jìn)程移到自己的 cgroups 中，從而導(dǎo)致 Containerd 無(wú)法正確獲取容器的資源使用情況。

• KillMode : 這個(gè)選項(xiàng)用來(lái)處理 Containerd 進(jìn)程被殺死的方式。默認(rèn)情況下，systemd 會(huì)在進(jìn)程的 cgroup 中查找并殺死 Containerd 的所有子進(jìn)程，這肯定不是我們想要的。KillMode字段可以設(shè)置的值如下。

  我們需要將 KillMode 的值設(shè)置為 process，這樣可以確保升級(jí)或重啟 Containerd 時(shí)不殺死現(xiàn)有的容器。

• control-group（默認(rèn)值）：當(dāng)前控制組里面的所有子進(jìn)程，都會(huì)被殺掉
• process：只殺主進(jìn)程
• mixed：主進(jìn)程將收到 SIGTERM 信號(hào)，子進(jìn)程收到 SIGKILL 信號(hào)
• none：沒有進(jìn)程會(huì)被殺掉，只是執(zhí)行服務(wù)的 stop 命令。

現(xiàn)在到了最關(guān)鍵的一步：?jiǎn)?dòng) Containerd。執(zhí)行一條命令就完事：

???→?systemctl?enable?containerd?--now

接下來(lái)進(jìn)入本文最后一部分：Containerd 的基本使用方式。本文只會(huì)介紹 Containerd 的本地使用方法，即本地客戶端 ctr 的使用方法，不會(huì)涉及到 crictl，后面有機(jī)會(huì)再介紹 crictl。

4. Containerd 快速安裝

如果你想在一分鐘內(nèi)快速裝好 Kubernetes 和 Containerd，可以使用 Sealos^[3] 來(lái)部署。該項(xiàng)目旨在做一個(gè)簡(jiǎn)單干凈輕量級(jí)穩(wěn)定的 kubernetes 安裝工具，一條命令，離線安裝，包含所有依賴，內(nèi)核負(fù)載不依賴 haproxy keepalived,純 golang 開發(fā),99 年證書。1.20.0 版本的離線包搭載了最新版本的 Containerd，還支持 arm64 架構(gòu)，簡(jiǎn)直就是簡(jiǎn)直了。

部署方法特別簡(jiǎn)單，首先下載并安裝 sealos, sealos 是個(gè) golang 的二進(jìn)制工具，直接下載拷貝到 bin 目錄即可, release 頁(yè)面也可下載：

???→?wget?-c?https://sealyun.oss-cn-beijing.aliyuncs.com/latest/sealos
???→?chmod?+x?sealos?&&?mv?sealos?/usr/bin

下載離線資源包：

???→?wget?-c?https://sealyun.oss-cn-beijing.aliyuncs.com/7b6af025d4884fdd5cd51a674994359c-1.18.0/kube1.18.0.tar.gz

安裝一個(gè)三 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

然后就完事了。。。

詳細(xì)使用方式請(qǐng)?jiān)L問 https://sealyun.com。

5. ctr 使用

ctr 目前很多功能做的還沒有 docker 那么完善，但基本功能已經(jīng)具備了。下面將圍繞鏡像和容器這兩個(gè)方面來(lái)介紹其使用方法。

鏡像

鏡像下載：

???→?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，它是鏡像的能夠運(yùn)行的平臺(tái)標(biāo)識(shí)。

將鏡像掛載到主機(jī)目錄：

???→?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

將鏡像從主機(jī)目錄上卸載：

???→?ctr?i?unmount?/mnt

將鏡像導(dǎo)出為壓縮包：

???→?ctr?i?export?nginx.tar.gz?docker.io/library/nginx:alpine

從壓縮包導(dǎo)入鏡像：

???→?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

對(duì)鏡像的更高級(jí)操作可以使用子命令 content，例如在線編輯鏡像的 blob 并生成一個(gè)新的 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

容器

創(chuàng)建容器：

???→?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

查看容器的詳細(xì)配置：

#?和?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

任務(wù)

???→?ctr?task?start?-d?nginx

???→?ctr?task?ls
TASK?????PID???????STATUS
nginx????131405????RUNNING

當(dāng)然，也可以一步到位直接創(chuàng)建并運(yùn)行容器：

???→?ctr?run?-d?docker.io/library/nginx:alpine?nginx

進(jìn)入容器：

#?和?docker?的操作類似，但必須要指定?--exec-id，這個(gè)?id?可以隨便寫，只要唯一就行
???→?ctr?task?exec?--exec-id?0?-t?nginx?sh

暫停容器：

#?和?docker?pause?類似
???→?ctr?task?pause?nginx

容器狀態(tài)變成了 PAUSED：

???→?ctr?task?ls
TASK?????PID???????STATUS
nginx????149857????PAUSED

恢復(fù)容器：

???→?ctr?task?resume?nginx

ctr 沒有 stop 容器的功能，只能暫?；蛘邭⑺廊萜?。

殺死容器：

???→?ctr?task?kill?nginx

獲取容器的 cgroup 信息：

#?這個(gè)命令用來(lái)獲取容器的內(nèi)存、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

查看容器中所有進(jìn)程的 PID：

???→?ctr?task?ps?nginx
PID???????INFO
149857????-
149921????-
149922????-
149923????-
149924????-
149925????-
149926????-
149928????-
149929????-
149930????-
149932????-
149933????-
149934????-
...

注意：這里的 PID 是宿主機(jī)看到的 PID，不是容器中看到的 PID。

命名空間

除了 k8s 有命名空間以外，Containerd 也支持命名空間。

???→?ctr?ns?ls
NAME????LABELS
default

如果不指定，ctr 默認(rèn)是 default 空間。

目前 Containerd 的定位還是解決運(yùn)行時(shí)，所以目前他還不能完全替代 dockerd，例如使用 Dockerfile 來(lái)構(gòu)建鏡像。其實(shí)這不是什么大問題，我再給大家介紹一個(gè)大招：Containerd 和 Docker 一起用！

Containerd + Docker

事實(shí)上，Docker 和 Containerd 是可以同時(shí)使用的，只不過 Docker 默認(rèn)使用的 Containerd 的命名空間不是 default，而是 moby。下面就是見證奇跡的時(shí)刻。

首先從其他裝了 Docker 的機(jī)器或者 GitHub 上下載 Docker 相關(guān)的二進(jìn)制文件，然后使用下面的命令啟動(dòng) Docker：

???→?dockerd?--containerd?/run/containerd/containerd.sock?--cri-containerd

接著用 Docker 運(yùn)行一個(gè)容器：

???→?docker?run?-d?--name?nginx?nginx:alpine

現(xiàn)在再回過頭來(lái)查看 Containerd 的命名空間：

???→?ctr?ns?ls
NAME????LABELS
default
moby

查看該命名空間下是否有容器：

???→?ctr?-n?moby?c?ls
CONTAINER???????????????????????????????????????????????????????????IMAGE????RUNTIME
b7093d7aaf8e1ae161c8c8ffd4499c14ba635d8e174cd03711f4f8c27818e89a????-????????io.containerd.runtime.v1.linux

我艸，還可以醬紫？看來(lái)以后用 Containerd 不耽誤我 docker build 了~~

最后提醒一句：Kubernetes 用戶不用驚慌，Kubernetes 默認(rèn)使用的是 Containerd 的 k8s.io 命名空間，所以 ctr -n k8s.io 就能看到 Kubernetes 創(chuàng)建的所有容器啦，也不用擔(dān)心 crictl 不支持 load 鏡像了，因?yàn)?ctr -n k8s.io 可以 load 鏡像啊，嘻嘻?

參考資料