如何絲滑般將 Kubernetes 容器運行時從 Docker 切換成 Containerd

作者：k8s技術圈 2021-08-18 06:40:54

云計算

前面我們了解了 containerd 的發展歷史和基本使用方式，本節我們就來嘗試下使用 containerd 來作為 Kubernetes 集群的容器運行時。

[[418144]]

前面我們了解了 containerd 的發展歷史和基本使用方式，本節我們就來嘗試下使用 containerd 來作為 Kubernetes 集群的容器運行時。

前面我們安裝的集群默認使用的是 Docker 作為容器運行時，那么應該如何將容器運行時從 Docker 切換到 containerd 呢?

維護節點

首先標記需要切換的節點為維護模式，強制驅逐節點上正在運行的 Pod，這樣可以最大程度降低切換過程中影響應用的正常運行，比如我們先將 node1 節點切換到 containerd。

首先使用 kubectl cordon 命令將 node1 節點標記為 unschedulable 不可調度狀態：

# 將 node1 標記為 unschedulable 
➜  ~ kubectl cordon node1 
node/node1 cordoned 
➜  ~ kubectl get nodes 
NAME     STATUS                     ROLES    AGE   VERSION 
master   Ready                      master   85d   v1.19.11 
node1    Ready,SchedulingDisabled   <none>   85d   v1.19.11 
node2    Ready                      <none>   85d   v1.19.11

執行完上面的命令后，node1 節點變成了一個 SchedulingDisabled 狀態，表示不可調度，這樣新創建的 Pod 就不會調度到當前節點上來了。

接下來維護 node1 節點，使用 kubectl drain 命令來維護節點并驅逐節點上的 Pod：

# 維護 node1 節點，驅逐 Pod 
➜  ~ kubectl drain node1 --ignore-daemonsets 
node/node1 already cordoned 
WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-flannel-ds-mzdgl, kube-system/kube-proxy-vddh9, lens-metrics/node-exporter-2g4hr 
evicting pod "kiali-85c8cdd5b5-27cwv" 
evicting pod "jenkins-587b78f5cd-9gvn8" 
evicting pod "argocd-application-controller-0" 
pod/argocd-application-controller-0 evicted 
pod/kiali-85c8cdd5b5-27cwv evicted 
pod/jenkins-587b78f5cd-9gvn8 evicted 
node/node1 evicted

上面的命令會強制將 node1 節點上的 Pod 進行驅逐，我們加了一個 --ignore-daemonsets 的參數可以用來忽略 DaemonSet 控制器管理的 Pods，因為這些 Pods 不用驅逐到其他節點去，當節點驅逐完成后接下來我們就可以來對節點進行維護操作了，除了切換容器運行時可以這樣操作，比如我們需要變更節點配置、升級內核等操作的時候都可以先將節點進行驅逐，然后再進行維護。

切換 containerd

接下來停掉 docker、containerd 和 kubelet：

➜  ~ systemctl stop kubelet 
➜  ~ systemctl stop docker 
➜  ~ systemctl stop containerd

因為我們安裝的 Docker 默認安裝使用了 containerd 作為后端的容器運行時，所以不需要單獨安裝 containerd 了，當然你也可以將 Docker 和 containerd 完全卸載掉，然后重新安裝，這里我們選擇直接使用之前安裝的 containerd。

因為 containerd 中默認已經實現了 CRI，但是是以 plugin 的形式配置的，以前 Docker 中自帶的 containerd 默認是將 CRI 這個插件禁用掉了的(使用配置 disabled_plugins = ["cri"])，所以這里我們重新生成默認的配置文件來覆蓋掉：

➜  ~ containerd config default > /etc/containerd/config.toml

前面我們已經介紹過上面的配置文件了，首先我們修改默認的 pause 鏡像為國內的地址，替換 [plugins."io.containerd.grpc.v1.cri"] 下面的 sandbox_image：

[plugins."io.containerd.grpc.v1.cri"] 
  sandbox_image = "registry.aliyuncs.com/k8sxio/pause:3.2" 
  ......

