crictl

List all kubernetes pods (Ready and NotReady)

$ crictl pods

$ crictl ps [[-a|--all]]

$ crictl images

$ crictl inspect [container_id1 container_id2 ...]

$ crictl exec [[-it|--interactive --tty]] [container_id] [sh]

$ crictl pull [image:tag]

$ crictl logs [[-f|--follow]] [container_id]

$ crictl rmi [image_id1 image_id2 ...]

crictl [GLOBAL_OPTIONS] COMMAND [COMMAND_OPTIONS] [ARGUMENTS]

Examples:
crictl ps
crictl images
crictl pull nginx:latest
crictl logs <container_id>

-D, --debug
    Enable debug output.

--runtime-endpoint <path>
    Endpoint of CRI runtime service (e.g., "unix:///var/run/containerd/containerd.sock").

--image-endpoint <path>
    Endpoint of CRI image service (often same as runtime endpoint).

--timeout <duration>
    Timeout for connecting to the server (e.g., "5s").

--config <path>
    Path to the crictl config file (e.g., "/etc/crictl.yaml").

-v, --version
    Show version information.

-h, --help
    Show help message.

crictl is a command-line interface tool that provides a common set of commands to interact with CRI-compatible container runtimes (like containerd, CRI-O) on a Kubernetes node. It's designed primarily for debugging and troubleshooting purposes, allowing administrators and developers to inspect and manage containers, pods, images, and other resources managed by the Container Runtime Interface (CRI). Unlike general-purpose container management tools such as docker or podman, crictl's primary focus is on the specific interactions required by Kubernetes.

It allows users to list pods, containers, and images; pull images; create sandboxes; run containers; and more, mimicking some of the functionalities that kubelet uses internally to communicate with the container runtime. This makes crictl an invaluable tool for understanding and diagnosing issues within the Kubernetes container ecosystem, especially when direct interaction with the container runtime is needed.

crictl is primarily a debugging and troubleshooting tool for Kubernetes nodes, not a general-purpose container management tool. Its functionality is tied to the Container Runtime Interface (CRI) specification, meaning it interacts directly with CRI-compliant runtimes (like containerd or CRI-O). Behavior and available features can vary slightly depending on the specific underlying runtime and its version. It requires direct access to the Kubernetes node where the container runtime is running.

crictl is invaluable for:

• Debugging kubelet issues or container startup failures.
• Verifying the status of the container runtime and its managed resources.
• Inspecting container images and their metadata.
• Force-removing stuck or misbehaving pods/containers when kubectl commands are insufficient.
• Understanding the direct interactions between kubelet and the underlying container runtime via the CRI API.

crictl can be configured using a YAML file, typically located at /etc/crictl.yaml or ~/.crictl.yaml. This configuration file allows users to specify the default runtime endpoint, image endpoint, and timeout settings, avoiding the need to pass them as command-line arguments repeatedly.

crictl was developed as part of the Kubernetes project to provide a consistent way to interact with various Container Runtime Interface (CRI) implementations. Its emergence parallels Kubernetes' evolution towards greater runtime independence. Before CRI, Kubernetes often had tight coupling with specific runtimes like Docker. The introduction of CRI abstracted runtime specifics, and crictl became the standard CLI tool for administrators and developers to debug and inspect the state of containers and pods directly on a Kubernetes node, bypassing kubectl and interacting with the underlying runtime services (e.g., containerd or CRI-O) via the CRI API. This provides a crucial layer for diagnosing issues between kubelet and the container runtime.

kubectl(1), kubelet(8), containerd(1), crio(8), podman(1), docker(1)