cri-containerd 1.7.23 离线安装、配置与排错-北京尧图网络

简介配套 cri-containerd 1.7.23 Linux AMD64 的容器运行时安装包面向云原生运维、Kubernetes 集群部署及容器运行时调试人员主要用于离线环境下的版本对齐、CRI 接入和运行时组件替换适合具备一定 Linux 与容器基础的中高级读者参考使用。压缩包共 19 个文件整体约 101.22MB主体为容器运行时及其命令行工具、CRI 测试与压力测试程序等二进制组件同时配有 yaml 配置、systemd 服务模板、环境变量和辅助脚本目录按系统路径组织可覆盖安装部署、接口联调、运行验证与基础压测等环节。已有 262 人学习下载。读者能够获得与 1.7.23 版本匹配的完整运行时文件集合便于在节点侧快速落地组件、核对配置模板、验证 CRI 连通性并开展基础性能测试包内弃用说明也有助于提前识别后续版本迁移风险降低组件不匹配带来的排错成本。1. 离线节点上那个 tar 包cri-containerd 1.7.23 到底装了什么内网机房里最尴尬的一幕节点出不了网kubelet 起来了却一直报容器运行时连不上翻遍发行版仓库才发现自带的那份 containerd 版本太老配置项跟手上的 kubelet 对不上。这时候cri-containerd-1.7.23-linux-amd64.tar就是那颗后悔药——它是 containerd 1.7 分支专门为 CRI 场景打的静态包解开来是几个不依赖系统库的二进制拷进 U 盘就能带到任意一台 x86_64 机器上。它适合两类人一是要在离线节点上把 containerd 装起来、再交给 kubelet 用的运维和 SRE二是想搞清楚装一个容器运行时到底装了哪几个文件、谁在调谁的工程师。下面按我实际交付的顺序拆包里有什么、怎么落到 systemd、config.toml改哪几行、以及五个真把节点搞挂过的坑。2. 解包之前先认清组件五个二进制和一条启动链路拿到一个 tar 包很多人的第一反应是tar -xf完事然后systemctl start一把梭。离线环境里这么干出问题的时候你连从哪一层开始查都不知道。我一般会先花五分钟把包拆开看清楚这一步省下来的时间远比它花掉的多。2.1 tar 里到底有什么先看清单再决定解到哪这一步纯属保命# 只看清单不解压。确认里面确实有 shim 和 runc别拿到一个空壳包 tar -tf cri-containerd-1.7.23-linux-amd64.tar | head -n 30 # 看顶层目录结构一般是 ./bin 和 ./etc 两层 tar -tf cri-containerd-1.7.23-linux-amd64.tar \ | awk -F/ NF1 {print $2} | sort -u # 顺手校验离线包最容易在 U 盘拷贝、跳板机中转这两步损坏 sha256sum cri-containerd-1.7.23-linux-amd64.tar如果清单里只有bin/、没有etc/说明这个包不带默认配置config.toml必须自己用containerd config default生成。另外一个高频混淆点cri-containerd这个包不带 CNI 插件带插件的是cri-containerd-cni那个变体。节点上如果还没有任何 CNI 配置光装这个包Pod 网络是通不了的得单独补插件。包里的二进制各管一段缺一个就是一段链路断掉二进制职责缺了之后的表现containerd守护进程本体监听/run/containerd/containerd.sockCRI 插件内嵌在里面服务根本起不来containerd-shim-runc-v2每个容器一个 shim 进程托管 runc 与容器进程的生命周期Pod 长期停在ContainerCreatingrunc真正干活的 OCI 运行时创建 namespace、cgroup、挂载根文件系统shim 起不来日志里是no such file or directoryctrcontainerd 自带客户端绕过 CRI 直连 socket只是少了最底层的调试入口crictlCRI 客户端和 kubelet 走同一个接口少了和 K8s 视角一致的排查手段这张表值得抄在交付文档里。后面所有排错本质都是先判断断在表的哪一行。2.2 从 kubelet 到 runc一次 Pod 创建经过谁理解这条链路比背任何命令都有用。kubelet 通过 CRI 的 gRPC 接口连到containerd.sock请求落到 containerd 内部的 CRI 插件上——注意这个插件是 containerd 进程里的一个插件io.containerd.grpc.v1.cri不是独立进程所以ps里看不到第二个 containerd。插件解析请求之后交给 runtime v2 层由它 fork 出containerd-shim-runc-v2shim 再调runc把容器进程创建出来。这里有个容易忽略的点1.7 里 CRI 插件默认是启用的但它可以在disabled_plugins里被关掉。有些裁剪过的配置模板会把cri加进禁用列表结果就是 containerd 明明活着kubelet 却怎么都连不上日志里是no CRI service这类提示。我第一次遇到时查了半小时 socket 权限最后发现是插件被禁了血泪经验。另一个点是 shim 的常驻特性。容器跑起来之后runc就退出了真正托管容器进程的是 shim。所以ps -ef | grep shim看到的一堆进程是正常的不要以为是泄漏。也正因为 shim 独立于 containerd 主进程containerd 重启时容器不会跟着死——前提是你的 systemd unit 写对了这部分在第 5 章会细说。2.3 为什么是 1.7.23而不是随手拿个更新的1.7.23 是 1.7 分支后期的补丁版本这个定位决定了它的使用场景已经在 1.7 线上的节点做补丁升级或者新节点要和存量节点保持同一小版本。K8s 对容器运行时的兼容窗口一般是相邻小版本1.7 的 containerd 配 1.26 到 1.28 的 kubelet 都属于常见组合跨度再大就要逐个配置项对一遍。我不建议为了版本新直接跨到 2.x。2.x 的配置文件版本、shim 路径、sandbox 的实现方式都有变化一份 1.7 的config.toml拿过去大概率报解析错误而且存量节点混版本会让镜像和快照的兼容问题变得很难查。版本统一这件事在离线环境里尤其重要——你不能指望节点出网去拉一个缺失的组件。还有一条是和内核的关系。runc依赖内核的 cgroup 和 namespace 能力3.10 这类老内核上跑较新的 runc经常在 cgroup v2 相关的路径上报权限错误。装之前先确认内核版本比装完再回滚便宜得多# 内核版本与 cgroup 版本决定了 snapshotter 和 runc 的可用性 uname -r stat -fc %T /sys/fs/cgroup # 输出 cgroup2fs 表示 v2tmpfs 表示 v13. 从 tar 到 systemd一条能复现的最小安装路径安装本身很短短到很多人会跳过验证直接进下一步。但离线交付里翻车的八成不是安装命令写错而是以为装好了。这一章按我实际的顺序来落盘、生成配置、拉起服务、两级验证每一步都留一个可观测的检查点。3.1 落盘、校验与 PATH# 包内路径是 ./bin/xxx解到 /usr/local 正好落成 /usr/local/bin/xxx tar -C /usr/local -xf cri-containerd-1.7.23-linux-amd64.tar # 四个关键二进制逐个确认在 PATH 里且版本自洽 /usr/local/bin/containerd --version /usr/local/bin/runc --version /usr/local/bin/ctr --version /usr/local/bin/crictl --version-C /usr/local这个参数是整套流程的关键。包内是相对路径./bin/containerd解到别处就得自己建软链而软链一旦漏建systemd unit 里的ExecStart就会指向一个不存在的文件报错信息还挺含糊。如果你的系统里已经有发行版仓库装的旧 containerd先systemctl stop containerd并确认which containerd指向新路径新旧混用是排查噩梦。crictl默认找不到 socket每次手动加--runtime-endpoint太难受直接写死cat /etc/crictl.yaml EOF runtime-endpoint: unix:///run/containerd/containerd.sock image-endpoint: unix:///run/containerd/containerd.sock timeout: 10 debug: false EOFtimeout设 10 秒是有讲究的默认值偏短在内网仓库响应慢的时候crictl pull会莫名超时让人误以为是网络不通。调到 10 到 30 秒之间能把真的不通和只是慢区分开。3.2 生成 config.toml 并改三处关键参数mkdir -p /etc/containerd containerd config default /etc/containerd/config.toml # 留一份原始备份后面 diff 的时候能救命 cp /etc/containerd/config.toml /etc/containerd/config.toml.origconfig default输出的是当前这个二进制对应的默认值所以千万别拿网上抄来的一份 1.6 模板套在 1.7 上字段名和层级都可能变过。生成完之后改三处# 1) cgroup driver 对齐kubelet 用 systemdcontainerd 也必须 systemd sed -i s/SystemdCgroup false/SystemdCgroup true/ /etc/containerd/config.toml # 2) pause 镜像换内网地址离线节点不允许它去公网拉 sed -i s#sandbox_image .*#sandbox_image harbor.example.internal/base/pause:3.9# \ /etc/containerd/config.toml # 3) 落盘位置确认root 放大盘state 放本地盘或 tmpfs grep -nE ^\s*(root|state)\s* /etc/containerd/config.tomlsed只是图快正式环境我建议手改再diff一遍sandbox_image那一行的引号和缩进很容易被改坏导致 containerd 启动时直接解析失败。参数的含义和调整边界参数默认值什么时候必须改SystemdCgroupfalsekubelet 用 systemd 作为 cgroup driver 时必须改true否则容器创建报 cgroup 权限错sandbox_image指向公网 pause 镜像离线或内网环境必须换成内网仓库地址tag 要和 kubelet 期望的一致root/var/lib/containerd系统盘小时挪到大盘挪之前要把已有数据迁走不能直接改完重启state/run/containerd一般不动除非/run空间被别的服务挤爆max_concurrent_downloads3仓库限流或带宽紧张时调小到 1 到 2本地仓库可以调大到 5 到 83.3 systemd unit 与首次拉起unit 文件我不从包里拿手写一份更可控# /etc/systemd/system/containerd.service [Unit] Descriptioncontainerd container runtime Afternetwork.target local-fs.target [Service] ExecStartPre-/sbin/modprobe overlay ExecStart/usr/local/bin/containerd Typenotify Delegateyes KillModeprocess Restartalways RestartSec5 LimitNPROCinfinity LimitCOREinfinity TasksMaxinfinity OOMScoreAdjust-999 [Install] WantedBymulti-user.target三个参数值得单独说。Delegateyes让 containerd 自己管 cgroup 子树不写的话 Pod 数量一多就会出现 cgroup 争用和莫名其妙的 OOM。KillModeprocess保证systemctl restart只杀主进程不把 shim 和业务容器一起带走——这是很多人改个配置重启一下业务全没了的直接原因。OOMScoreAdjust-999是给 containerd 上个保险内存紧张时优先被杀的是业务而不是运行时。systemctl daemon-reload systemctl enable --now containerd systemctl status containerd --no-pager # 起不来就看这 50 行配置解析错误会直接打在这里 journalctl -u containerd -n 50 --no-pager3.4 用 ctr 和 crictl 做两级验证这一步是整个流程里最值钱的部分。ctr走 containerd 原生接口crictl走 CRI 接口两个都测就能把故障范围切成两半ctr通、crictl不通问题在 CRI 插件配置两个都不通问题在 containerd 本体或 runc。# 第一级绕过 CRI验证 containerd 本体、snapshotter、镜像拉取链路 ctr version ctr -n k8s.io images pull harbor.example.internal/base/busybox:1.36 ctr -n k8s.io run --rm harbor.example.internal/base/busybox:1.36 smoke-test echo ok-n k8s.io这个 namespace 必须带。containerd 是多租户的kubelet 用的 namespace 就是k8s.io不加 namespace 你会在default里操作ctr images ls看到的是一片空白然后误判镜像没拉到。# 第二级走 CRI验证插件真的起来了、配置真的被读到 crictl info | head -n 20 crictl pull harbor.example.internal/base/pause:3.9 crictl images # 再确认 CRI 看到的 sandbox 配置和你写的一致 crictl info -o json | grep -i sandboxcrictl info能返回 JSON 这件事本身就是个信号——它意味着 CRI 插件在正常响应。如果这条命令卡住基本可以断定插件没启或被禁用直接去看config.toml里的disabled_plugins。4. config.toml 里真正决定成败的四个配置块config.toml几百行绝大多数行你一辈子都不用碰。真正会让节点交付失败的集中在四个块上。这一章把这四块拆开讲包括每个字段改了之后的连锁反应。4.1 sandbox_imagepause 镜像不对Pod 就起不来pause 容器的作用是持有 Pod 的 network namespace其他业务容器 join 进这个 namespace。它由 containerd 而不是 kubelet 负责拉取所以镜像地址配错时kubelet 那边只能看到一个语焉不详的 sandbox 创建失败事件。# 把当前配置里的 sandbox_image 抓出来逐台节点核对 grep -n sandbox_image /etc/containerd/config.toml # 别等创建 Pod 时才发现仓库里没这个 tag提前 pull 一次 crictl pull harbor.example.internal/base/pause:3.9tag 版本要和 kubelet 的期望对齐。版本不一致的典型现象是 sandbox 反复重建Pod 一直在ContainerCreating和CrashLoopBackOff之间跳。另外记住一条铁律改完sandbox_image必须重启 containerdCRI 插件只在启动时读配置热加载不存在这一点坑过不少人。4.2 registry 与 mirrors离线环境怎么让 containerd 找到仓库1.7 上两套写法并存config.toml里的registry.mirrors和/etc/containerd/certs.d/host/hosts.toml。前者是老写法后者更细粒度。先看config.toml这套[plugins.io.containerd.grpc.v1.cri.registry] config_path /etc/containerd/certs.d [plugins.io.containerd.grpc.v1.cri.registry.mirrors.harbor.example.internal] endpoint [https://harbor.example.internal] [plugins.io.containerd.grpc.v1.cri.registry.configs.harbor.example.internal.tls] insecure_skip_verify false [plugins.io.containerd.grpc.v1.cri.registry.configs.harbor.example.internal.auth] username robot password CHANGE_ME几个边界要划清。config_path一旦设置certs.d 目录下的配置优先级更高两套并存时非常容易出现我明明改了 mirrors 却不生效的玄学我一般只保留一套另一套注释掉。insecure_skip_verify true只适合在自签证书且 CA 还没导入的临时阶段打开长期开着等于关掉校验后面换证书时会踩更大的坑。把明文密码写进配置文件也不体面能用凭据助手或者挂载密钥就别写死。4.3 snapshotter 与 root/state 目录默认 snapshotter 是overlayfs兼容性最好的是native但空间占用大得多。overlayfs 有两个硬性前提内核加载了 overlay 模块且底层文件系统支持d_type——xfs 必须建卷时带ftype1否则会出现一堆诡异的现象比如镜像能拉下来但容器起不来或者层合并出错。# 三个前提条件一次性确认 lsmod | grep overlay || modprobe overlay xfs_info /var/lib/containerd 2/dev/null | grep -i ftype df -hT /var/lib/containerd /run目录规划上root放镜像和快照是最吃空间的地方节点上单独挂一块盘比较稳state放 socket 和运行时状态重启就没了一般留在/run下。改root之前必须先把存量数据迁过去直接改完重启会让 containerd 认为一切从零开始已有镜像全部消失——不是真的丢了是它去新目录找不到了。4.4 改完必须回读不能只看重启成功systemctl restart containerd systemctl is-active containerd # 回读配置确认 CRI 插件真的按新参数在跑 crictl info -o json | grep -iE sandbox|snapshotter # 再用一次真实拉取做端到端确认 crictl pull harbor.example.internal/base/busybox:1.36systemctl is-active返回active只说明进程活着不说明配置生效。config.toml里某个字段名写错时containerd 有时候会带着警告启动并忽略那一块日志里只有一行不起眼的 warn。所以回读这一步别省。提示每次改config.toml前先cp一份带时间戳的备份改完diff一眼能省掉大量到底改了啥的回忆成本。5. 排查清单五个把节点搞挂的坑下面五条都是我在交付现场真实遇到过的按现象 → 原因 → 解决写遇到对应的直接对号入座。5.1 重启 containerd 之后节点上业务容器全没了现象改完配置执行systemctl restart containerd几秒后crictl ps一片空白kubelet 开始成批报 sandbox 不存在业务全量抖动。原因systemd unit 里没写KillModeprocess默认是control-group重启时会把整个 cgroup 里的进程一起杀掉包括 shim 和容器进程。严格说不是容器挂了是它们被 systemd 顺手带走了。解决unit 里补上KillModeprocess和Delegateyessystemctl daemon-reload再重启。已经在跑容器的节点改配置前先cordondrain把业务挪走再操作别在高峰期赌运气。5.2 kubelet 报连接失败socket 明明存在现象kubelet 日志里是rpc error: code Unavailable或connect: no such file or directory但手工ls /run/containerd/containerd.sock是有文件的。原因路径没对齐。一种是 kubelet 的--container-runtime-endpoint还指向老运行时的 socket另一种是 unit 里给 containerd 加了--address参数换了路径但 kubelet 那边没同步。也有权限问题——socket 的属主和 kubelet 的运行用户不匹配。解决两边统一写unix:///run/containerd/containerd.sock。用ss -lntp | grep containerd确认实际监听路径用ls -l看 socket 的权限位再用crictl -r unix:///run/containerd/containerd.sock info从客户端侧验证一次连通性。5.3 Pod 卡在 ContainerCreating事件指向 pause 镜像现象kubectl describe pod里反复出现Failed to pull image ...pause...或sandbox image not found节点上其他一切正常。原因三种可能。sandbox_image还是默认的公网地址离线节点出不去地址改了但内网仓库里没有对应 tag仓库有镜像但证书不受信拉取时报 TLS 错误被当成拉取失败。解决先crictl pull手工拉一次 pause 镜像能把三种原因快速区分开。拉取报 404 就是 tag 不存在报x509就是证书超时就是网络或 DNS。证书问题把 CA 放到/etc/containerd/certs.d/host/ca.crt比开insecure_skip_verify干净得多。5.4 容器创建时报 cgroup 相关错误现象failed to create task后面跟着unable to apply cgroup configuration或permission denied容器起一下就退。原因cgroup driver 不一致。kubelet 用 systemdcontainerd 还是默认的 cgroupfs两边对同一个 cgroup 路径的理解不同写进去就打架。老内核上还有另一种可能内核只支持 cgroup v1但配置里按 v2 的路径在写。解决SystemdCgroup true之后重启用stat -fc %T /sys/fs/cgroup确认 cgroup 版本。老内核节点上别指望靠改配置绕过所有问题该升级内核就升级硬扛下去只会在业务高峰期爆。5.5 镜像拉取时快时慢偶发超时现象同一个镜像crictl pull有时几秒完成有时卡两三分钟然后超时重试又能成功。原因max_concurrent_downloads默认是 3多个 Pod 同时启动时并发拉层把仓库带宽或连接数打满也可能是config.toml的 mirrors 和 certs.d 两套配置同时生效containerd 在多个 endpoint 之间来回试。解决先把镜像配置收敛成一套只留 certs.d 或只留 mirrors。并发调到 1 到 2 观察本地仓库带宽充足时再往上调。同时把crictl.yaml里的timeout提到 30 秒让慢和不通能区分开别把慢当成故障处理。6. 上线前的 dry runcerts.d 分仓库配置与自查表多仓库场景下我倾向于把信任关系按 host 拆开管而不是全塞进config.toml。每个仓库一个目录一份hosts.toml谁的问题一眼能定位mkdir -p /etc/containerd/certs.d/harbor.example.internal cat /etc/containerd/certs.d/harbor.example.internal/hosts.toml EOF server https://harbor.example.internal # 主仓库带 CA允许 pull 和 resolve [host.https://harbor.example.internal] capabilities [pull, resolve] ca /etc/containerd/certs.d/harbor.example.internal/ca.crt # 备用镜像站只读主仓库不可达时兜底 [host.https://mirror.example.internal] capabilities [pull, resolve] skip_verify false EOFcapabilities里加不加push是有区别的只给pull和resolve等于从运行时层面堵死了误推的可能构建机和生产节点用同一份配置时尤其省心。skip_verify我一般显式写false哪怕它是默认值写出来是为了让后来接手的人知道这里校验是开着的。交付前我会固定跑一遍这张表六项全过才把节点交给 kubelet检查项命令通过标准二进制版本自洽containerd --version runc --version版本与预期一致无 unknown服务状态systemctl is-active containerdactive且journalctl无 errorcgroup 对齐grep SystemdCgroup /etc/containerd/config.toml值为truepause 可达crictl pull sandbox_image拉取成功无 TLS 报错端到端运行ctr -n k8s.io run --rm busybox t echo ok输出ok且自动清理磁盘余量df -hT /var/lib/containerd使用率低于 70%这套流程我吃过亏才固化下来。早期交付时图快装完systemctl start看到active就撤了结果第二天业务上线Pod 全卡在ContainerCreating原因是sandbox_image还指着公网。从那以后我每台新节点交付前都会强制走一遍crictl pull pause加ctr run一个 busybox 的双重 dry run两个都过才允许 kubelet 接进来。这份cri-containerd-1.7.23-linux-amd64.tar本身没什么花样真正值钱的是上面这套顺序和那份自查表——包在内网文件服务器上放一份配置模板和检查项跟着节点一起归档下次扩容能省掉一整天。希望帮到你。本文还有配套的精品资源点击获取

cri-containerd 1.7.23 离线安装、配置与排错

相关推荐

群晖NAS挂载和彩云：WebDAV与rclone自动备份实战

MATLAB多尺度法求解Duffing方程：完整代码包与工程避坑指南

Python数据分析全流程：Miniconda环境搭建与Jupyter实战

更多资讯

纯Python实现铅锤面内无控导弹弹道仿真与RK4数值积分

Rancher 2.7 生产级部署与集群运维实战指南

ns-usbloader 安装配置全攻略：Java 环境、USB 驱动与文件传输避坑指南

Linux私有化部署IP归属地查询服务：MMDB与高性能实践

单细胞聚类后如何注释细胞类型？从UMAP体检到Marker验证全流程

半导体制造中的高端布料：关键材料与技术解析

今日更新

MATLAB缩进快捷键与批量格式化实战指南

用Poco实现Qt风格信号与槽的跨平台C++方案

ESXi裸机虚拟化安装指南：从硬件兼容到虚拟机部署

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？