这次我们来看一个很经典的部署链路用kubeadm安装 Kubernetes 集群但底层容器运行时不走默认的 containerd而是继续走 docker。Kubernetes 从 1.24 正式移除 dockershim 之后“k8s docker”这个组合已经不是默认选项需要额外加一层cri-dockerd适配器因此很多同学在部署时会卡在版本匹配、cgroup driver、socket 路径这些细节上。标题里的1.37.x是目标版本号示例。Kubernetes 官方 release 渠道的版本更新非常快实操前请先确认当前可用的稳定版本把命令里的${K8S_VERSION}替换成实际版本号不要直接照抄一个可能还没发布的补丁版本。这篇文章会用一个最小拓扑1 台 Master 1 台 Worker完整走一遍环境准备、Docker 安装、cri-dockerd 部署、kubeadm 初始化、Flannel 网络、节点加入、应用验证。最后会整理常见报错和排查清单部署完可以直接对照。1. 为什么 kubeadm 安装还要底层走 docker 容器运行时先回答一个常被问到的问题k8s 和 docker 到底有什么区别。Docker 是一个容器引擎负责镜像构建、容器生命周期管理、网络和存储的默认方案。Kubernetes 是一个容器编排平台负责调度、服务发现、扩容缩容、故障恢复。简单理解docker 管单个容器k8s 管一群容器。k8s 需要一种“容器运行时”来真正把容器跑起来这个运行时接口叫 CRIContainer Runtime Interface。在早期版本里Kubernetes 的 kubelet 通过内置的 dockershim 模块直接调用 docker。但是从 k8s 1.24 开始dockershim 被正式移除kubelet 不再直接识别 docker 的 API。默认情况下kubelet 会选择 containerd 作为运行时。由于 docker 底层本身也依赖 containerd很多团队仍然希望继续保留 docker 做镜像管理和本地开发。要在 k8s 1.24 版本里继续走 docker需要安装cri-dockerd。它是 Mirantis 维护的适配器负责把 kubelet 发出的 CRI 调用翻译成 docker API。整体调用链路变为kubelet - CRI - cri-dockerd - docker daemon - containerd - 容器这个链路上多了一层转换性能和稳定性方面不如直接用 containerd好处是能继续使用 docker 命令直接查看 pod 对应的容器对于已经深度依赖 docker 的运维团队来说迁移成本更低排障心理负担也更小。所以不是“k8s 只能走 containerd”而是安装适配器后可以继续使用 docker。本文的方案就是围绕这条链路展开的。2. 部署方案核心能力速览能力项说明部署方式kubeadm 初始化 kubeadm join目标版本k8s 1.37.x以官方 release 实际可用版本为准容器运行时Docker cri-dockerd 适配器CRI 适配器cri-dockerd监听unix:///var/run/cri-dockerd.sock网络方案Flannel VXLANPod 网段10.244.0.0/16操作系统Ubuntu/Debian 系CentOS/RHEL 系命令差异见正文说明最小节点1 台 Master 至少 1 台 Worker建议 2C2G 以上证书体系kubeadm 自动签发kubeconfig 控制访问权限API 能力Kubernetes API Server 默认端口 6443批量能力通过 Deployment/StatefulSet 实现批量调度适合场景已有 docker 使用习惯的团队迁移、测试环境、学习 kubeadm 机制这里不涉及 GPU、显存、图像模型这类资源核心资源是 CPU、内存、磁盘和网络。Pod 网段和 Service 网段需要和网络插件匹配提前规划好别随意改。3. 适用场景与使用边界3.1 适合谁已经在用 docker 管理镜像和容器短期内不想切 containerd 的团队。需要学习 kubeadm 工作原理观察 kubelet 如何向运行时发起调用的开发者。企业内部已有 docker registry、docker compose 等设施想先低成本把 k8s 跑起来的场景。3.2 不适合谁新搭建的生产环境官方默认推荐 containerd。containerd 少一层适配镜像启动更快故障面更小。大规模集群、依赖复杂 CRI 高级特性时优先考虑 containerd。如果你完全没用过 docker直接在 k8s 场景学习 containerd 可能更省事没必要再学 docker 再转一层。3.3 安全与合规边界kubeadm 默认生成自签名证书API Server 的访问控制依赖 kubeconfig文件权限必须收紧不要随意复制到不可信环境。镜像来源要可信尤其是 kube-system 和网络插件镜像尽量使用官方发布渠道。如果环境涉及生产业务注意镜像漏洞扫描、镜像签名、RBAC 最小授权、NetworkPolicy 网络隔离。多租户环境不要共享 kubeconfigkubeadm token 有有效期过期后重新生成。所有操作建议在隔离测试环境完成不要在未备份的生产机器上直接操作。4. 环境准备与前置条件4.1 节点规划角色主机名配置建议系统Masterk8s-master2C4G磁盘 40GUbuntu 22.04 LTSWorkerk8s-worker012C4G磁盘 40GUbuntu 22.04 LTS生产环境建议 Master 4C8G 以上Worker 根据业务负载调整。这里只讨论通用部署流程不区分云厂商。4.2 操作系统推荐 Ubuntu 22.04 LTS 或 Debian 12内核 5.4 以上。CentOS 7.9 / Rocky Linux 9 也可以把apt-get替换成yum或dnfkubeadm 安装源也要换成对应 RPM 源。4.3 设置主机名和 hosts 解析每台机器分别设置主机名# Master 节点 hostnamectl set-hostname k8s-master # Worker 节点 hostnamectl set-hostname k8s-worker01在所有节点的/etc/hosts里加入 IP 和主机名映射cat /etc/hosts EOF 192.168.10.10 k8s-master 192.168.10.11 k8s-worker01 EOF这里的 IP 是示例地址实际按你的服务器内网 IP 替换。4.4 关闭交换分区Kubernetes 1.28 之后虽然支持部分 swap 场景但初学者建议先关闭避免调度行为不可控swapoff -a sed -i / swap / s/^/#/ /etc/fstab执行后可以用free -h确认 swap 为 0重启机器后依然生效。4.5 加载内核模块并配置 sysctl所有节点都要执行cat EOF | tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF modprobe overlay modprobe br_netfilter然后配置内核参数cat EOF | tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sysctl --system这里的关键是br_netfilter它让 iptables 规则能正确处理桥接流量。Flannel 的 VXLAN 和 kube-proxy 的转发都依赖这两个参数。4.6 端口要求组件端口方向kube-apiserver6443所有节点可访问etcd2379-2380Master 内部kubelet10250Master 到 Workerkube-scheduler10259本机kube-controller-manager10257本机Flannel VXLAN8472/UDP节点间互通测试环境可以先关防火墙或放行全部内网通信生产环境按最小原则放行端口。4.7 软件版本说明Docker使用当前稳定版本。docker 官方 apt 源安装即可。cri-dockerd选择与目标 k8s 版本接近的 release 版本所有节点保持一致。kubeadm、kubelet、kubectl版本必须一致且与集群目标版本一致。5. 安装 Docker 与 cri-dockerd5.1 安装 Docker所有节点都需要安装 Dockerapt-get update apt-get install -y ca-certificates curl install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc chmod ar /etc/apt/keyrings/docker.asc echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ tee /etc/apt/sources.list.d/docker.list /dev/null apt-get update apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin安装完成后启动 Dockersystemctl enable --now docker docker version5.2 配置 Docker cgroup driver 和镜像加速kubelet 默认使用systemdcgroup driverdocker 也必须保持一致否则初始化会因为 cgroup driver 不一致而直接失败。编辑/etc/docker/daemon.json{ exec-opts: [native.cgroupdriversystemd], registry-mirrors: [https://你的镜像加速器地址] }镜像加速器地址按你所在环境实际可用的服务配置不同的云服务商控制台会给出专属地址。这里不写具体域名避免失效。重启 Dockersystemctl restart docker执行docker info确认输出中Cgroup Driver为systemd。5.3 安装 cri-dockerdcri-dockerd 是让 k8s 继续走 docker 的关键组件。推荐使用官方 release 的 deb 包或二进制包安装。先确认最新 release 版本号再执行wget https://github.com/Mirantis/cri-dockerd/releases/download/${CRI_DOCKERD_VERSION}/cri-dockerd-${CRI_DOCKERD_VERSION}.amd64.deb sudo dpkg -i cri-dockerd-${CRI_DOCKERD_VERSION}.amd64.deb其中${CRI_DOCKERD_VERSION}换成实际 release 版本号例如0.3.x这样的格式。如果系统架构不是 amd64改成对应架构的包名。如果想用二进制方式安装可以下载 tar 包并手动安装 systemd 服务文件但 deb/rpm 包更省事启动文件也会自动创建。启动并设置开机自启systemctl enable --now cri-docker systemctl status cri-docker5.4 验证 CRI socketcri-dockerd 启动后需要确认 socket 文件存在ls -l /var/run/cri-dockerd.sock再把crictl的 endpoint 指向 cri-dockerdcat EOF | tee /etc/crictl.yaml runtime-endpoint: unix:///var/run/cri-dockerd.sock image-endpoint: unix:///var/run/cri-dockerd.sock timeout: 10 debug: false EOF配置完成后用crictl info可以查看运行时信息。后面 kubelet 也是通过这个 socket 和 docker 通信。6. 安装 kubeadm、kubelet、kubectl6.1 添加 Kubernetes 官方 apt 源Kubernetes 1.28 之后推荐使用pkgs.k8s.io源。这里以 v1.37 为例apt-get update apt-get install -y apt-transport-https ca-certificates curl gpg mkdir -p /etc/apt/keyrings curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.37/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo deb [signed-by/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.37/deb/ / | tee /etc/apt/sources.list.d/kubernetes.list apt-get update如果v1.37目录在你的网络环境下还不可用把路径中的v1.37改成官方当前最新的稳定版本号即可例如v1.36或v1.35。安装源的版本目录要和你准备部署的集群版本保持一致。6.2 安装 kubeadm、kubelet、kubectl所有节点执行apt-get install -y kubelet kubeadm kubectl如果需要锁定版本先查看源里有哪些可用版本apt-cache policy kubeadm然后按具体版本号安装例如apt-get install -y kubelet${K8S_VERSION}-* kubeadm${K8S_VERSION}-* kubectl${K8S_VERSION}-*这里${K8S_VERSION}替换成类似1.37.2这样的完整版本号。如果不确定先apt-cache policy再定。设置 kubelet 开机自启但先不要启动kubeadm 初始化时会自动拉起systemctl enable kubelet6.3 验证版本一致性kubeadm version kubelet --version kubectl version --client三个命令输出的版本必须一致。如果 Master 和 Worker 的组件版本不一致节点加入时会报版本不匹配错误。7. kubeadm init 初始化与网络插件部署7.1 准备 kubeadm 配置文件在 Master 节点创建kubeadm-config.yamlapiVersion: kubeadm.k8s.io/v1beta3 kind: InitConfiguration localAPIEndpoint: advertiseAddress: ${MASTER_IP} bindPort: 6443 nodeRegistration: criSocket: unix:///var/run/cri-dockerd.sock --- apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: ${K8S_VERSION} networking: podSubnet: 10.244.0.0/16 --- apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration cgroupDriver: systemd${MASTER_IP}换成 Master 的内网 IP${K8S_VERSION}换成实际版本号。nodeRegistration.criSocket必须指向 cri-dockerd 的 socket这一步是“底层走 docker”的核心写错会导致 kubelet 去找 containerd。7.2 执行 kubeadm initkubeadm init --config kubeadm-config.yaml初始化过程会先拉取控制面镜像再启动 etcd、API Server、Controller Manager、Scheduler。如果 docker 镜像拉取慢先确认第 5.2 节的镜像加速配置是否生效也可以手动执行kubeadm config images pull预拉取。初始化成功后输出末尾会包含两部分关键信息配置 kubectl 的命令。Worker 节点加入集群的kubeadm join命令记得保存token 默认有效期 24 小时。7.3 配置 kubectl按初始化输出的提示执行mkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config执行kubectl get nodes此时 Master 状态应该是NotReady这是正常的因为网络插件还没安装。7.4 安装 Flannel 网络插件网络插件必须和控制面组件同时就绪Pod 才能互通。这里使用 Flannelkubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml然后观察 Pod 状态kubectl get pods -n kube-flannel -o wide kubectl get pods -n kube-system -o wide等待 1 到 2 分钟等coredns、flannelPod 进入Running状态再执行kubectl get nodes如果 Master 显示Ready控制面就已经就绪。如果 Pod 一直CrashLoopBackOff优先看日志和镜像拉取状态排查方法见第 10 章。8. Worker 节点加入集群与功能验证8.1 Worker 节点重复执行前置操作Worker 节点需要完成第 4 章、第 5 章、第 6 章的所有步骤关闭 swap、加载内核模块、安装 docker、安装 cri-dockerd、安装 kubeadm/kubelet/kubectl。唯一不需要执行kubeadm init。一个常见错误是 Worker 节点只装了 docker 和 kubelet没有装 cri-dockerd。最后 join 时 kubelet 找不到 runtime会一直报CRI v1 runtime API is not implemented之类的错误。8.2 在 Master 上获取 join 命令如果初始化时输出的 join 命令已过期可以重新生成kubeadm token create --print-join-command输出类似kubeadm join 192.168.10.10:6443 --token xxxxx --discovery-token-ca-cert-hash sha256:xxxxx在 Worker 节点执行时需要加上--cri-socketkubeadm join ${MASTER_IP}:6443 --token ${TOKEN} --discovery-token-ca-cert-hash ${HASH} \ --cri-socketunix:///var/run/cri-dockerd.sock不加这个参数kubelet 也会优先找 containerd。8.3 查看节点状态回到 Master 节点kubectl get nodes kubectl get pods -n kube-system -o wideWorker 节点状态变为Ready后整个集群最小拓扑就算搭完了。8.4 部署一个 Nginx 应用验证用 Deployment 部署一个简单的测试应用kubectl create deployment nginx-demo --imagenginx:latest kubectl scale deployment nginx-demo --replicas2 kubectl get pods -o widePod 分布在 Master 和 Worker 上说明调度正常跨节点网络也能工作。把服务暴露成 NodePortkubectl create service nodeport nginx-demo --tcp80:80 kubectl get svc然后在浏览器或另一台机器访问http://节点IP:NodePort能看到 Nginx 默认页面。8.5 进入容器查看日志和运行时通过 kubectl 进入容器kubectl exec -it pod-name -- bash看到容器内的 shell 后说明 kubelet 通过 cri-dockerd 成功把容器跑在 docker 之上。退出后直接在当前节点用 docker 命令检查docker ps | grep nginx-demo这时能看到对应 Pod 的容器说明“底层走 docker”是真实生效的。也可以在节点上用 crictl 查看crictl ps查看应用日志kubectl logs -l appnginx-demo8.6 LNMP 场景简说这套集群跑 LNMP 架构完全够用。推荐拆分成三个层NginxDeployment NodePort/Ingress负责静态资源和反向代理。PHP-FPMDeployment和 Nginx 通过 Service 通信。MySQLStatefulSet PVC持久化数据数据库密码用 Secret 管理。这种拆分方式可以充分利用 k8s 的调度、滚动更新和故障恢复能力。相比 docker composek8s 的价值在于多节点调度和自愈能力。9. 资源占用与性能观察9.1 控制面组件资源占用Master 节点常驻进程包括kube-apiserver、etcd、kube-controller-manager、kube-scheduler、kubelet、kube-proxy、flanneld、docker、cri-dockerd。最低 2C4G 可以跑起来但 cpu 和内存都比较紧张。可以用kubectl top node查看节点负载用docker stats查看单个容器资源占用。Worker 节点主要是kubelet、kube-proxy、flanneld、docker、cri-dockerd资源占用比 Master 小很多。9.2 docker 链路多出的额外开销直接使用 containerd 时kubelet 调用链是 kubelet - containerd。使用 docker 时多了一层 cri-dockerd 转发CPU 和内存会有少量额外消耗。在 Pod 密度很高、频繁创建销毁容器的场景下这个差异会放大。测试环境无所谓生产高密度部署要留意。9.3 降低负载的建议提前拉取镜像避免运行时并发拉取。减小容器日志产生量配置合理的日志轮转。不用的镜像定期清理docker image prune -a可以释放磁盘。如果确认要长期跑生产还是建议切回 containerd减少一层适配。10. 常见问题与排查方法问题现象可能原因排查方式解决方案kubeadm init 报 cgroup driver 错误docker 的 cgroup driver 不是 systemddocker info查看 Cgroup Driver修改 daemon.json 并重启 dockerkubelet 日志报找不到 socketkubeadm 没指定 cri-dockerd socket查看/var/run/cri-dockerd.sock是否存在在配置文件中设置criSocket: unix:///var/run/cri-dockerd.sockkubeadm init 拉镜像超时镜像加速未配置或网络问题kubeadm config images list列出镜像后手动拉取配置 docker 镜像加速重新kubeadm initNode 一直是 NotReady网络插件未安装或 flannel 未运行kubectl get pods -n kube-flannel安装 Flannel 插件并等待 Pod RunningPod 一直 Pending资源不足或节点有 taintkubectl describe pod name检查节点资源或删除 taintkubectl get nodes 只能看到 MasterWorker join 失败或 token 过期在 Worker 上重新执行 join 命令kubeadm token create --print-join-command重新生成crictl 连接失败crictl 的 endpoint 没指向 cri-dockerd查看/etc/crictl.yaml设置 runtime-endpoint 为 cri-dockerd.sockjoin 时版本不匹配kubeadm 和集群版本不一致检查kubeadm version统一所有节点的组件版本Flannel Pod CrashLoopBackOff10.244.0.0/16 网段与 VPC 网段冲突查看 flannel 日志修改配置文件的 podSubnet 或调整 VPC 网段端口被占用6443 或 10250 被其他服务占用ss -lntp查看端口释放端口或修改组件监听地址一个容易忽略的细节kubeadm reset清理时也要指定 CRI socket否则可能清理不干净。kubeadm reset --cri-socketunix:///var/run/cri-dockerd.sock执行后再手动删除残留的容器和挂载目录必要时重启节点。11. 最佳实践与使用建议11.1 第一次部署先小参数测试不要一上来就生产配置。先用最小参数把集群跑通确认 kubeadm init 成功、网络插件正常、Pod 能调度再逐步加高可用、多 Worker、存储、监控。11.2 kubeadm reset 的正确用法部署失败后需要彻底清理kubeadm reset --cri-socketunix:///var/run/cri-dockerd.sock rm -rf /etc/cni/net.d ~/.kube如果还有 docker 容器残留手动docker rm -f $(docker ps -aq)清理测试容器。保持环境干净能避免很多二次部署问题。11.3 证书轮换与 etcd 备份kubeadm 签发的证书有效期默认一年需要记住证书到期时间kubeadm certs check-expiration证书快到期时执行kubeadm certs renew alletcd 数据是集群核心状态测试环境也要养成备份习惯ETCDCTL_API3 etcdctl snapshot save /backup/etcd-snapshot.db \ --endpointshttps://127.0.0.1:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key11.4 RBAC 最小授权不要直接把 admin kubeconfig 散给所有人。需要给其他同事时用 RBAC 创建只读或指定 namespace 权限的 ServiceAccount把更细粒度的 kubeconfig 分发出去。11.5 镜像加速与离线兜底内网环境拉不到镜像时提前在有网络的环境拉取所有 kube-system 镜像和必要业务镜像导出后传到内网节点再用docker load导入。离线部署时这一步能省很多时间。12. 总结与下一步这套方案最值得尝试的地方是在 k8s 1.24 版本里保留 docker 操作习惯。通过 cri-dockerd 适配kubelet 照常调度docker 命令也能直接看到容器对新接触 k8s 的人来说心理门槛低不少。建议第一次实操时重点验证三件事docker info中的 cgroup driver 是否为 systemd。/var/run/cri-dockerd.sock是否存在。kubectl 进入容器后docker ps 能否看到对应容器。最容易踩的坑基本都集中在 CRI socket 和 cgroup driver 配置上这两处配置对了整个链路就通了一大半。下一步可以继续扩展给 Master 和 Worker 之间配置高可用、接入 Ingress Controller、部署 Prometheus 监控、用 Helm 管理应用或者把 LNMP 业务完整搬到集群里验证滚动更新和故障自愈能力。如果是奔着生产环境去还是建议逐步迁移到 containerd减少适配层换来更稳定的长期运行体验。