同樣再配置下鏡像倉庫的加速器地址：

[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://bqr1dr1n.mirror.aliyuncs.com"] 
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."k8s.gcr.io"] 
      endpoint = ["https://registry.aliyuncs.com/k8sxio"]

接下來修改 kubelet 配置，將容器運行時配置為 containerd，打開 /etc/sysconfig/kubelet 文件，在該文件中可以添加一些額外的 kubelet 啟動參數，配置如下所示：

KUBELET_EXTRA_ARGS="--container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock"

上面的配置中我們增加了兩個參數，--container-runtime 參數是用來指定使用的容器運行時的，可選值為 docker 或者 remote，默認是 docker，由于我們這里使用的是 containerd 這種容器運行時，所以配置為 remote 值(也就是除 docker 之外的容器運行時都應該指定為 remote)，然后第二個參數 --container-runtime-endpoint 是用來指定遠程的運行時服務的 endpiont 地址的，在 Linux 系統中一般都是使用 unix 套接字的形式，比如這里我們就是指定連接 containerd 的套接字地址 unix:///run/containerd/containerd.sock。

其實還應該配置一個 --image-service-endpoint 參數用來指定遠程 CRI 的鏡像服務地址，如果沒有指定則默認使用 --container-runtime-endpoint 的值了，因為 CRI 都會實現容器和鏡像服務的。

配置完成后重啟 containerd 和 kubelet 即可：

➜  ~ systemctl daemon-reload 
➜  ~ systemctl restart containerd 
➜  ~ systemctl restart kubelet

重啟完成后查看節點狀態是否正常：

➜  ~ kubectl get nodes -o wide 
NAME     STATUS                     ROLES    AGE   VERSION    INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION                CONTAINER-RUNTIME 
master   Ready                      master   85d   v1.19.11   192.168.31.30    <none>        CentOS Linux 7 (Core)   3.10.0-1160.25.1.el7.x86_64   docker://19.3.9 
node1    Ready,SchedulingDisabled   <none>   85d   v1.19.11   192.168.31.95    <none>        CentOS Linux 7 (Core)   3.10.0-1160.25.1.el7.x86_64   containerd://1.4.4 
node2    Ready                      <none>   85d   v1.19.11   192.168.31.215   <none>        CentOS Linux 7 (Core)   3.10.0-1160.25.1.el7.x86_64   docker://19.3.9

獲取節點的時候加上 -o wide 可以查看節點的更多信息，從上面對比可以看到 node1 節點的容器運行時已經切換到 containerd://1.4.4 了。

最后把 node1 節點重新加回到集群中來允許調度 Pod 資源：

➜  ~ kubectl uncordon node1 
node/node1 uncordoned 
➜  ~ kubectl get nodes 
NAME     STATUS   ROLES    AGE   VERSION 
master   Ready    master   85d   v1.19.11 
node1    Ready    <none>   85d   v1.19.11 
node2    Ready    <none>   85d   v1.19.11

用同樣的方法再去處理其他節點即可將整個集群切換成容器運行時 containerd 了。

crictl

現在我們可以 node1 節點上使用 ctr 命令來管理 containerd，查看多了一個名為 k8s.io 的命名空間：

➜  ~ ctr ns ls 
NAME   LABELS 
k8s.io 
moby

上文我們已經介紹 kubernetes 集群對接的 containerd 所有資源都在 k8s.io 的命名空間下面，而 docker 的則默認在 moby 下面，當然現在 moby 下面沒有任何的數據了，但是在 k8s.io 命名空間下面就有很多鏡像和容器資源了：

➜  ~ ctr -n moby c ls 
CONTAINER    IMAGE    RUNTIME 
➜  ~ ctr -n moby i ls 
REF TYPE DIGEST SIZE PLATFORMS LABELS 
➜  ~ ctr -n moby t ls 
TASK    PID    STATUS 
ctr -n k8s.io i ls -q 
docker.io/library/busybox:latest 
docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60 
quay.io/coreos/flannel:v0.14.0 
quay.io/coreos/flannel@sha256:4a330b2f2e74046e493b2edc30d61fdebbdddaaedcb32d62736f25be8d3c64d5 
registry.aliyuncs.com/k8sxio/pause:3.2 
......

