1. 为什么需要离线部署containerd在工业控制、军工系统、金融核心业务等特殊场景中服务器往往运行在物理隔离的网络环境中。我曾经参与过一个智能制造项目生产线的控制服务器连内网都不允许接入更别说访问互联网了。这种环境下要部署容器化应用传统的在线安装方式完全行不通。离线部署最大的技术难点在于依赖链断裂。常规的containerd安装需要在线下载依赖包而静态二进制文件containerd-static就像个自给自足的集装箱——把所有依赖都打包进单个可执行文件。实测在CentOS 7这种老系统上用动态链接的containerd会因为glibc版本过低直接报错而静态版本完全无视系统库版本。2. 准备工作构建离线资源包2.1 获取静态二进制文件首先在有网络的机器上访问GitHub releases页面wget https://github.com/containerd/containerd/releases/download/v1.6.8/containerd-1.6.8-linux-amd64.tar.gz wget https://github.com/opencontainers/runc/releases/download/v1.1.4/runc.amd64 wget https://github.com/containernetworking/plugins/releases/download/v1.1.1/cni-plugins-linux-amd64-v1.1.1.tgz这里有个坑要注意containerd的静态版本命名带-static后缀比如containerd-static-1.6.8-linux-amd64.tar.gz。我遇到过同事误下载普通版本导致glibc报错的情况建议用这个命令校验file containerd-1.6.8-linux-amd64/bin/containerd | grep statically linked2.2 制作离线安装介质将下载的文件打包成离线安装包mkdir -p offline-containerd/{bin,cni,config} cp containerd-1.6.8-linux-amd64/bin/* offline-containerd/bin/ cp runc.amd64 offline-containerd/bin/runc tar xzf cni-plugins-linux-amd64-v1.1.1.tgz -C offline-containerd/cni/建议用ansible-playbook或者简单的shell脚本自动化这个过程。我在实际项目中会额外包含一个version.txt文件记录各组件的版本信息避免后期维护时出现版本混乱。3. 离线环境部署实战3.1 基础环境配置将离线包拷贝到目标机器后先设置PATH变量export PATH/usr/local/bin:$PATH mkdir -p /opt/cni/bin解压containerd静态二进制包tar Cxzvf /usr/local containerd-static-1.6.8-linux-amd64.tar.gz这里有个细节静态二进制文件体积较大约50MB但部署时不需要安装任何依赖库。对比动态链接版本在Ubuntu 18.04上需要额外安装12个依赖包。3.2 系统服务配置创建systemd单元文件时要注意Delegate配置cat /etc/systemd/system/containerd.service EOF [Unit] Descriptioncontainerd container runtime Afternetwork.target [Service] ExecStartPre-/sbin/modprobe overlay ExecStart/usr/local/bin/containerd Delegateyes KillModeprocess Restartalways ... EOF关键参数说明Delegateyes允许containerd管理自己的cgroupKillModeprocess只终止主进程避免误杀容器进程TasksMaxinfinity需要systemd v226版本支持3.3 组件安装与校验安装runc时要特别注意权限install -m 755 runc.amd64 /usr/local/sbin/runc chmod 755 /usr/local/sbin/runcCNI插件需要放到指定目录tar xzf cni-plugins-linux-amd64-v1.1.1.tgz -C /opt/cni/bin/验证安装是否成功containerd --version runc --version ls /opt/cni/bin/4. 常见问题排查指南4.1 GLIBC版本冲突典型报错containerd: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.32 not found解决方案分三步确认下载的是containerd-static版本用file命令检查二进制文件类型使用ldd命令查看动态链接情况静态版本应显示not a dynamic executable4.2 网络插件问题当容器无法联网时检查lsmod | grep br_netfilter sudo modprobe br_netfilter还要确保iptables规则正确iptables -L | grep CNI4.3 存储驱动配置在/etc/containerd/config.toml中建议使用overlayfs[plugins.io.containerd.grpc.v1.cri.containerd] snapshotter overlayfs对于老内核3.x可能需要换用aufs或者devicemapper。5. 生产环境优化建议5.1 资源隔离配置在config.toml中限制资源使用[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc] runtime_type io.containerd.runc.v2 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup true5.2 日志管理调整日志轮转策略mkdir -p /var/log/containerd cat /etc/logrotate.d/containerd EOF /var/log/containerd/*.log { rotate 7 daily compress missingok copytruncate } EOF5.3 安全加固建议的selinux配置semanage fcontext -a -t container_runtime_exec_t /usr/local/bin/containerd restorecon -v /usr/local/bin/containerd6. 版本升级策略离线环境下的升级需要特别注意下载新版本静态二进制包停止旧服务但不卸载解压新版本到临时目录对比config.toml的差异灰度迁移容器实例建议使用工具比较配置差异diff -u /etc/containerd/config.toml /tmp/new-containerd/config.toml7. 容器运行时生态解析containerd、runc和CNI插件的关系可以用快递系统类比containerd像快递公司总部管理整体运作runc是送货的快递员负责容器生命周期CNI插件是运输网络处理容器间的联通这种架构设计使得各组件可以独立升级。我在某次升级中就遇到过只更新runc不更新containerd的情况系统仍然稳定运行。