crictl怎么用？Kubernetes节点排障命令实践

Kubernetes节点从Docker运行时逐步转向containerd后，很多过去依赖 docker ps、docker logs 的排障习惯需要调整。crictl是面向CRI的命令行工具，它看到的是kubelet与容器运行时之间的标准接口状态，因此更适合排查Pod沙箱、容器、镜像和运行时连接问题。

crictl不是kubectl的替代品，也不是ctr的完全替代品。kubectl面向Kubernetes API，适合看调度、事件和资源对象；crictl面向节点CRI，适合确认节点上真实容器状态；ctr更接近containerd内部，适合深入分析内容存储和快照。排障时把三者放在正确层级，才能减少误判。

使用前先确认运行时端点

crictl需要知道CRI运行时端点。多数containerd节点会通过 /etc/crictl.yaml 配置运行时端点、镜像端点、超时时间和调试开关。若没有配置文件，crictl可能尝试多个默认端点，导致命令变慢或出现连接告警。建议在节点基线中明确配置，而不是让运维人员每次手工指定。

crictl version
crictl info

如果这一步失败，先不要排查业务容器。应检查containerd服务、CRI插件、socket路径和权限。对于使用不同运行时的节点，也要确认crictl连接的是kubelet实际使用的CRI端点。

Pod、容器和镜像怎么查看

crictl最常用的三类对象是Pod沙箱、容器和镜像。Pod沙箱可以理解为Kubernetes为Pod准备的运行基础环境，业务容器运行在这个环境之上。

crictl pods
crictl pods --name <pod_name>
crictl inspectp <pod_id>
crictl ps -a
crictl inspect <container_id>
crictl logs <container_id>
crictl images
crictl inspecti <image_id>

这些命令的关键不是背参数，而是理解状态差异。例如，kubectl显示Pod处于Pending，节点上可能还没有Pod沙箱；kubectl显示CrashLoopBackOff，crictl通常能看到历史退出容器和退出码；kubectl显示ImagePullBackOff，crictl images可能确认镜像是否已存在本地。

一个推荐的节点排障顺序

排查节点问题时，建议遵循“API事件、节点CRI、运行时日志”的顺序。第一步看Kubernetes事件：

kubectl describe pod <pod_name> 
  -n <namespace>

第二步在目标节点上看CRI状态：

crictl pods --name <pod_name>
crictl ps -a | 
  grep <pod_name>

第三步查看容器日志和详细状态：

crictl logs <container_id>
crictl inspect <container_id>

第四步才进入运行时和系统层：

journalctl -u containerd 
  --since "30 min ago"

这个顺序能帮助团队把问题分层：调度失败、镜像拉取失败、容器启动失败、应用进程退出、运行时异常，分别对应不同处理人和处理动作。

常见故障场景如何定位

镜像拉取失败时，先看事件中的错误，再用crictl确认本地镜像状态。如果镜像不存在且拉取失败，重点检查仓库地址、tag、认证、证书、代理和节点网络。如果镜像存在但仍然失败，要检查镜像拉取策略、摘要变化和运行时缓存。

容器启动后立即退出时，使用 crictl ps -a 找到退出容器，再用 crictl logs 和 crictl inspect 查看退出码、启动命令、环境变量和挂载信息。若退出码稳定重复，通常是应用自身配置或依赖问题；若状态混乱，则继续检查containerd和kubelet日志。

Pod一直处于ContainerCreating时，重点关注Pod沙箱、CNI、镜像解压、存储挂载和Secret挂载。此时单看容器日志可能没有结果，因为容器未必已经启动。更多容器运行时背景可结合容器技术专题理解CRI链路。

crictl和ctr、kubectl的边界

kubectl面向Kubernetes API对象，适合调度、事件和资源状态；crictl面向CRI对象，适合节点Pod、容器、镜像排障；ctr面向containerd内部对象，适合内容存储、快照和任务深查。生产环境建议把crictl作为节点排障标准工具，但不建议把它变成日常变更工具。手工删除容器、强行拉取镜像或修改底层状态，可能让节点实际状态与Kubernetes控制面短暂不一致。

平台团队可以把crictl命令整理成场景化SOP，而不是只给一张命令表。更有效的方式是按故障入口组织：镜像拉取失败、容器异常退出、Pod沙箱创建失败、节点运行时不可用、磁盘压力、CNI异常。每个场景至少包含先看什么信号、用哪些命令验证、最终把问题归因到哪个层级。

常见问题

crictl可以替代docker命令吗？

在Kubernetes节点排障场景中，crictl可以替代很多过去用于查看容器、日志和镜像的docker命令。但它不是完整Docker开发工具，不能覆盖Dockerfile构建、本地开发编排等能力。生产节点更关注CRI状态，因此应把crictl作为运行时排障工具，把镜像构建留在CI或专用构建环境中。

为什么crictl看不到我用ctr看到的镜像？

常见原因是命名空间和视角不同。Kubernetes通过CRI使用的containerd资源通常在 k8s.io 命名空间下，而ctr如果不指定命名空间，看到的可能不是同一组对象。此外，ctr展示的是containerd内部对象，crictl展示的是CRI接口可见对象，两者不一定一一对应。排障时应先以crictl为准，再用ctr补充验证。

可以用crictl直接删除异常容器吗？

临时排障时可以执行删除操作，但要非常谨慎。Kubernetes控制器可能重新创建容器，直接删除只能解决局部状态问题，不能替代修复Deployment配置、镜像、Secret、存储或网络问题。生产环境建议先保留日志和inspect结果，再按平台SOP决定是否删除，避免丢失关键证据。