我們當然可以直接使用 ctr 命令來直接管理鏡像或容器資源，但是我們在使用過程中明顯可以感覺到該工具沒有 docker CLI 方便，從使用便捷性和功能性上考慮，我們更推薦使用 crictl 作為管理工具，crictl 為 CRI 兼容的容器運行時提供 CLI，這允許 CRI 運行時開發人員在無需設置 Kubernetes 組件的情況下調試他們的運行時。

接下來我們就先簡單介紹下如何使用 crictl 工具來提升管理容器運行時的效率。

安裝

首先我們需要先安裝 crictl 工具，直接從 cri-tools 的 release 頁面下載對應的二進制包，解壓放入 PATH 路徑下即可：

➜  ~ VERSION="v1.22.0" 
➜  ~ wget https://github.com/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-$VERSION-linux-amd64.tar.gz 
# 如果有限制，也可以替換成下面的 URL 加速下載 
# wget https://download.fastgit.org/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-$VERSION-linux-amd64.tar.gz 
➜  ~ tar zxvf crictl-$VERSION-linux-amd64.tar.gz -C /usr/local/bin 
➜  ~ rm -f crictl-$VERSION-linux-amd64.tar.gz 
➜  ~ crictl -v 
crictl version v1.22.0

到這里證明 crictl 工具安裝成功了。

用法

crictl 安裝完成后，接下來我們來了解下該工具的一些常見使用方法。

首先需要修改下默認的配置文件，默認為 /etc/crictl.yaml，在文件中指定容器運行時和鏡像的 endpoint 地址，內容如下所示：

runtime-endpoint: unix:///var/run/containerd/containerd.sock 
image-endpoint: unix:///var/run/containerd/containerd.sock 
debug: false 
pull-image-on-create: false 
disable-pull-on-run: false

配置完成后就可以使用 crictl 命令了。

獲取 Pod 列表

通過 crictl pods 命令可以獲取當前節點上運行的 Pods 列表，如下所示：

➜  ~ crictl pods 
POD ID              CREATED             STATE               NAME                       NAMESPACE           ATTEMPT             RUNTIME 
cb18081b33933       39 minutes ago      Ready               kube-flannel-ds-mzdgl      kube-system         1                   (default) 
95d6004c55902       40 minutes ago      Ready               node-exporter-2g4hr        lens-metrics        1                   (default) 
cfae80b3209db       40 minutes ago      Ready               kube-proxy-vddh9           kube-system         1                   (default) 
99ac2583da87f       40 minutes ago      Ready               jenkins-587b78f5cd-dfzns   kube-ops            0                   (default) 
07ebdc51f1def       45 minutes ago      NotReady            node-exporter-2g4hr        lens-metrics        0                   (default) 
bec027b98f194       45 minutes ago      NotReady            kube-proxy-vddh9           kube-system         0                   (default) 
b44b5ec385053       45 minutes ago      NotReady            kube-flannel-ds-mzdgl      kube-system         0                   (default)

還可以使用 --name 參數獲取指定的 Pod：

➜  ~ crictl pods --name kube-flannel-ds-mzdgl 
POD ID              CREATED             STATE               NAME                    NAMESPACE           ATTEMPT             RUNTIME 
cb18081b33933       About an hour ago   Ready               kube-flannel-ds-mzdgl   kube-system         1                   (default)

同樣也可以根據標簽來篩選 Pod 列表：

➜  ~ crictl pods --label app=flannel 
POD ID              CREATED             STATE               NAME                    NAMESPACE           ATTEMPT             RUNTIME 
cb18081b33933       About an hour ago   Ready               kube-flannel-ds-mzdgl   kube-system         1                   (default)

