cri-dockerd是mirantis维护的cri适配器，为docker engine提供kubernetes兼容层；自kubernetes 1.24移除dockershim后，它成为docker无缝接入k8s的关键桥梁，并默认通过cni插件（如calico、flannel）实现统一网络。
要让 Docker 容器真正“接入”Kubernetes，关键不是直接把 Docker 容器塞进 K8s，而是让 Kubernetes 能用 Docker Engine 作为底层运行时，并统一网络模型——这靠的是 cri-dockerd + CNI 网络插件 的组合，而不是所谓“跨平台网络插件”本身。市面上没有叫这个名字的独立工具，它实际指代的是在 cri-dockerd 架构下，对接标准 CNI（Container Network Interface）插件的能力。
Docker 运行时需先通过 cri-dockerd 接入 K8s
Kubernetes 1.24+ 已移除内置 dockershim，Docker Engine 不再原生兼容。必须部署 cri-dockerd 作为适配层：
- 它监听 K8s 的 CRI gRPC 接口，把 Pod 创建、启动等请求翻译成 Docker API 调用
- 它不替代 Docker，也不改造容器网络，只做协议桥接
- 安装后需重启 kubelet，并指定
--container-runtime-endpoint unix:///var/run/cri-dockerd.sock
CNI 插件才是网络统一的核心
cri-dockerd 默认启用 CNI 模式（v0.2.5+），它会调用你配置好的 CNI 插件（如 Calico、Flannel、Cilium）来为每个 Pod 分配 IP、设置路由和策略：
- 确保
/etc/cni/net.d/下有合法的 .conf 文件（例如 10-calico.conflist） - cri-dockerd 启动时自动读取该目录，无需额外参数；也可显式指定：
cri-dockerd --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d - Docker 容器本身不参与 CNI 配置——Pod 内的 pause 容器由 cri-dockerd 启动，并交由 CNI 插件接管网络命名空间
避免常见网络断连陷阱
即使 cri-dockerd 和 CNI 都装好了，Docker 容器仍可能无法与 K8s Pod 互通，原因通常是环境隔离未打通：
- 不要混用 docker run 启动的容器和 K8s Pod：手动用 docker 命令起的容器不在 K8s 管理范围，也不会被 CNI 分配集群 IP，也无法解析 Service DNS
-
宿主机网络需对齐：确保 Docker daemon 的
bridge网络（如 docker0）不与 CNI 分配网段冲突（例如避开 10.244.0.0/16、192.168.0.0/16） -
iptables/ipvs 规则要兼容：kube-proxy 若用 ipvs 模式，需确认内核模块已加载；若用 iptables，检查是否被 Docker 自动规则干扰（可设
"iptables": false在 /etc/docker/daemon.json 中）
验证是否真正“无缝”
真正的无缝体现为：K8s 调度的 Pod 能像 Docker Compose 服务一样互相发现，且网络行为一致：
- 在 Pod 内执行
ping和nslookup <service-name></service-name>均通 - 用
kubectl exec -it <pod> -- ip addr</pod>查看 eth0 地址属于 CNI 网段，而非 docker0 - 查看
cri-dockerd日志（journalctl -u cri-dockerd -f）确认无 “failed to setup network” 类报错
