CRICTL Kubernetes Command Line Tool for Troubleshooting

 

 

CRICTL is not a command that you may have heard about when working with Kubernetes, but it is a really great utility to troubleshoot your Kubernetes cluster at the container runtime level. It provides a direct line of sight to the container runtime such as containerd or others like CRI-O. We will take a look at how to setup CRICTL and use it in a few practical examples for your Kubernetes cluster.

What is crictl?

First of all, let’s take a look at what CRICTL is exactly. It is a command line tool that is used to interact with your container runtimes that are used by Kubenetes. You can use the tool to inspect and troubleshoot your containers and podes and also images directly from the runtime. The key here is that it doesn’t need the Kubernetes control plane to get this information as it speaks directly to the container runtime.

Points to note:

• It allos direct access to container runtimes
• If kubectl is not working or doesn’t give you the information you need crictl helps
• If a node is isolated, you can still interact with the runtime which can definitely be helpful

Installing crictl

Let’s look at the process to install crictl and see how you can get up and running with the tool. You can install the CRICTL tool by curling down the tar.gz file or using something like wget, extracting the file, and then copying to usr/local/bin.

To find the latest release of the crictl tool, visit the download page here:

• https://github.com/kubernetes-sigs/cri-tools/releases

To download, the version you want to download, use the command example below, replacing the version with the version you want to download:

curl -LO https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.31.1/crictl-v1.31.1-linux-amd64.tar.gz

Next, we would like to unzip the file:

tar -xvzf crictl-v1.31.1-linux-amd64.tar.gz

Next, we can move the directory to our /usr/local/bin directory:

mv crictl /usr/local/bin

Finally, check that it is installed by running the command:

crictl --version

Configuring crictl for Your Environment

By default, crictl looks for the container runtime socket at /var/run/dockershim.sock. If you’re using containerd (common in modern Kubernetes setups), you will need to update your configuration. This is what I had to do when using it with a Microk8s Kubernetes cluster:

nano /etc/crictl.yaml

For containerd, you add the following in that file:

runtime-endpoint: unix:///var/snap/microk8s/common/run/containerd.sock

To test and see if the change has taken effect, run the following command:

critcl info

Below, we don’t get an error running the command so everything looks good pointed to the containerd runtime.

 

Example CRICTL Commands to use

Let’s look at a few example of using CRICTL and see how we can use th

Listing pods or containers

One of the things you may want to do with CRICTL is list your pods or containers. You can do this with CRICTL, using the following command:

crictl pods

This command returns the pod ID, namespace, and pod names. It will also give you the state of all pods on the node.

Getting kubernetes pods with crictl

Similar to using the docker cli, you can list containers running on a container host node using the following:

crictl ps

For all containers, including stopped ones:

crictl ps -a

Viewing logs

You can view the logs for a specific container using the following command:

crictl logs <container_id>

Inspecting containers

Inspecting Containers Get detailed information about a containers:

crictl inspect <container_id>

Listing images

Debugging Images List all images available on the node:

crictl images

Removing images

Remove an unused image:

crictl rmi <image_id>

Pulling images

Pull an image manually:

crictl pull nginx:latest

Stopping and removing pods

Managing Pods Remove a pod (useful for stuck or orphaned pods):

crictl stopp <pod_id>
crictl rmp <pod_id>

Troubleshooting sandboxes

Debugging Sandbox Issues In Kubernetes, pods are associated with sandboxes. List all sandboxes and inspect sandboxes:

crictl sandboxes
crictl inspectp <sandbox_id>

 

Troubleshooting with crictl

As CRICTL is primarily for troubleshooting in most cases, let’s consider a few examples of issues you might use CRICTL to troubleshoot. Note the following:

• When a Kubernetes pod is in a CrashLoopBackOff State: You can use crictl logs to get logs and troubleshoot for error messages
• When a Pod Won’t Start: Check the sandbox state: codecrictl sandboxes crictl inspectp <sandbox_id>
• When Disk Space is an Issue: List all images and remove unused ones: crictl images crictl rmi <image_id>

crictl vs. kubectl

You might wonder how do crictl and kubectl compare. They are both great tools but have their strengths and definite use cases. Note the following helpful comparison:

Feature	kubectl	crictl
Scope	talks to all nodes in cluster	specific to a node
Interaction	uses Kubernetes API	Direct comms with container runtime
Use Case	day-to-day management and troubleshooting of Kubernetes objects	Used to troubleshoot containers and runtime
Visibility	All nodes	local node only

crictl excels in node-level debugging, especially when the Kubernetes API server or kubectl commands aren’t helpful.

Wrapping up

Kubernetes is one of those solutions that it takes an acquired skill and experience to troubleshoot. But, it also takes the right tools and know what to use when. CRICTL is a command line tool that you may not have been familiar with but definitely one that you want to take notice of. Get this downloaded in your home lab and start experimenting with it to see how it can be helpful. It can definitely be a valuable addition to your troubleshooting toolbelt as it can help pinpoint issues or troubleshoot Kubernetes when kubectl might not be able to such as when a node is isolated.