獲取鏡像列表

使用 crictl images 命令可以獲取所有的鏡像：

➜  ~ crictl images 
IMAGE                                     TAG                 IMAGE ID            SIZE 
docker.io/jenkins/jenkins                 lts                 3b4ec91827f28       303MB 
docker.io/library/busybox                 latest              69593048aa3ac       771kB 
quay.io/coreos/flannel                    v0.14.0             8522d622299ca       21.1MB 
quay.io/prometheus/node-exporter          v1.0.1              0e0218889c33b       13MB 
registry.aliyuncs.com/k8sxio/kube-proxy   v1.19.11            732e0635ac9e0       49.3MB 
registry.aliyuncs.com/k8sxio/pause        3.2                 80d28bedfe5de       300kB

同樣在命令后面可以加上 -v 參數來顯示鏡像的詳細信息：

➜  ~ crictl images -v 
ID: sha256:3b4ec91827f28ed482b08f6e379c56ea2308967d10aa4f458442c922e0771f87 
RepoTags: docker.io/jenkins/jenkins:lts 
RepoDigests: docker.io/jenkins/jenkins@sha256:abcd55c9f19c85808124a4d82e3412719cd5c511c03ebd7d4210e9fa9e8f1029 
Size: 302984002 
Username: jenkins 
 
ID: sha256:69593048aa3acfee0f75f20b77acb549de2472063053f6730c4091b53f2dfb02 
RepoTags: docker.io/library/busybox:latest 
RepoDigests: docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60 
Size: 770886 
 
......

獲取容器列表

使用 crictl ps 命令可以獲取正在運行的容器列表：

➜  ~ crictl ps 
CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID 
c8474738e4587       3b4ec91827f28       About an hour ago   Running             jenkins             0                   99ac2583da87f 
0f9c826f87ef8       8522d622299ca       About an hour ago   Running             kube-flannel        1                   cb18081b33933 
da444f718d37b       0e0218889c33b       About an hour ago   Running             node-exporter       1                   95d6004c55902 
a484a8a69ea59       732e0635ac9e0       About an hour ago   Running             kube-proxy          1                   cfae80b3209db

還有更多其他可選參數，可以通過 crictl ps -h 獲取，比如顯示最近創建的兩個容器：

➜  ~ crictl ps -n 2 
CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID 
c8474738e4587       3b4ec91827f28       About an hour ago   Running             jenkins             0                   99ac2583da87f 
0f9c826f87ef8       8522d622299ca       About an hour ago   Running             kube-flannel        1                   cb18081b33933

使用 -s 選項按照狀態進行過濾：

➜  ~ crictl ps -s Running 
CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID 
c8474738e4587       3b4ec91827f28       About an hour ago   Running             jenkins             0                   99ac2583da87f 
0f9c826f87ef8       8522d622299ca       About an hour ago   Running             kube-flannel        1                   cb18081b33933 
da444f718d37b       0e0218889c33b       About an hour ago   Running             node-exporter       1                   95d6004c55902 
a484a8a69ea59       732e0635ac9e0       About an hour ago   Running             kube-proxy          1                   cfae80b3209db

在容器中執行命令

crictl 也有類似 exec 的命令支持，比如在容器 ID 為 c8474738e4587 的容器中執行一個 date 命令：

➜  ~ crictl exec -it c8474738e4587 date 
Tue 17 Aug 2021 08:23:02 AM UTC

輸出容器日志

還可以獲取容器日志信息：

➜  ~ crictl logs c8474738e4587 
...... 
2021-08-17 07:19:51.846+0000 [id=155]   INFO    hudson.model.AsyncPeriodicWork#lambda$doRun$0: Started Periodic background build discarder 
2021-08-17 07:19:51.854+0000 [id=155]   INFO    hudson.model.AsyncPeriodicWork#lambda$doRun$0: Finished Periodic background build discarder. 6 ms 
2021-08-17 08:19:51.846+0000 [id=404]   INFO    hudson.model.AsyncPeriodicWork#lambda$doRun$0: Started Periodic background build discarder 
2021-08-17 08:19:51.848+0000 [id=404]   INFO    hudson.model.AsyncPeriodicWork#lambda$doRun$0: Finished Periodic background build discarder. 1 ms

