今天分享一下Kubernetes為什么識別不了docker鏡像。這是Kubernetes1.24版本后困惑一些運維人員的問題。

今天我們徹底搞清楚： 為什么 Docker 導入的鏡像 Kubernetes 不認？ 以及兩種靠譜解決方案，讓你的鏡像跑起來不踩坑。

1. 為什么識別不了

在早期（Kubernetes v1.23 及以前），K8s 的容器底層是靠 Docker 驅動的。 那時候，可以用 docker load 導鏡像、docker images 查鏡像，都是一個體系。

docker load -i nginx.tar
kubectl run test --image=nginx:1.26

完美運行!

但從 v1.24 開始，Kubernetes 把 Docker “踢”了出去，改用新的容器運行時，比如：

• containerd
• CRI-O

官方理由是：Docker 不符合 Kubernetes 的標準接口（CRI），就是想擺脫依賴，而且使用docker需要多走一層，消耗性能。

這意味著：

• K8s 跑的容器，不再是 “Docker 容器”，
• Docker 鏡像存在 Docker 庫里，K8s 運行時卻不認

就像：你把外賣放在 1 號宿舍門口 ，你自己住在 3 號宿舍——找不到是正常的。

2. 先確認你的 K8s 用哪個運行時

執行這條命令：

[root@k8s-master ~]# kubectl get node -o jsnotallow='{.items[*].status.nodeInfo.containerRuntimeVersion}'
containerd://1.7.27

會輸出當前的容器運行時是啥。

可見我用的是containerd，而不是docker。

3. 正確的導鏡像姿勢

如果你看到上面是 containerd，有兩種導入方法

方法 1：用 ctr

ctr 是 containerd 的命令行工具，雖然功能強大，但用法稍微原始一些，需要指定命名空間 k8s.io，因為 Kubernetes 的容器都運行在這個命名空間下

ctr -n k8s.io images import nginx.tar

查看導入結果

ctr -n k8s.io images ls | grep nginx

導入后就可以在deployment或直接運行該鏡像了。

方法 2：用 nerdctl

nerdctl 是 containerd 的一個增強 CLI，命令語法和 Docker 很相似，幾乎可以“零成本遷移 Docker 用戶”。

如果你更習慣 Docker 命令，這個方法非常方便。

默認是沒有的，需要自行安裝。

nerdctl load -i nginx.tar

導完以后，可以查一下：

nerdctl images |grep nginx

然后在你的 YAML 里直接寫：

image: nginx:1.26

這時候，K8s 就能順利拉到鏡像啦。nerdctl 默認也會導入到 k8s.io 命名空間，因此 Pod 可以直接識別。

4. 繼續使用docker命令

有些同學就是喜歡 Docker，希望直接 docker load 就能用。 可以通過 docker-cri / cri-dockerd 實現：

• 功能：把 Docker Daemon 包裝成符合 CRI 的接口
• 作用：K8s 重新通過 Docker 運行容器

不過已經部署完的Kubernetes集群再修改容器運行時也比較麻煩，需要安裝cri-dockerd，然后改kubelet的啟動參數，對于高版本都推薦用containerd。

這里部署和使用就不展開講了。

5. cri-dockerd 注意事項

小結：救急神器，但不適合長期生產環境。

6. 多節點環境最佳實踐

導鏡像這種手工操作，只適合單節點。 多節點集群建議使用 私有鏡像倉庫：

• 自建 Harbor / Docker Registry / 阿里云 ACR
• 上傳鏡像：

docker tag nginx:1.26 harbor.liyb.com/prod/nginx:1.26
docker push harbor.liyb.com/prod/nginx:1.26

• Pod YAML 里直接寫：

image: harbor.liyb.com/prod/nginx:1.26

全集群自動拉取，優雅高效。

還有個問題，要將harbor鏡像倉庫對接Kubernetes，也可以通過secret方式引入

7. 快速總結問題

如果你只是 單節點開發環境，cri-dockerd 很方便，想怎么用 Docker 都行。

但如果你要搭 生產級集群，建議徹底轉向 containerd，一次到位。