一、内容整体设计与思路拆解1.1 Containerd 在工业级环境中的定位先聊一个很多人问过我的问题为什么已经有了 Docker还要在 Kubernetes 这一类编排系统里把运行时替换成 Containerd答案其实不复杂——Docker 本身是一套“容器解决方案”而 Containerd 是一个“容器运行时组件”。生产环境里跑着几百上千个节点时我们需要的不是 Docker 那一整套 API、网络代理和 CLI 工具链而是一个内核稳定、接口收敛、性能损耗尽量小的执行单元。Containerd 恰好就是这样一块“工业级零件”。从项目标题里的 Containerd、工业级容器、container-lifecycle-management 这几个关键词就能看出这篇博文的核心不是讲“怎么把镜像跑起来”而是要深入容器的一生——从创建到销毁中间经历启动、运行、暂停、停止直到最后的资源回收。这套流程在单机 Docker 环境里体验不明显因为 Docker CLI 把很多状态转换都给用户“代劳”了。但在工业级集群环境中调度器需要精确掌控每个容器的状态才能决定什么时候迁移 Pod、什么时候重启容器、什么时候把节点上的负载腾空。这时候理解 Containerd 对容器生命周期的管理方式就成了排查问题、优化性能、保障稳定性的基本功。1.2 生命周期管理为什么值得单独拆出来讲很多人以为容器生命周期管理无非就是 start、stop、rm 三个命令实际操作一下就会发现不是这么回事。Containerd 的生命周期模型里容器和任务Task是两个不同实体。容器负责保存配置、挂载点、镜像引用等元数据任务则是容器里正在运行的进程实例。创建了容器不代表进程已经启动进程退出了也不代表容器对象已经被清理。这个“容器—任务”双层模型是理解整个生命周期管理的关键也是工业级容器运行时的核心设计。更进一步看容器停掉之后rootfs 和容器层的数据仍然留在磁盘上。调度器和运维人员需要决定这些数据和配置是被保留还是被回收。网络方面容器停止时 CNI 插件要清理已分配的 IP虚拟网卡要摘除存储方面容器的读写层是否保留决定了下一次创建时能否复用已有数据。这些细节层层嵌套构成了“工业级”容器生命周期管理的完整图景。1.3 这篇博文适合谁看如果你已经在接触 Kubernetes 节点排障、操作系统连接不上容器运行时、或者频繁遇到 Pod 卡在 Terminating 状态这篇内容能帮你建立从命令到原理的完整链路。如果你是刚开始接触云原生基础设施、还不清楚 ctr 和 crictl 有什么区别的初学者这篇博文也会带你以最贴近生产环境的方式快速进入状态。二、核心细节解析与实操要点2.1 生命周期状态机的完整视图Containerd 的容器生命周期不是简单的一条直线而是一张状态转换图。理解这张图排查问题会清晰很多。第一个阶段是 Create。通过 ctr 或 CRI 插件创建容器时Containerd 会基于镜像生成一个 rootfs配置好 mounts、env、args并在它的内部状态里记录当前容器为 created。注意这个阶段没有任何用户进程在跑只是把“壳”准备好了。第二个阶段是 Start。Containerd 调用 runc 去执行容器里的 init 进程。runc 完成 namespaces、cgroups、capabilities 的配置后会把进程拉起容器进入 running 状态。这里有个细节如果容器里配置了 init 进程或自定义入口命令Start 阶段会确保这些进程被正确挂到控制组里。运行状态下的容器通过宿主机上的 containerd-shim 进程保持连接shim 是容器进程与 containerd 守护进程之间的桥梁它负责转发信号、收集退出状态、管理 stdio。第三个阶段是 Pause / Resume。使用 crictl pause 可以把容器里的所有进程冻结在 cgroup freezer 里CPU 调度停止但内存和文件句柄不释放。这个操作在给容器做快照或临时隔离时很有用但需要注意不是所有工作负载都能接受长时间暂停。第四个阶段是 Stop / Kill。停止容器本质上是向主进程发送信号。默认情况下Kubernetes 通过 CRI 发送 SIGTERM等待默认的优雅退出时间后再发送 SIGKILL 强制终止。这个设计是为了让业务进程有足够时间做退出前清理比如关闭数据库连接、刷新日志缓冲等。最后一个阶段是 Delete。删除容器时Containerd 会回收 rootfs 和容器层、摘除挂载点、释放 cgroup、清理网络接口。删除之后容器对象在 containerd 的 metadata 里被标记为 deleted随后从存储中被移除。2.2 容器与任务的双层模型我最初用 ctr 的时候犯过一个错误ctr c create 创建完容器然后直接用 ctr c ls 查看以为容器已经在跑了直到看了半天才发现根本没有进程。因为 create 和 start 是分开的create 只完成配置和 rootfs 准备start 才会真正拉起进程。在 containerd 的术语体系里这个正在运行的进程对象叫 Task。容器是静态实体任务是动态实体。你可以在同一个容器上停止任务、重启任务容器对象本身不会变化这就引出了一个实际应用Kubernetes 里的重启策略本质上是在复用容器对象的基础上重新创建和拉起 Task。理解了这个模型你在排查“容器停止失败”这类问题时就能快速定位是 Task 没有正常退出还是容器对象清理流程卡住了。有了这个诊断方向再去检查 shim 进程、Cgroup 路径、挂载点状态就顺理成章了。2.3 工业级场景下的状态约束生产环境下我们最怕的是“状态不确定”。容器到底是在启动中还是已停止是在删除中还是删除失败Containerd 用内部状态机约束了这些转换的合法性例如不能直接从一个运行中的容器执行删除必须先停止不能对一个尚未创建的容器执行启动Pause 和 Resume 是互斥操作等。我曾经在测试环境里用脚本循环删除和创建容器结果有一天出现了大量状态异常的记录。查到最后是因为脚本绕过了 Stop 阶段直接调用了 DeleteContainerd 虽然能处理这种请求但状态机的不一致会导致 GC垃圾回收任务无法及时清理底层资源。工业级环境的第一原则就是按状态机的合法路径操作不要跳过中间状态。三、实操过程与核心环节实现3.1 工具选型ctr vs crictlContainerd 项目中自带两个客户端工具ctr 和 crictl。它们并不是互为替代品而是服务于不同场景。ctr 是 containerd 的原生 CLI能直接操作 containerd 的所有原生对象包括 namespace、image、container、task。优点是功能全面调试底层问题时很直观缺点是它绕过了 CRI 插件的流程直接向 containerd 核心 API 发起请求所以用 ctr 创建的容器不会自动被 kubelet 感知到。crictl 是 CRI 兼容的容器运行时调试客户端它模拟的是 kubelet 通过 CRI 接口发起请求的行为。我们日常排查节点上的 Pod 和容器时用的基本都是 crictl。它会把 Pod 抽象为 sandbox把业务容器抽象为单一的 container这与 Kubernetes 的视角完全一致。建议生产环境优先使用 crictl 排查问题在学习和理解底层机制时使用 ctr。两个工具结合使用既能看清 CRI 层交互又能深入核心对象。3.2 使用 ctr 完整演示一个容器的生命周期为了方便演示我用一个最小化的容器镜像这里从公共镜像仓库拉取一个静态工具镜像用于测试。实际操作时你会选镜像仓库里你自己的镜像或者公共镜像仓库的镜像原理都是相通的。先创建 namespace。生产环境中的租户隔离和组件隔离大多依赖 namespaceKubernetes 的 Pod 和容器一般会在 k8s.io 这个 namespace 下管理而系统组件则可能放在其他 namespace 中。执行以下命令创建独立 namespacectr namespace create demo-lifecycle拉取镜像ctr -n demo-lifecycle image pull docker.io/library/busybox:latest创建容器ctr -n demo-lifecycle container create docker.io/library/busybox:latest demo-container这时候容器已经创建完成但运行状态的 Task 还不存在。你可以用下面这个命令验证ctr -n demo-lifecycle task list执行后会看到列表里只有“已创建但未运行”的容器状态标识。下面创建并启动 Taskctr -n demo-lifecycle task start -d demo-container /bin/sleep 3600命令成功执行后容器进程在后台运行。再看一下 Task 列表此时状态应该变为 running。接下来我们演示暂停并恢复容器ctr -n demo-lifecycle task pause demo-container ctr -n demo-lifecycle task resume demo-container暂停时进程被冻结在 cgroup freezer恢复后继续运行。最后停止容器ctr -n demo-lifecycle task kill demo-container ctr -n demo-lifecycle task delete demo-container ctr -n demo-lifecycle container delete demo-container这个流程虽然简单但踩过的坑不少。第一次用 kill 之后没有执行 task delete导致容器对象始终处于“进程已退出但 Task 未清理”的状态。正确的顺序必须是先 kill 停止任务再删除 Task最后删除容器对象。3.3 使用 crictl 演示 Pod 沙箱与容器生命周期接下来用 crictl 模拟 kubelet 的视角。首先创建一个 Pod 沙箱沙箱就是一组共享命名空间的容器集合对应 Kubernetes 里的 Podcrictl runp sandbox-config.json然后准备好业务容器的配置通过 run 命令创建并启动容器指定 Docker 镜像和沙箱 IDcrictl run container-config.json sandbox-idcrictl run 会自动完成容器创建、任务启动和网络配置。查看当前容器列表crictl ps -a你会看到沙箱容器和业务容器两个条目。这里有个非常容易混淆的地方Pod 沙箱本身也是一个容器它运行的是 pause 容器。pause 容器的唯一作用是“占住”一组 Linux namespace让同一 Pod 内的业务容器可以加入这组 namespace形成共享网络和 PID 空间的单元。在生命周期管理中Pod 删除时需要先删除业务容器再删除沙箱容器顺序不能乱否则会导致 namespace 无法正常回收。停止容器crictl stop container-id删除容器和沙箱crictl rm container-id crictl rmp -f sandbox-id-f 参数用于强制删除处于非活跃状态的沙箱。这个场景经常出现在节点维护和 Pod 驱逐时理解这里就能明白 kubelet 在节点压力下执行驱逐时经历的状态转换路径。3.4 生命周期中的存储与网络资源管理容器生命周期管理核心不只是进程还包括存储和网络。存储方面容器创建时Containerd 会为容器准备 rootfs。rootfs 由镜像层和容器层组成镜像层为只读容器层负责运行时的写入。容器被删除时默认情况下容器层会一并清理磁盘空间得以释放。这就是为什么你用 docker 删除容器后磁盘占用会降低而工业级场景下我们要格外关注持久化数据卷的生命周期——卷的挂载点与容器生命周期解耦删除容器并不会自动删除卷数据。网络方面每当沙箱创建时CRI 插件会调用 CNI 配置的网络插件比如 Calico 或 Flannel为沙箱分配 IP 并创建网络命名空间。容器生命周期结束时CNI 的 DELETE 操作会回收 IP 并清理虚拟网卡。如果容器删除后 IP 仍然被占用基本可以推断是 CNI 调用链路或者第三方插件卡住了这个思路对排查 IP 泄漏非常有价值。3.5 状态查询与诊断命令速查日常工作中我使用频率最高的是下面这几组命令命令用途crictl ps -a查看所有容器及其状态包括已退出容器crictl inspect container-id查看容器完整状态信息包括 PID、挂载点、资源限制crictl logs container-id查看容器日志crictl stats查看运行时资源使用情况ctr -n k8s.io task list原生视角查看 Task 列表排查任务状态ctr -n k8s.io container ls原生视角查看容器列表ctr -n k8s.io c info container-id查看容器元数据详情一个实用的排查思路当 crictl ps 显示容器为 CONTAINER_EXITED但业务进程在你的监控系统里仍然存在时不要急着强制杀掉进程先检查这个进程是不是容器外的残留进程用nsenter或者ctr task list判断该 PID 归属的 cgroup 路径是否还挂载在已删除的容器之下。四、常见问题与排查技巧实录4.1 容器删除失败卡在 Terminating这是 Kubernetes 环境里最常见的生命周期问题。现象是 Pod 一直处于 Terminating 状态几分钟甚至几小时都无法消失。排查步骤可以按这个顺序走第一步用 crictl 查看容器状态crictl ps -a | grep pod-name如果容器状态显示为 CONTAINER_EXITED 但删除卡住大概率是 Containerd 在等待 kubelet 确认或者是 CNI 资源清理没结束。第二步检查 containerd 的日志。多数情况会看到错误信息显示任务删除超时或 mount point 仍然被占用journalctl -u containerd --since 10 minutes ago第三步去宿主机上检查容器对应的 cgroup 路径是否还在。容器删除后cgroup 应该自动清理。没有清理的话手动查看并处理挂载cat /proc/mounts | grep container-id4.2 停止容器时优雅退出超时进程被 SIGKILL业务容器停止时kubelet 会给容器一个优雅退出时间默认是 30 秒。如果进程在超时时间内没有退出kubelet 会发送 SIGKILL 强杀。这个问题常见于业务进程没有处理 SIGTERM 信号或者存在不可中断的内核线程。从生命周期管理的角度建议业务镜像内部实现退出钩子确保 SIGTERM 到达时业务代码能够主动关闭连接池、落盘未完成的数据。底层基础设施层面则要确保 containerd 和 runc 的版本不低于当前发行版的支持基线避免因 shim 阻塞导致 SIGKILL 延迟。4.3 沙箱逃逸与顽固的 pause 容器crictl ps 里看到一个 pause 容器一直处于 Running对应的业务容器却全部退出了。这个状态并不一定异常因为 Pod 的沙箱生命周期可以比业务容器更长。但如果一个 Pod 已经被删掉很长时间暂停沙箱仍然存在那就要动手清理了。此时先利用 crictl inspect 查询沙箱关联的 CNI 网卡和 IP再去 CNI 插件侧检查对应的 IP 是否还需要回收。确认不会有业务流量后再执行强制删除。工业级运维规范通常要求任何生产节点的强制删除操作都记录操作人、时间和原因这是避免误伤的重要手段。4.4 镜像层和容器层占满磁盘容器生命周期管理的末端是资源回收。如果节点上频繁创建容器、Taint 和驱逐但磁盘空间越用越满就要排查 Containerd 的镜像 GC 和高位垃圾回收配置。Containerd 提供了 image GC 和 container GC 两个机制相关配置位于 /etc/containerd/config.toml。合理的 GC 配置能自动清理未被容器引用的镜像层和悬空容器。我曾经在一个高负载节点上配置了较短的生命周期回收周期结果反过来影响了大镜像的正常拉取。调整之后采用分时回收策略在业务低峰期触发回收任务磁盘占用和拉取性能同时得到保证。这个平衡需要根据你的业务负载特征持续观察不存在一个适合所有集群的通用数值。五、踩过几次坑之后的个人体会Containerd 的容器生命周期管理说到底是围绕状态、资源和时间三件事的博弈。状态要清晰每一步都要合法可追踪资源要可控网络、存储、CPU、内存都要随生命周期正确回收时间要敏感优雅退出要配置合理GC 任务要避开业务高峰。我在实际生产运维中最大的体会是永远不要在生产节点上绕开 CRI 层去操作核心对象的生命周期。ctr 能修改底层状态但不会同步通知 kubelet。一旦两边状态不一致排障成本远高于临时操作节省的时间。如果你维护的是 Kubernetes 集群优先用 crictl如果你在深入研究和学习 Containerd 的核心设计ctr 是不可或缺的工具。两者配合才能在工业级容器环境里做到既懂原理又处变不惊。最后再分享一个小技巧在关键操作前给 containerd 的日志目录开启持久化排障时先看时间线再定位对象很多生命周期问题的答案都藏在事件顺序里。