和 kubectl logs 類似于，還可以使用 -f 選項來 Follow 日志輸出，--tail N 也可以指定輸出最近的 N 行日志。

資源統計

使用 crictl stats 命令可以列舉容器資源的使用情況：

➜  ~ crictl stats 
CONTAINER           CPU %               MEM                 DISK                INODES 
0f9c826f87ef8       0.00                21.2MB              0B                  17 
a484a8a69ea59       0.00                23.55MB             12.29kB             25 
c8474738e4587       0.08                413.2MB             3.338MB             12 
da444f718d37b       0.00                14.46MB             0B                  16

此外鏡像和容器相關的一些操作也都支持，比如：

拉取鏡像：crictl pull
運行 Pod：crictl runp
運行容器：crictl run
啟動容器：crictl start
刪除容器：crictl rm
刪除鏡像：crictl rmi
刪除 Pod：crictl rmp
停止容器：crictl stop
停止 Pod：crictl stopp
......

更多信息請參考 https://github.com/kubernetes-sigs/cri-tools。

CLI 對比

前面我們了解了圍繞鏡像、容器和 Pod 可以使用 docker、ctr、crictl 這些命令行工具進行管理，接下來我們就來比較下這幾個常用命令的使用區別。

需要注意的是通過 ctr containers create 命令創建的容器只是一個靜態的容器，所以還需要通過 ctr task start 來啟動容器進程。當然，也可以直接使用 ctr run 命令來創建并運行容器。在進入容器操作時，與 docker 不同的是，必須在 ctr task exec 命令后指定 --exec-id 參數，這個 id 可以隨便寫，只要唯一就行。另外，ctr 沒有 stop 容器的功能，只能暫停(ctr task pause)或者殺死(ctr task kill)容器。

另外要說明的是 crictl pods 列出的是 Pod 的信息，包括 Pod 所在的命名空間以及狀態。crictl ps 列出的是應用容器的信息，而 docker ps 列出的是初始化容器(pause 容器)和應用容器的信息，初始化容器在每個 Pod 啟動時都會創建，通常不會關注，所以 crictl 使用起來更簡潔明了一些。

日志配置

docker 和 containerd 除了在常用命令上有些區別外，在容器日志及相關參數配置方面也存在一些差異。

當使用 Docker 作為 Kubernetes 容器運行時的時候，容器日志的落盤是由 Docker 來完成的，日志被保存在類似 /var/lib/docker/containers/ 的目錄下面，kubelet 會在 /var/log/pods 和 /var/log/containers 下面創建軟鏈接，指向容器日志目錄下的容器日志文件。對應的日志相關配置可以通過配置文件進行指定，如下所示：

{ 
    "log-driver": "json-file", 
    "log-opts": { 
        "max-size": "100m", 
        "max-file: "10" 
    } 
}

而當使用 containerd 作為 Kubernetes 容器運行時的時候，容器日志的落盤則由 kubelet 來完成了，被直接保存在 /var/log/pods/ 目錄下面，同時在 /var/log/containers 目錄下創建軟鏈接指向日志文件。同樣日志配置則是通過 kubelet 參數中進行指定的，如下所示：

--container-log-max-files=10 --container-log-max-size="100Mi"

所以如果我們有進行日志收集理論上來說兩種方案都是兼容的，基本上不用改動。

當然除了這些差異之外，可能對于我們來說鏡像構建這個環節是我們最需要關注的了。切換到 containerd 之后，需要注意 docker.sock 不再可用，也就意味著不能再在容器里面執行 docker 命令來構建鏡像了。所以接下來需要和大家介紹幾種不需要使用 docker.sock 也可以構建鏡像的方法。

責任編輯：姜華來源： k8s技術圈