實戰直擊：Kubernetes棄用Docker？
作者 ｜ 劉啟偉，廣東公司網絡管理中心網管系統室平臺團隊核心專家。近年來，網管系統室一方面大力推進OSS應用建設，為“三零三自”的自智網絡賦能；另一方面，積極推動微服務、容器化、PaaS、DevOps等云原生技術的實踐落地。在團隊中負責DevOps平臺和容器云的建設運營工作，擁有豐富的Kubernetes、Istio、DevOps工具鏈落地實踐經驗，致力于克服技術落地難題，用云原生技術賦能應用。
Labs 導讀
?Kubernetes是一個可移植、可擴展的開源平臺，用于管理容器化的工作負載和服務，可促進聲明式配置和自動化。Kubernetes擁有一個龐大且快速增長的生態系統，其服務、支持和工具的使用范圍廣泛。
1前言
前段時間，kubernetes推出了1.24版本，曾經轟動一時的docker棄用也正式實裝了，這意味著1.24版本之后，docker將不能作為k8s的容器運行時。docker作為云原生的基礎技術底座，如果kubernetes不再支持docker，這在互聯網IT業界都會引發不大不小的恐慌，這到底該怎么辦？是不是docker完全不能使用了？
2技術的真相
其實kubernetes只是棄用了dockershim，并不是棄用了docker的全部。docker體系中的containerd是符合CRI標準的，可以繼續作為kubernetes的容器運行時。而OCI標準的實現者runC也是docker體系的。
另一方面，docker構建的鏡像符合OCI標準，可以運行在kubernetes集群中，所以仍然可以在本地使用docker進行開發和測試。
2.1 OCI和CRI標準分別是什么？
OCI（Open Container Initiative）是一組圍繞容器技術的開放標準和規范，主要定義了容器的生命周期管理規范。OCI的實現者通常被稱為“低級容器運行時”，例如runC。低級運行時的主要功能是按照給定的容器文件系統和JSON配置文件，創建容器，并管理容器的生命周期。
CRI（Container Runtime Interface）是一組插件接口，定義了kubernetes（kubelet）與容器運行時的接口規范，實現兩者之間的解耦。通過CRI與kubernetes交互的運行時通常被稱為“高級容器運行時”。高級運行時的功能是為容器準備必要的運行環境，比如拉取鏡像、解壓鏡像并創建容器文件系統、創建容器網絡等，然后調用低級容器運行時，創建和運行容器。
2.2 kubernetes支持哪些容器運行時？
kubernetes支持任何符合CRI標準的容器運行時。在1.23版本之前，常用的容器運行時有三種：docker、containerd、cri-o.
docker
docker守護進程是不符合CRI標準的。為了支持docker作為容器運行時，kubelet內置了一個dockershim模塊，kubelet通過CRI調用dockershim，再由它轉換請求，調用docker守護進程，而1.24版本將要移除的就是這個模塊。此模式下創建容器時的調用過程如下：
- kubelet通過CRI調用dockershim；
- dockershim轉換請求，調用docker守護進程；
- docker調用containerd；
- containerd創建containerd-shim進程，再由containerd-shim調用runC完成容器創建。最終容器由containerd-shim管理，容器內所有進程都是containerd-shim的子進程。
containerd
containerd是從docker守護進程中獨立出來的容器運行時，最終也要通過runC運行容器。
在CRI標準被提出后，為了兼容CRI，減少調用開銷，containerd開發了一個守護進程，叫CRI-containerd。原先調用鏈kubelet -> dockershim -> dockerd -> containerd 被簡化成為 kubelet -> CRI-containerd -> containerd。后來，containerd干脆將CRI-containerd以CRI插件形式內建在項目中，直接通過方法調用，進一步將調用鏈簡化為 kubelet -> containerd。
cri-o
CRI標準被提出后，紅帽按照CRI開發的一個輕量級容器運行時，是CRI標準的最小實現。此模式下kubelet直接調用cri-o，再由cri-o調用runC完成容器創建和管理，調用鏈比較簡潔。
廣東公司網絡管理中心網管系統室負責建設和維護O域容器云，近期剛好啟動kubernetes 版本升級工作，借此機會，我們決定在測試環境上將容器運行時從docker遷移至cri-o，并驗證下kubernetes 1.23 -> 1.24版本升級方案，以下是遷移的部分注意事項及詳細步驟。
3遷移注意事項和詳細步驟
注意事項：
- 對于使用docker in docker的pod，如果是掛載宿主機的docker.sock守護進程，遷移后將不能運行，如果是在容器中安裝獨立的docker守護進程，遷移后仍然可以正常運行。
- /etc/docker/daemon.json中的配置需要同步到新的運行時，比如倉庫的鏡像站點。
- 檢查各種運維腳本，如果包含docker命令需要修改。
- 容器stdout/stderr日志形式變更，如果使用Fluentd或者Filebeat收集日志，需要修改配置。
① 日志目錄：使用docker時，日志通過/var/log/containers鏈接到/var/log/pods/目錄，最后鏈接到/var/lib/docker/containers/xxx/目錄，如果使用其他運行時，一般是通過/var/log/containers鏈接到/var/log/pods/目錄，由kubelet管理。
② 日志格式：使用docker時，很多人習慣設置json格式，而切換到其他運行時，默認格式是text，格式為“time stream log-info”。日志解析配置需要修改。
③ 日志回滾：使用docker時，在daemon.json配置，切換運行時后，通過kubelet的配置項containerLogMaxSize、containerLogMaxFiles設置。
怎么將kubernetes的容器運行時從docker遷移至cri-o？
- 操作系統：centOS 7.9
- 內核版本：5.4.178
- kubernetes版本：1.23.3
- cri-o：1.22.3
1. 遷移按節點進行，先驅逐pod并隔離節點
kubectl drain --delete-emptydir-data --force --ignore-daemonsets <NODE_NAME>
2. 卸載docker
systemctl stop kubelet
systemctl stop docker
systemctl disable docker
yum remove -y docker-ce
# docker數據目錄先保留一段時間，運行沒異常再刪除
rm -rf /var/lib/docker
3. 內核設置
這些設置一般在k8s安裝前都會設置，這里再確認一次，已經設置好的忽略這一步。
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sysctl --system
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
modprobe overlay
modprobe br_netfilter
4. 安裝cri-o
# 設置yum源
export OS=CentOS_7
export VERSION=1.22
curl -L -o
/etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
# 安裝cri-o
yum install -y cri-o
5. 修改cri-o配置
# 查看conmon路徑
which conmon
# 修改cri-o配置文件
vi /etc/crio/crio.conf
# 修改crio.runtime表，加上conmon路徑配置
[crio.runtime]
conmon = "/usr/bin/conmon"
# 修改crio.image表，加上pause鏡像設置。xxx需要換成你的私有鏡像庫
[crio.image]
insecure_registries = ["xxx"]
pause_image = "xxx/k8s/pause:3.6"
# 修改registry配置
vi /etc/containers/registries.conf
# 添加私有鏡像庫，xxx需要替換成你的私有鏡像庫，這里設置了insecure，可按實現情況修改
# 因為我用的是私有倉庫，不需要設置鏡像站點
[[registry]]
prefix = "xxx"
insecure = true
blocked = false
location = "xxx"
6. 啟動cri-o服務
systemctl enable crio
systemctl start crio
systemctl status crio
7. 修改kubelet配置
設置kubelet命令行啟動參數，指定使用cri-o運行時。
vi /etc/sysconfig/kubelet
# 修改內容，加上以下兩個參數
KUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtime-endpoint='unix:///var/run/crio/crio.sock'
修改 /var/lib/kubelet/kubeadm-flags.env 文件，文件中如果有以下3個參數，請刪除。
- --cgroup-driver k8s建議在配置文件設置，不要在命令行。
- --cni-plugin 1.24版本后會和docker-shim一起被移除。
- --pod-infra-container-image 當使用cri-o運行時，kubelet忽略這個參數，需要在cri-o配置中指定。
修改kubelet的配置文件 /var/lib/kubelet/config.yaml，修改以下4個參數，如果參數不存在則添加上去。
設置kubelet的cgroup驅動為systemd，因為cri-o默認驅動是systemd，必須保持一致。舊版本kubelet默認驅動是cgroupfs，1.22以上才是默認systemd。
cgroupDriver: systemd
設置運行時請求超時：
runtimeRequestTimeout: 5m
容器stdout/stderr日志文件的回滾設置，按實際需求修改。
containerLogMaxSize: 100Mi
containerLogMaxFiles: 3
修改了 /var/lib/kubelet/config.yaml 文件后，建議同步修改內容到kubelet-config-1.xx configmap，1.xx是kubernetes的版本。因為集群擴容時，新節點使用這個configmap生成配置文件，這樣可以保證新舊節點配置文件一致。
kubectl edit cm -n kube-system kubelet-config-1.23
8. 啟動kubelet，查看kubelet狀態、節點狀態、pod狀態是否正常。
systemctl start kubelet
systemctl status kubelet
9. 更新kubeadm使用的cri運行時
kubeadm使用的cri運行時在node annotations中定義，需要單獨修改，否則下次使用kubeadm時會出錯，比如升級k8s版本的時候。
# 查看當前節點的kubeadm使用的cri運行時
kubectl get node <NODE_NAME> -o jsonpath='{.metadata.annotations.kubeadm\.alpha\.kubernetes\.io/cri-socket}'
# 將dokcershim修改為cri-o
kubectl annotate node <NODE_NAME> --overwrite kubeadm.alpha.kubernetes.io/cri-socket=/var/run/crio/crio.sock
10. 安裝podman
podman是一個開源的容器管理工具，命令幾乎與docker一致，可以用于替換docker。相較于docker，它不存在守護進程，因此podman避免了docker daemon引入的問題。另一方面，cri-o專注于CRI實現，沒有提供build、tag鏡像等功能，而podman和cri-o的鏡像是共享的，可以為cri-o補充鏡像管理功能。
yum install -y podman
podman info
11. 重啟服務器
docker卸載后可能還有一些配置遺留，例如iptables規則，建議重啟服務器，防止被影響。
12. 將節點重新加入集群調度。
kubectl uncordon <NODE_NAME>
到這里，第一個節點的容器運行時遷移就完成了，可以按照相同的方法再遷移其他節點。
遷移完成后就能愉快地把k8s版本升到1.24.0了。
4后記
雖然k8s已經正式移除了dockershim，但是docker+kubernetes的方案經過多年發展已經成熟，被廣泛地應用，短期內地位仍然不可撼動。開發、測試環境可以按照需求折騰，遷移容器運行時，積累實踐經驗。生產環境的話建議保持穩定，等時機成熟再遷移。
